4.3 Evaluating Solution Concepts

4.3.1 Solution–Problem Alignment

4.3.1.1 A solution can work perfectly and still address the wrong problem

Imagine a neighborhood coffee shop that discovers customers are frustrated in the morning. The owner installs a faster espresso machine, trains staff to make drinks more quickly, and celebrates when average preparation time falls. Yet complaints continue because customers are most frustrated by not knowing which order is ready for pickup. The equipment improvement may be real, but it does not fully address the experience the owner hoped to improve. Technical performance and problem–solution fit are related, not identical. We can become very good at a task that was never the main obstacle.

Solution–problem alignment asks whether the proposed design actually responds to the particular difficulty supported by evidence. The question has several parts. Who experiences the problem, and in which situation? What change in that person's experience would count as meaningful improvement? Which part of the concept is supposed to produce that change? What important barriers would remain untouched? These questions return us to the discipline of Module 2. A prototype is not an excuse to stop listening simply because there is now something tangible to show.

Dorst's (2011) analysis of design reasoning helps explain why this evaluation may require returning to the way a problem was framed. A design can perform well inside a narrow frame while failing to help the larger situation. If the coffee shop originally framed the issue as “drinks are too slow,” a more useful framing might emerge from the feedback: “Customers are uncertain about when and where to collect completed orders.” That change could lead to better pickup signs, clearer order identification, a revised counter layout, or communication rather than another equipment purchase. Reframing is not indecision. It is a response to evidence that the original explanation may have been incomplete.

4.3.1.2 Trace the promise all the way to the experience

One method of evaluating alignment is to follow a chain of reasoning from the observed problem to the proposed improvement. Start with the evidence-supported difficulty, identify the affected people and context, name the desired outcome, describe how the proposed solution is supposed to create that outcome, and identify the evidence still missing. The chain is strongest when each link can be explained without relying on wishful language. “Our app uses AI” is not an explanation of how students will get better advising. “The app presents approved information in plain language and provides a clear route to a qualified advisor for nonstandard situations” is closer to a mechanism that can be examined.

Consider Elena's clinic. Suppose her team prototypes a one-page appointment checklist. The design may reduce confusion about required paperwork, but it will not create a bus route or change someone's work schedule. That does not make the checklist useless. It clarifies the problem segment the checklist might address and the limits of the promise. A strong solution can be deliberately narrow when its value is real and its boundaries are honest. The error would be using an improvement in one area to declare that all appointment-related difficulties have been solved.

This is where Module 3's systems thinking matters again. Even a well-aligned feature needs a channel through which people receive it, someone responsible for keeping it accurate, and an arrangement that works with the organization's other obligations. A solution may improve user understanding but create more manual work than the staff can sustain. Another may make a process faster but introduce an unacceptable confidentiality concern. Evaluating alignment therefore means examining the desired outcome and the broader system that makes the outcome possible.

4.3.1.3 Comparing concepts without manufacturing certainty

Students sometimes assume that selecting an idea requires a mathematical score. Scores can help us make criteria visible, but they can also make uncertain judgments appear more scientific than they are. Imagine a team comparing a printable checklist, a staff callback option, and an automated reminder tool. It gives each idea a score for convenience, cost, accessibility, and likely effectiveness. The scores may look precise, but what do they mean? Were they based on relevant observations, staff estimates, published information, or personal intuition? A score without a source is often only a belief in numerical clothing.

A better comparison makes the evidence status explicit. The team might know that printed materials can be distributed through current clinic workflows. It might have preliminary observations suggesting that patients appreciate concise instructions. It may have no evidence about whether an automated reminder would improve attendance. It may know that any live communication system needs privacy review. This approach does not guarantee the correct choice, but it prevents the appearance of certainty from replacing actual understanding. McGrath's (2010) discovery-driven approach to business models emphasizes learning under uncertainty rather than treating the first plan as settled truth; the same caution applies to solution choices.

The point of the comparison is not to prove that the checklist is best. It is to make visible which claims are supported, which are uncertain, and which test could be responsible next. We also learn that concepts can complement one another. A clear checklist may help some people while a human support route helps others. A design may need to preserve choice rather than force every person through the same channel. A strong evaluation looks for the smallest credible improvement while respecting the diversity of the people affected.

4.3.2 Interpreting Prototype Feedback

4.3.2.1 A favorable reaction is not the same as demonstrated improvement

A team unveils a redesigned campus website. Several students praise its clean layout, large buttons, and modern appearance. Someone says it looks much better than the existing page. These responses may be encouraging, but they do not tell us whether students can complete the tasks that matter. The revised website may be more attractive while concealing important information. A participant may report liking the colors yet fail to find a tuition deadline. Preference, task performance, actual outcomes, and willingness to pay are different concepts; evidence about one should not be silently presented as proof of the others.

This distinction is especially important because people frequently want to be supportive. They may tell a student designer that an idea is great because the student worked hard or because the conversation feels uncomfortable. They may genuinely like a demonstration while knowing they would never change their behavior to use the completed service. A designer should appreciate encouragement without allowing it to determine the next investment. Observing whether someone can find information or understand instructions may be more useful than counting positive adjectives.

Research on prototyping indicates that prototypes are valuable for learning and stakeholder communication, not that any single prototype can settle every question about a final product (Lauff et al., 2018; Lauff et al., 2020). This means we should always relate feedback to the actual purpose of the representation. A paper interface can help us learn about comprehension and navigation; it is weak evidence about reliability under high demand. A role-play may reveal confusing responsibilities; it does not establish staffing capacity across an entire semester. An early sample product may help someone assess comfort; it may not reveal durability after months of use.

4.3.2.2 Contradictions and unusual responses can be useful

Imagine that six participants navigate a paper registration form successfully and one person cannot. A team focused only on average performance may dismiss the difficulty as an outlier. Yet the person might use a screen reader, have limited familiarity with college terminology, or face a situation not represented in the sample task. That observation could expose an important problem. Conversely, an individual participant might struggle for a reason unrelated to the design, such as misunderstanding the test instructions. Responsible interpretation asks what the unexpected result might mean and what additional inquiry is warranted rather than immediately declaring success or failure.

A useful feedback record separates observation, participant explanation, designer interpretation, and planned follow-up. For example: “The participant clicked three labels before finding the deadline” is an observation. “I expected it under Registration” is the participant's explanation. “Our category names may not match user expectations” is the designer's interpretation. “Compare two clearer label options with relevant participants” is the proposed next step. Each line has a different evidence status, and keeping them distinct helps teams avoid turning assumptions into facts.

This distinction becomes vital when teams disagree. One team member may insist that the participant was careless; another may blame the interface. Neither interpretation should win simply because its advocate speaks confidently. We can document what happened, identify alternative explanations, and design a fair next observation. In Module 5, we will deepen this reasoning through hypotheses, metrics, and experiments. Here we are developing the underlying habit of intellectual honesty: evidence deserves interpretation, but interpretation should not pretend to be evidence.

4.3.2.3 Small observations need appropriately small conclusions

It is tempting to say, “We tested our design, and users love it.” But who were the users? What were they asked to do? How many participated? Was the test simulated? Did anyone encounter accessibility barriers? Were participants offered a real choice, or did they simply respond to the only concept they saw? These details determine what conclusions are reasonable. A few informative observations may reveal an obvious problem or inspire a valuable change. They cannot, by themselves, establish population-wide preferences or guarantee that a new service will be adopted.

The goal of a first prototype review is usually diagnostic learning—discovering what may be confusing, incomplete, or worth examining next. That is different from making a reliable estimate of how often something will occur across a whole market. A teacher may learn from several students that the instructions for an activity are unclear; that finding may justify improving the instructions without claiming that all students nationally will respond the same way. A founder may learn that the wording on a booking page confuses interview participants; that is useful, but it is not proof of revenue demand.

The academic value of this restraint is substantial. It teaches students to calibrate their confidence to the evidence available. Sometimes an observation supports an immediate low-risk improvement. Sometimes it signals the need for expert review. Sometimes it reveals that the problem was framed incorrectly. The most mature conclusion may be, “We learned something, but not the thing we originally expected.” That is not a disappointing outcome when the purpose of a prototype is to improve understanding.

4.3.3 Iterative Improvement and Responsible Next Steps

4.3.3.1 Iteration means changing an idea for a reason

Iteration is the process of revising a design in response to evidence, constraints, or new understanding. We often imagine it as a series of increasingly polished versions: sketch one, mockup two, prototype three, finished product four. But improvement is not necessarily linear. A later version may be simpler. A team may abandon a feature it once considered essential. It may return to an earlier problem statement or choose an entirely different approach. A good iteration has a purpose, even when that purpose is to discover whether the previous interpretation was mistaken.

Imagine Elena's clinic reviewing a fictional checklist prototype. Participants find the instructions clearer but still do not know whom to contact if a required document is missing. The team could add more paragraphs, but that might make the page harder to read. Another possibility is to improve the contact pathway and clarify what information staff can provide. The next version should be connected to the observed difficulty, not merely to the team's desire to add features. Design learning happens when a specific change is tied to a reason and examined in context.

Dow and colleagues' (2010) research on parallel prototyping offers a useful caution against refining one concept so deeply that alternatives disappear. Some projects benefit from revising a promising option; others benefit from comparing several possibilities before deciding which deserves further effort. The skill is not endless iteration. It is the ability to recognize when to refine, when to reconsider, and when to stop. Time and resources matter, but so do safety, user trust, and the opportunity cost of remaining attached to a weak concept.

4.3.3.2 The next action should match the biggest uncertainty

A team can leave a prototype review with twenty suggested improvements. Which should it address first? One practical principle is to prioritize the uncertainty that could most seriously undermine the promised value or create harm. If people cannot understand the main task, improving animations is unlikely to be the best next step. If a service cannot be delivered safely, adding a new booking channel is premature. If a process depends on staffing the organization cannot provide, a more elegant interface may make an impossible promise more attractive without making it achievable.

A useful decision conversation asks four questions. What have we learned? Which claim remains most uncertain? What consequence would follow if that claim proved false? What is the smallest responsible next inquiry that could reduce the uncertainty? These questions link Module 4's design work to Module 5's explicit experimentation and Module 6's financial analysis. They also prevent the team from turning every suggestion into a requirement. A designer can appreciate a participant's idea without accepting a new obligation to build it.

Consider a hypothetical comparison. A prototype for a service booking page produces two findings: some people dislike the font, and several cannot understand the cancellation policy. Font preferences may be relevant, but uncertainty about cancellation responsibilities could cause disputes and loss of trust. The second concern may deserve priority even if it attracts fewer comments. A strong team evaluates consequences, not just frequency or emotional intensity. When necessary, it consults qualified people before moving to a real offering.

4.3.3.3 Choosing to pause, simplify, or stop

Our culture often treats innovation as a race: whoever builds first wins, and whoever pauses loses momentum. But responsible design sometimes requires a deliberate pause. A team may discover that it lacks access to the users needed for meaningful feedback. A proposed feature may rely on inaccurate data. A service may expose people to risks the organization is not prepared to manage. A new concept may duplicate an existing solution that already serves the intended users well. In such situations, pausing or stopping can be evidence of sound judgment rather than a failure of courage.

An idea can also be simplified in a way that increases its value. The mobile bicycle-repair founder might initially imagine a complete maintenance subscription, 24-hour roadside dispatch, custom app, and broad service area. Early learning may suggest that a clearly bounded scheduled service for a narrower group is more realistic. An internal college team might abandon a new portal and improve an existing page. Neither decision is automatically less entrepreneurial. A focused design may be more inclusive, more sustainable, and easier to evaluate than an ambitious concept with contradictory promises.

In the next module, you'll learn how to specify assumptions and run more deliberate experiments. For now, understand the kind of judgment Module 4 has helped you develop: making something tangible is the beginning of a conversation with reality, not the end of it. When you can explain why a design is changing, what uncertainty remains, and what you would need to learn before expanding, you are practicing entrepreneurial thinking in a rigorous and transferable way.

Entrepreneur-in-Action

Berkeley's Curb Ramps: Redesigning the Environment Instead of the Person

In the late 1960s and 1970s, disability rights advocates in Berkeley, California, confronted streets and sidewalks that made independent movement difficult or impossible for many wheelchair users. The problem was not that people needed more motivation to navigate a high curb. It was that the environment itself created barriers. Activists including Hale Zukas pressed for changes, and disability advocates also built makeshift ramps to demonstrate and address the obstacles they faced. The Smithsonian National Museum of American History documents the grassroots efforts of Berkeley's Independent Living Movement to create more accessible routes (Peterson, 2015).

The design challenge was practical and deeply human: how could a public environment provide safe, usable passage for people who had been excluded by the existing arrangement? Berkeley's work helped advance curb ramps, but the history also reveals why a solution must be examined in context. An oral history with Zukas describes how designers considered the needs of people with different disabilities, including the importance of features that could alert people with visual impairments when they approached a street (University of California, Berkeley, n.d.). Improving access for one group should not create an avoidable new hazard for another.

Today curb ramps are familiar. Their usefulness extends beyond wheelchair users to people pulling luggage, pushing strollers, or transporting goods. That broader benefit is sometimes called the curb-cut effect, but the historical achievement should not be reduced to a convenient marketing analogy. Disability advocates fought for access and civil rights, not merely for a feature that happened to benefit shoppers. For students of entrepreneurship, the case illustrates what becomes possible when affected people are treated as knowledgeable contributors and the design problem is placed in the environment rather than blamed on those excluded by it (Blackwell, 2017).

Think about it: What if a university had defined the challenge as “teach wheelchair users to navigate existing curbs more efficiently”? How would that frame have limited the solutions? What could a designer learn by listening to the people who experienced the barrier every day?

See all 24 entrepreneurship case studies →

What Can You Do?

Learn From the Curb-Cut Effect

The Berkeley story provides a historical lesson you can apply without starting a business or building physical infrastructure. Think of a routine process in your school, workplace, or community that works adequately for some people but creates unnecessary obstacles for others. It might involve forms, office hours, unclear instructions, transportation, navigation, or access to assistance. Begin by describing the barrier as a condition of the environment rather than as a personal weakness of those who struggle with it. Then identify at least two different groups who may experience the process differently and what you would need to learn from them before proposing a change.

Imagine that a campus service can be reached only by telephone during traditional business hours. An easy first conclusion is that students should remember to call earlier. A more human-centered analysis asks how the schedule affects students who work shifts, have hearing-related access needs, or must care for family members. You might consider an accessible appointment request option, clearer published hours, an approved callback process, or a partnership with an existing support office. The point is not to declare one answer correct. It is to examine the design of the environment, consider meaningful alternatives, and identify who should be involved in evaluating them.

As a final reflection, ask what would change if the people who face the greatest barriers were invited to help define the problem rather than asked only to react to a finished solution. In the curb-ramp story, affected people did not merely provide feedback after someone else decided what mattered. They advocated, organized, and contributed expertise about how the physical environment needed to change. That is a model of participatory problem-solving that applies to workplaces, community organizations, and entrepreneurial ventures alike.

AI Advisor · Coming soon

Prototype & MVP Advisor

Coaching on your solution concepts, your prototype plan, and what your feedback really shows.

What to bring

• Your problem statement and the design criteria you drew from it (4.2.1).
• Two or three solution concepts, not just your favorite (4.1.3).
• Your prototype plan, or what you observed and heard when people tried it (4.2.2, 4.2.4).

What the advisor does

• Traces each concept back to the problem and design criteria, and flags features that skip past the outcome (4.2.1, 4.3.1).
• Checks that your prototype asks one clear question, uses the simplest form, and is labelled honestly (4.2.2).
• Tests whether your MVP is the smallest responsible offer you could actually deliver and support (4.2.3, 4.2.5).
• Separates what people said from what they did, and keeps small observations to small conclusions (4.2.4, 4.3.2).
• Looks at accessibility and unintended consequences, and ends with a next step: iterate, simplify, pause, or stop (4.1.5, 4.3.3).

What it won't do

• Grade you, or pick the "winning" concept for you.
• Invent user feedback, test results, or data.
• Approve tests involving health, safety, food, or private data: it points you to the right approvals.

Coming soon

About this advisor

A coach, not a grader: the work and the decisions stay yours.

Emerging practices

From Faster Building to Better Learning

AI-assisted coding, digital twins, interactive mockups, and no-code platforms are making it easier to transform an idea into a convincing demonstration. This may reduce the cost of exploration, but it also raises the value of evidence literacy. A student must still ask which parts are simulated, whose needs the design reflects, what safety or accessibility review is missing, and whether a positive prototype reaction justifies any claim about real-world adoption. Emerging practices will continue changing the speed and form of prototyping; the deeper discipline remains remarkably stable. Choose a meaningful uncertainty, represent the idea honestly, learn from the people affected, and make the next decision in proportion to the evidence.

Module 4 Summary: From Knowing the Problem to Learning About Possible Solutions

At the beginning of this chapter, we asked whether a bridge was really the answer to a difficult river crossing. The question was never meant to discourage ambitious ideas. It was meant to remind us that a solution only becomes meaningful when it serves the underlying need. In Module 1 you developed the habit of noticing opportunities; in Module 2 you practiced understanding people and evaluating problem evidence; in Module 3 you learned to connect value promises to the organizations and resources required to deliver them. This module added the creative discipline needed to move from a promising problem to responsibly examined alternatives.

We learned that design thinking is not just the work of artists, engineers, or technology founders. It involves empathy, problem framing, divergent exploration, deliberate selection, and iterative learning. We distinguished features from outcomes and prototypes from operating offerings. We saw why a rough representation may sometimes be more useful than a polished presentation, why usability observations can reveal problems that compliments conceal, and why accessibility and safety belong at the beginning of design rather than the end. We also learned that the ability to pause, simplify, or reject an idea can be part of sound entrepreneurial judgment.

Elena still has not proved that a revised clinic process will improve appointments, nor has Sam demonstrated that a bicycle-repair business is ready to operate. What they have gained is a better way to ask which solution deserves the next investment of attention, time, and resources. That's real progress. The next step is not to declare a winner; it is to design an honest test of the claim that matters most. Module 5 will take us from prototypes and preliminary feedback into experimentation and evidence-based validation.

Key Terms & Definitions

Review Questions

1. Why might a solution that works exactly as designed still fail to create meaningful value? Explain using a situation from a workplace, profession, or community organization.
2. How does reframing a problem change the range of possible solutions? Give two different How-might-we questions for the same observed difficulty and explain how they might lead to different designs.
3. Distinguish divergent thinking from convergent thinking. Why can it be useful to generate and compare several ideas before developing one in detail?
4. Explain how a sketch, prototype, MVP, pilot, and finished service can be different. Which kinds of evidence can one provide, and which kinds of conclusions would still require further investigation?
5. What should a responsible designer do when feedback indicates that a concept is attractive but may be difficult to use, inaccessible to some participants, or impossible to deliver safely?

Discussion and Reflection

The first idea isn't the only idea. Choose an everyday frustration you have experienced at work, school, or in your community. Without choosing a winner, describe three different categories of possible solution: a communication change, a process or relationship change, and a technology-assisted change. Discuss what you would need to understand before judging them.

The problem behind the complaint. Consider a manager who says, “Employees never follow the process.” Identify two alternative explanations involving the process itself. How might reframing the problem change the ways the organization could respond?

What can a prototype really tell us? Imagine a team presents an attractive clickable demonstration of a new student advising portal and receives enthusiastic feedback. Explain what may have been learned and identify at least four important claims that have not yet been established.

Designing for more than the average person. Discuss a product, form, service, or physical place that might be easy for some people to use but difficult for others. What perspectives should be included in defining and evaluating a redesign, and what might be lost if they are not?

The cost of an unfinished promise. Compare a website that allows people to request an appointment with the full service required to keep that appointment. Which capabilities, policies, communications, safeguards, and partners might be necessary before a real customer can responsibly rely on the offer?

References