Let us jump to a situation where you have done some research and are convinced that from a market perspective as well as technically your proof-of-concept (POC) is worth exploring. Now, the next step is to figure out how your solution will look like. This stage is the prototyping stage and comes before spending any further resources on building a minimum viable product (MVP) and even before you should be thinking about concluding on a product-market-fit. Prototyping is about working out (mostly visually) how exactly your digital solution guides the user from point a to point b.

Done right, prototyping has the potential to save you and your team from building an application you shouldn’t build and get confirmation on applications you should take to the next stage. How so? Let us go through some observations on why to use prototypes, how to use them, and other points to consider.

The why

• Realistic versions of your product make you go through all the details of the proposed solution which leads to further improvements and even major redesigns of the solution. It is almost impossible to find the solution components to be improved or redesigned without actually building the design. Your design path is unknown before you start building and anyone thinking to know how the design path and how the final solution will look like simply never built before.
• Realistic versions of your product allow you to conduct usability testing and gather valuable insights on what should be improved. The quality of feedback from realistic prototypes is higher compared to the quality of insights obtained when test subjects are given conceptual sketches.
• For product ideas where data-driven decision-making is possible a prototype is a great tool to extract feedback from customers. However, many products or features are novel with user testing going beyond where to place the action button and into whether the user will use your software at all. In these cases, we require opinion-driven decision making and well-designed prototypes are again an excellent tool to reevaluate your intuition of how the application really feels and whether you should put your resources into it.

The how

• Based on your use case and design resources accessible choose the right prototyping technology (Hint: Evaluate especially no-code tools on top of UI design tools). A designer should be able to explain the choice of the right product design tool and master the features of the chosen tool to unlock the true value of prototyping.
• Understand the domain in which the solution resides and engineer a solution that solves the identified domain problem with great design. The domain usually requires an expert system which you create yourself or leverage from. The expert system will determine the design and architecture of the solution. Merging then the solution with great design (potentially using a design system to speed up the process) is the next challenging part as budgets and skills often run dry when you get to the design part.
• Dive into the psychology of people to understand how to design an application that people actually use. It is surprising how general design principles and decade-old research still summarizes what you should and shouldn’t do more understandable than some modern articles and blog posts — For example, get your hands on a copy of Human Interface Guidelines: The Apple Desktop Interface, published in 1987.

Points to consider

• Each time you upgrade your prototyping approach, including your stack of technology, ask yourself, how does this improve the quality and time-to-market of your software? This question will spare you from wasting time and resources on the wrong approach and technology and make you a better product designer.
• Let the product, design, and development team look up from their immediate tasks to understand what marketing, sales, legal, etc. are doing. This may lead to making necessary adjustments to the prototype that will save the product from failure as it goes through the rest of the development and launch stages. (see on that topic Build: An Unorthodox Guide to Making Things Worth Marking by Tony Fadell).
• Always establish a connection between your solution and the wider company and product vision. Learn from the things that benefited the ultimate success of past prototyping projects.
• Double-check with engineering whether the updated design is still doable from a technical perspective as established during the POC phase. In particular, your customers may have introduced many ideas while involved in co-creation sessions.
• Be bold enough to set projects aside or entirely walk away from certain ones after your prototype does not deliver the results you hoped for. On the other side, if things go well, move projects up your priority list if a prototype is convincing and adjust your roadmap.

If you want to receive more insights into the workflows of designing digital solutions in the transfer pricing or international tax domain the experts at Aibidia will be glad to share additional learnings gained in dozen ongoing projects in different stages of early stage development.