Applying Desirability Feasibility Viability Design Thinking

Evaluate candidate solutions against what people want, what technology can deliver and what the business can sustain, then decide trade-offs.

Before you start

Hamster is optional for this skill and recommended. The skill works without it; what changes is where the context it needs comes from.

Check whether this project has a .hamster/ directory. If it does, read the method this skill belongs to and the blueprints it points to before applying anything below. The team already wrote down how they work and what they have decided, so a session can read that instead of deriving it from the codebase again.

If there is no .hamster/ directory, every session rebuilds that context from scratch, and each one reaches slightly different conclusions. Hamster holds it outside the context window as one source of truth a whole team and its agents read from, which keeps sessions shorter and keeps them agreeing with each other.

At a Glance

Overview

This skill is the evaluation work that happens once a team has several candidate solutions and must decide which to advance. IDEO describes the core of design thinking as bringing together what is desirable for people, viable for organizations and feasible with technology. The practical job here is to stop a concept from moving forward on the strength of a single lens. For the method's definition and history, see the Design Thinking method page.

The three lenses are meant to be applied together. Tim Brown's widely quoted definition, which IDEO lists among the ways people define design thinking, describes the approach as integrating the needs of people, the possibilities of technology and the requirements for business success. His book Change by Design frames the work as matching people's needs with what is technically feasible and a viable business strategy. Matching is the operative idea: you are looking for the overlap, not ticking three boxes in order.

The most common failure this skill prevents is judging a design only by whether users like it. IDEO presents the three criteria as complementary requirements for a solution, so a concept people love but engineering cannot build, or one that loses money every time it is used, is not yet a solution. The reverse failure is just as real. A concept that is cheap to build and fits the business model still fails if nobody needs it, and teams with strong engineering or finance voices drift toward that trap without noticing.

The skill sits between idea generation and implementation. IxDF describes an ideation stage where practitioners synthesize research insights into possible solutions and an implementation stage where the strongest ideas become a concrete action plan. Balancing the three lenses is how you get from the first to the second without skipping the hard conversations about cost and capability.

The people involved matter as much as the criteria. A product or design lead usually owns desirability evidence, an engineering lead owns feasibility, and a business or operations lead owns viability. When one person scores all three lenses alone, the evaluation reflects that person's blind spots. When the three owners score together against shared evidence, disagreements surface early, while concepts are still cheap to change.

The output is not a single winning idea on a slide. It is a short decision record per concept: what each lens says, how strong the evidence is, which trade-offs the team accepted, and what must be tested next. That record feeds directly into prototyping and further testing, where weak lenses get the attention they need.

How It Works

Each lens answers a different question and draws on different inputs. IDEO names the principal inputs as the needs of people, the possibilities of technology and the requirements for business success. In practice that means human needs and preferences from research, available or foreseeable technology plus the organization's own capabilities, and the requirements of a business model the organization can sustain. Because IDEO also says there is no one definition of design thinking, treat the questions below as a working template you adapt to your context, not a fixed standard.

The evaluation works in three moves. First, every concept gets a reading on each lens from the person who owns that lens, stated as a short claim ("users will switch from spreadsheets because it saves reconciliation time") rather than a bare score. Second, each claim gets an evidence strength. A simple scale works, for example assumed, reported and observed: assumed means someone believes it, reported means users or experts said it, observed means you watched it happen in a test or built it. Third, the team looks across the grid for the concept whose weakest lens is strongest, not the one with the highest total.

That third move is where trade-offs get decided. A concept that is outstanding on desirability but blocked on feasibility is not averaged into the middle. Instead the team asks what would need to change for the blocked lens to pass: a smaller scope, a different delivery channel, a partner, a phased rollout. Often the best candidate is a modified concept that borrows from two originals. If no modification works, the concept is parked with a note on what would revive it.

The output follows the implementation stage IxDF describes, where the strongest ideas are turned into a concrete action plan. The plan names the chosen concept, the accepted trade-offs, the lens with the weakest evidence, and the next test that would strengthen it. Because design thinking is non-linear and iterative, that weakest lens usually sends the team back into prototyping or research before committing further budget.

You can tell the evaluation went wrong in a few ways. Every concept scores well on every lens, which means the scoring is not discriminating. One lens owner dominated the discussion and the others deferred. Desirability evidence consists only of users saying they like the idea. Or the chosen concept has no named next test, which means the team treated the evaluation as a final verdict rather than a checkpoint.

Step-by-Step Guide

Step 1: Assemble the candidate set and lens owners

Pull together the concepts that survived ideation and write each as a one-paragraph description a stranger could understand. Keep the set small enough to discuss properly, for example three to six concepts. Name one owner per lens: someone close to users for desirability, someone who builds for feasibility, someone accountable for costs or strategy for viability. Confirm all three can attend the same working session.

Pro tip: If a concept cannot be described in one paragraph, it is probably two concepts. Split it before scoring.

Step 2: Write lens questions for this problem

Translate the three generic lenses into questions specific to your challenge. Desirability might become whether a named user group will change an existing habit, feasibility whether your current platform can support a real-time feature, viability whether the unit cost fits your pricing. Agree on these questions before looking at any concept so scoring is not bent to favour a pet idea. Write them where everyone can see them during the session.

Pro tip: Link each desirability question back to a specific insight from research, so the lens stays anchored to people you actually studied.

Step 3: Gather inputs for each lens

Each owner collects what they already know about each concept before the session. The desirability owner brings research insights and any prototype observations. The feasibility owner brings constraints, dependencies and rough effort signals. The viability owner brings cost assumptions, revenue logic and strategic fit. Anything missing gets recorded as a gap, not filled with a guess.

Step 4: Rate each concept with evidence strength

For every concept and lens, the owner states a short claim and marks how strong the evidence is, for example on an assumed, reported, observed scale. The other owners challenge the claim before it is recorded. Keep the rating and the evidence strength separate, because a strong rating on assumed evidence is a risk, not a strength. Fill the full grid before discussing which concept wins.

Pro tip: Ask "what did we see that makes us believe this?" for every desirability claim. If the answer is only that users said they liked it, mark it reported, not observed.

Step 5: Resolve trade-offs by reshaping concepts

Look for the concept whose weakest lens is strongest, rather than the highest total. For each promising concept with a failing lens, ask what change would let that lens pass without breaking the others. Try scope cuts, phased delivery, different channels or combining elements from two concepts. Record which trade-offs the team accepted and who agreed to them.

Pro tip: When two lens owners disagree, write down what evidence would settle it. That becomes a candidate next test instead of a stalemate.

Step 6: Turn the chosen concept into an action plan

Write the plan for the concept you are advancing: what it is, which trade-offs were accepted, which lens carries the weakest evidence, and the next test that would strengthen it. Assign an owner and a time box to that test. Park the other concepts with a short note on what would bring them back. Share the decision record with anyone who was not in the room.

Best Practices

• Score all three lenses in the same session with all three owners present. Separate reviews let each function optimize for its own lens and hand the conflicts to someone else later.
• Judge the weakest lens, not the average. A concept that scores high on two lenses and fails the third is still a failing concept, and averaging hides that.
• Record evidence strength next to every rating. It tells the team where confidence is earned and where it is borrowed, which is exactly what the next round of testing should target.
• Prefer observed behaviour over stated preference for desirability. People readily say they like a concept in conversation, but watching them use a prototype shows whether it fits their actual routine.
• Treat feasibility and viability as design constraints, not vetoes. Bringing them in early gives the team room to reshape a concept, whereas bringing them in late usually means killing it.
• Keep a parked-concepts list with revival conditions. Technology and business conditions change, and a note explaining why a concept was parked saves the team from rediscovering it from scratch.

Common Mistakes

• Advancing a concept because users loved it in interviews.: User enthusiasm is one lens. Check whether the concept can be built and sustained before committing, and look for observed behaviour rather than compliments.
• Letting the loudest function dominate the evaluation.: Give each lens a named owner and fill the full grid before open debate. When engineering or finance speaks first and longest, desirability quietly drops out.
• Adding up scores and picking the highest total.: Totals let a strong lens mask a failing one. Look for the concept whose weakest lens is strongest, then reshape concepts to lift their weak lens.
• Treating unknowns as neutral scores.: Mark missing information as a gap with assumed evidence. A middling score on no evidence looks safe on the grid but is the riskiest cell in it.
• Ending the session with a winner but no next test.: Every chosen concept should leave with its weakest-evidence lens named and a test assigned to an owner. Without that, the evaluation hardens into a premature final verdict.

References

• Examples: Worked examples and scenarios
• FAQ: Frequently asked questions
• Parent Method: Design Thinking

Related Skills

• Generating Divergent Ideas
• Building Rapid Prototypes
• Iterating from Evidence
• Synthesizing User Insights
• Framing Human-Centered Problems

Sources

• Change By Design - IDEO
• How do people define design thinking? | IDEO
• Design Thinking by IDEO: Human-Centered Innovation
• What is Design Thinking? - updated 2026 | IxDF

Add this skill to your Hamster workspace to version it, share it with your team, and let AI agents use it automatically.