Three circles with the words desirability (humans), feasability (tech) and viability (business). The word "goal" is at the intersection of the three circles.

From Prototype to Product: Ensure That Your Solution Is Feasible and Viable

by Rikke Friis Dam and Teo Yu Siang | | 18 min read

The end goal of a design thinking process is to create a solution that is desirable, feasible and viable. This means that your product should satisfy the needs of a user, be feasible to implement and have a financial model as well. During the bulk of your design thinking process, you’ll focus on desirability as you are concerned with testing your ideas and validating your hypotheses about your users. Towards the end of your project, however, you should bring the focus to feasibility and viability so that your solution can be sustainable. Let us now look at the best ways you can make sure that your design solution is feasible and viable, on top of being desirable to your users.

How to Ensure Your Solution is Feasible

Three intersecting circles labeled 'Desirability (Humans)', 'Viability (Business)' and 'Feasibility (Tech)'. The circle labeled 'Feasibility (Tech)' is shaded, while the other two are in outline.

© holder: Teo Yu Siang and the Interaction Design Foundation:CC BY-NC-SA 3.0.

Feasibility is about whether you can effectively implement your solution. Technically, anything is feasible, depending upon how much time you have. Adding a new feature or building a new app shouldn’t take years and years (although some have). However, colonizing Mars… That’s going to take a lot more time and effort. It’s important when starting out the design process to not get too caught up in the technical implementation. This is so you don’t restrict innovation. However, you should, earlier than even at this stage, communicate with your developers about your ideas so as to come to a compromise that the whole project team can live with.

To start thinking about the feasibility of your solution, focus on two main areas that impact implementation:

  • The capabilities you need for pulling off the solution (developers, code libraries, etc.)

  • Distribution channels to get your solution to your users (marketing)

Think about these two factors for each of your solutions and organize an exercise to discuss them with your teammates.

How Will Your Solution be Distributed?

Illustration of dots spreading out with dotted lines connecting them.

© holder: Teo Yu Siang and the Interaction Design Foundation:CC BY-NC-SA 3.0.

Distribution channels are the ways your users get to access, purchase or use your solution. Discuss with your team the possible ways your users can experience the solution. Where would they go? When and how would they experience the product or service? Why would the user want to gain access to your product? From these questions, think of as many alternative distribution and delivery possibilities as possible. If your company has a marketing or sales department, they will be an undeniable asset here.

Make a list of potential people and channels that will be involved to deliver the solution to your users. If your solution is a physical product, would you send a pack and deliver it with your team of delivery people, use the post office or engage with private courier services? Would you use a marketplace such as Amazon to reach your users, or would you prefer to set up your own website (or both)? If your solution is for hospital patients, will a doctor or a nurse administer it? Are there other channels, conventional or unconventional, that you might use to deliver your solution?

Think of the pros and cons of each delivery method. Consider how each method affects the user experience as well as the profits of your company.

What Capabilities Do You Need to Create and Deliver Your Solution?

Make a list of the personnel, manufacturing, financial and technological capabilities you will need to create and deliver your solution to users. For each capability, note down whether they exist in your organization. If they do, think about how you can see your solution added to your organization’s workflow and resource pool. If not, make a list of potential external sources of these capabilities in organizations and networks you can tap on, such as third-party contractors and service providers. Also, consider if your organization should build up its capabilities to create and deliver your solution.

For instance, if your design solution is a mobile app, then some capabilities you require are: designers with experience in mobile apps and developers who can create applications on popular operating systems such as Android and iOS. Do you have such talents in your organization? If not, does it make more sense to hire new people to your team or engage with third-party UX consultancies and development houses?

How to Ensure Your Solution is Viable

Venn diagram of Desirability, Feasibility, and Viability. The Viability circle is highlighted.

© Teo Yu Siang and the Interaction Design Foundation, CC BY-NC-SA 3.0.

The commercial viability of your product will determine its long-term success. This is true even for nonprofit organizations and projects, because commercial viability will ensure that your solution will continue to work even without constant inflow of funding from donors or governments.

To conduct an evaluation of your solution’s viability, you should analyze the value proposition your product or service provides, think of potential revenue sources and consider various stakeholder incentives you can use.

What Customer Value Does Your Solution Provide?

Together with your team, think of the value that your solution provides to users. Does it provide convenience to your customers, therefore helping them save time? Does it provide safety that previously did not exist in a task? You can refer to your prototypes and notes that you have taken down in past testing sessions with users to find out what elements of your solution they find the most important or useful.

Next, try to figure out how much your users will pay for the value your solution provides. You may rely on past prototyping and empathy-gaining sessions with users, which may shed some light on how much they are willing to spend. Alternatively, you can consult experts or internal stakeholders who may have a better idea of how much your solution is worth.

What are Your Revenue Sources?

Depending on whether your solution is a product or service, or a mixture of both, it can have different sources of revenues. Together with your team, identify all the actors that will pay for the solution. How much will each actor pay for the product or service? For instance, if you are working with the government to implement a new service to people in need, will the government be paying for the full cost or will the end users co-pay a portion of the price?

Also, think about how users will make payment. Depending on the industry conventions, the country you are delivering your solutions to and the needs of the users, you may want to accept cash, credit or payment in kind for your solution. Besides the payment mode, you should also think about the most appropriate payment structure for your solution. Examples of possible payment structures include the following:

  • Membership, where users pay a regular fee (monthly, yearly, etc.).

  • Commission, where you earn a percentage of transaction fees enabled by your solution. (You can earn commission from the user or the user’s customer, or both.)

  • Give the product but sell the refill, to encourage adoption of your solution and earn revenue once users become repeat customers.

  • Subsidize the price of the solution, possibly in collaboration with the local government.

  • Pay-per-use, where you charge a fee for every time a customer uses your solution.

What Incentives Do Stakeholders Possess?

Identify all stakeholders your solution will affect. Discuss with your team if the solution provides value to each stakeholder involved. On the other hand, does your solution increase the costs to some stakeholders?

Go through each stakeholder and find out if they have any incentives or disincentives to adopt or help you with your solution. For example, if your solution helps supermarket goers get even more value while shopping, would adopting your solution create a disincentive for supermarkets? Consider how the proliferation of private-hire cars via companies such as Uber and Lyft had prompted strong lobbying by the taxi industries in many countries, and how it can impact the profitability of Uber and Lyft. Would your solution face similar problems from stakeholders who would be disincentivized to help you? If disincentives exist for stakeholders, try to think of ways in which you can tweak your product in order to encourage their participation.

Test It Out: Launch Live Prototypes and Pilots to Test Your Solution’s Feasibility and Viability

Launch Live Prototypes to Test Aspects of Your Solution in the Market

After you and your team have gone through assessing the feasibility and viability of your solution, you may want to launch a live prototype to test your solution in the market. We use live prototypes to test parts of our solutions in real-life environments and conditions.

To begin, determine what aspect of your solution you want to test. For instance, you could focus on the distribution model of your solution or getting users to know about your product. This works like a normal prototype, where the first step is always to determine what you want to test.

After you have a firm idea of what to test, you will then need to lay out the logistics behind your live prototype. Remember that you need to launch live prototypes in real-life conditions. Given that, you may need to rent some space, get materials to build a kiosk or apply for government permits. If your solution is a service, you may need to create uniforms and hire service personnel.

After you have figured out your logistical plan for the live prototype, launch it. Live prototypes can last for days or weeks, depending on your needs. During the live prototype launch period, continually take down notes and user feedback that you have gained. If there are areas that went wrong, try to improve them during the live prototype testing period and see if the improved iteration works better. Constantly gather feedback, iterate your prototype, and then test to see if it works.

At the end of the live prototype, gather all the useful feedback you have gained from users and other people involved in the process. By now, you should have a good feeling as to whether your solution satisfies the three parameters of desirability, feasibility and viability. When you feel confident in your solution (perhaps after a few runs of live prototypes), you are ready to launch a pilot of your product or service.

Conduct a Pilot of Your Solution

While you use live prototypes to test aspects of your solution, you use pilots to test the entire system of your solution. In a pilot test, you’re testing if each component involved in creating and delivering the system works well with other components, and if the entire scale of operations can run smoothly. In other words, your pilot test should give you a firm idea of whether the solution would work in the long term.

The first step in launching your pilot is to make sure you have a solid logistical plan for your product. Consider all the parties involved—manufacturers, distributors, retailers, etc.—as well as pertinent aspects, such as legal considerations. If your solution is involved with food products, for example, you may need to apply for a food permit.

Next, consider your marketing plan. While design thinking might not sound compatible with marketing, the success of your solution is going to rely heavily on sound marketing. Brainstorm and strategize on how to market the values of your product to potential customers. Compare your solution against the existing offerings in the market, and list down the key competitive advantages you have. You can use user insights you uncovered during the Empathize stage of your design process to help you identify the best ways to target and engage your potential customers. At this point, it is also useful to think about the various metrics that you should monitor during the pilot program.

The next step is to launch your pilot. Collect feedback from users and other parties involved to figure out what works and what doesn’t. You can make changes to your product or service during the pilot phase, but ideally you should keep the number of tweaks to a minimum. That’s because the point of a pilot is to tell you which parts of the system are working, and which aren’t. Making too many changes might make it difficult to tell whether the system is working; indeed, any scientist will tell you that changing more than one variable in an experiment will cause confusion. Your pilot can last for months as you test both your solution and how it reacts with real-life market forces.

If your pilot is a success, congratulations! Your solution is ready for shipment to the market!

Do You Always Need to Run a Live Prototype or Pilot?

No. If your product is relatively simple or you are confident, you don’t need to create a live prototype or pilot. After all, these are expensive programs to run. For example, if your design solution is a mobile app or a new feature on your website, you should be fine with directly launching your solution after you conduct some user tests.

Live prototypes and pilot programs are useful when you’re solving a wicked problem. This is when there are no clear solutions, and you have to deal with a system of multiple parties who often have different motivations. In such a scenario, when you are uncertain whether your solution will work within the market, a live prototype and pilot program can save you money in the long term. You’ll spend a portion of the full cost required to launch the solution and get realistic feedback about whether it’ll work.

After the Pilot: Formulate a Learning Plan to Combine Analysis and Synthesis

Learning plays a central role throughout the design thinking process. As you begin to implement your solutions after a successful pilot run, you should make sure that learning remains a key part of your organization. After all, design thinking is a long-term process that will continually help you improve your offerings.

After your product launches, you and your team should continue collecting stories from users and gathering their feedback. You can compare the stories you have collected at the early stages of your project with those collected after the project has launched. That way, you can see the impacts your solution has made on people’s lives. The feedback you gather will also help you constantly improve your product.

This ties back to how we design thinkers have to constantly switch between analysis and synthesis. In analysis, you collect and analyze data to gain a fine-grain picture of the problems you are solving. In synthesis, you look at all the notes you have taken and find patterns and themes that will help you generate new ideas and solutions. When you actively collect stories and feedback after your solution has been launched, you are performing an analysis of your solution’s performance. Using this information, you can then synthesize ways to iterate your product or service.

Illustration of Analysis and Synthesis.. An arrow goes from analysis to synthesis and then another arrow goes from synthesis to analysis in a circular format.

© Teo Yu Siang and the Interaction Design Foundation, CC BY-NC-SA 3.0.

The Take Away

Throughout a large portion of your design thinking process, you will focus on the desirability of your solution—i.e., whether it meets the needs of your users. However, towards the end stages, you will need to focus on feasibility and viability as well. To think about your solution’s feasibility, consider distribution channels, capabilities you require and your potential partners. To evaluate your solution’s viability, think about what value you provide to users, your potential revenue sources and the incentives for your stakeholders. Finally, if your problem is wicked and complicated, conduct sessions involving small, live prototypes to test your solution in real-world conditions, then launch a pilot to test how it works amongst the entire system. Always keep learning a vital part of your organization, by noting down user stories and feedback as well as tracking key performance indicators and outcomes.

References & Where to Learn More

IDEO, Live Prototyping

IDEO, Pilot

IDEO, Human-Centered Design Toolkit, 2009

Open Access - Link to us!

We believe in Open Access and the democratization of knowledge. Unfortunately, world class educational materials such as this page are normally hidden behind paywalls or in expensive textbooks.

If you want this to change, , link to us, or join us to help us democratize design knowledge!