How To Build A Prototype For Your SaaS Product [Q&A with George Krasadakis]

In this week’s article, we sat down with George Krasadakis, to talk about all things prototyping, giving you the tools you need to build a prototype for your saas product!

Each product starts with an idea. 

Some ideas are good and evolve in the future into truly wonderful products that users love. However, some ideas do not turn into valuable products, mostly because there is no market need for them.

In order not to waste time and money on ideas that will not stick, we need prototypes. How to build a prototype, how it should work, or maybe you should not build it at all? We answer these and many other questions in today’s article.

Meet George Krasadakis

If you have ever wanted to meet someone who has expert knowledge in innovation, leadership, data science, product development, artificial intelligence, and software systems design – George Krasadakis is your guy!

George is a Product, Innovation, and Technology Director and Advisor and his experience is just impressive: 

• 20+ patents on data-driven systems and Artificial Intelligence concepts 
• 80+ innovative, data-intensive projects, including Data Warehousing, Data Mining, Predictive modeling 
• 4x Startup Founder 
• 20 years of product architecture, software systems design, and digital product development – from concept to launch 
• Worked for/with 10 multinational corporations in 4 markets (including Microsoft, Accenture, GSK, and Wind)
• Author of ‘The Innovation Mode’ (Springer 2020) 
• Producer and chief editor of the ’60 Leaders’ ebook series 

In this article, George shares his expert opinions with our readers. Make sure to grasp this knowledge and use it when building your software products!

What is a software prototype? 

Prototypes are used as the means to validate ideas and capture early insights and learnings that help product teams make better decisions before investing in complex development efforts. Prototypes have short lifecycles – as soon as decisions are made about the underlying concept, the prototype usually becomes obsolete.

Hence, a prototype should be fast and inexpensive to develop – it should only contain a small subset of the features of a product, the ones that are essential pieces of the overall experience and are the most uncertain – and even the included features are usually not fully implemented.

In a software context, prototyping can be done through visualizations, wireframing, clickable prototypes, or functional implementations of some aspects of the product. Clickable prototypes are based on a series of connected user interfaces that mimic the flow of the envisioned application to provide basic navigation and demonstrate the core user flows – however, there is usually no real functionality implemented. A functional prototype is a realistic, interactive implementation that approximates the envisioned product or feature and offers a sufficient level of functionality to support real user interaction.

How should I use a prototype, and what questions should it help me answer?

The purpose of a prototype is to help the product team learn and set the right focus. Prototypes are typically used in the early stages of the product development process to validate concepts and ideas in a fast and inexpensive way – before they are considered for full development. Taking an ambitious idea through the prototyping and validation process enables an early estimation of its expected impact and helps identify signals for improvements or even possible pivots — coming directly from real users or experts.

The questions that a prototype can help answer depend on the context but typically they have to do with how real users would engage and interact with the product concept and its most novel features and experiences, or how particular features of a product would fit into an existing experience, or how a complex concept would look like in a particular form factor.

Prototyping plays a vital role in setting the right focus, providing clarity, and reducing the risks associated with new product development. More specifically, a good prototype:

• Helps achieve clarity and alignment. A good prototype realizes complex concepts in simplified forms. As people have the opportunity to interact with a realistic approximation of the original idea, the broader team achieves a shared understanding of its core aspects.
• Provides the means for feedback and interaction data. The prototype is seen as an early implementation of the product, and thus, it sets the basis for qualitative feedback from users and stakeholders. In some cases, the prototype itself provides usage data through telemetry; for example, when users are interacting with a functional prototype of a web application, clicks, and other events are captured and analyzed by the team to understand how users engage and interact with the prototype. At the same time, there could be an embedded user satisfaction form or a link to a questionnaire allowing the users to submit a more structured evaluation of their experience with the prototype.
• Helps understand ambiguous aspects of a concept. Regardless of the background of the stakeholders, some concepts are difficult to explain or visualize with conventional means. A functional prototype would allow stakeholders to interact with a realistic instance and thus help drive the discussion in the right direction.
• Helps understand how users are willing to engage with novel, untested features or technologies. A prototype brings significant value when the concept under consideration has increased levels of uncertainty. For instance, when the proposed experience is new to the users, and there is no prior knowledge or baselines about the expected adoption or level of engagement. There is always the risk that a certain persona or demographic is not ‘ready’ yet — or not comfortable in general — to adopt a novel technology or feature. A quick functional prototype can provide valuable insights regarding both the technical feasibility of the concept and the expected levels of user engagement.
• Accelerates product development. Prototypes reduce the risk of unnecessary loops and wrong decisions — by enabling early user feedback. A good prototype also produces knowledge that can steer product development efforts, inspire new ideas, or even raise challenging questions that may lead to pivots.

What does not belong to a prototype?

I would exclude from a prototype any ‘standard’, conventional, or non-essential feature – these can be skipped or mocked. Normally, prototypes are not expected to meet the typical ‘production readiness’ requirements – they are typically ‘throw-away’ implementations, with a short life cycle, and hence there is no value in spending energy for formal implementation, clean code, etc. For example, prototyping teams should not spend time and energy designing complex architectures for scalability and performance. Instead, they should be reusing components and making the necessary conventions that accelerate the process of exposing a good prototype to real users.

When should I use a wireframe, when a clickable prototype, and when a prototype has logic behind it (e.g. using a no-code platform or even custom code)?

Wireframing is ideal for quick, draft visualizations that help the team increase their clarity over the core experiences, the user flow, and the structure of the digital artifacts; it is the natural thing to do in early ‘discovery’ phases and events, for example in brainstorming sessions, ideations, or when pitching new product/ feature ideas, etc.

A clickable prototype may add value when there is a more mature, holistic view of the product concept and the team wishes to communicate it to a broader group of stakeholders – in some cases, including potential users or customers.

A functional prototype would add value when there is sufficient clarity about the big picture of the product/feature to be built but also increased uncertainty and significant implementation costs involved. In such situations, a relatively inexpensive implementation of a functional prototype (built quickly by reusing components and services or by leveraging a low/no-code platform) could be exposed to a broader group of users to collect valuable feedback and interaction data that inform and influence the product development process.

How long can it take to build a prototype? How to make it as fast as possible?

This depends on the complexity of the concept to be prototyped and also on the particular prototyping strategy. I have seen good prototypes built in a couple of days but also ones that took weeks or months.

In a software context, I believe that in most cases it is feasible to develop a functional prototype in just a few days. What is very important though is to properly set the scope for the prototype (select the right features to build, and avoid unnecessary development costs) and also to have a clear strategy on how to leverage the prototype as the means for learning (the target audience, the data to collect, how to generate the needed insights, what are the possible next steps after prototyping, etc.). 

To accelerate the development of prototypes, I would recommend: 

1. Do not waste valuable resources on building non-critical components and features. Identify the most important components — the ones that are expected to generate interesting insights and learning; those that need to be exposed to real users, to capture their feedback.
2. Use static data and objects: Avoid building sophisticated data models, databases, and back-end layers; instead, simply model all your key entities as static resources, e.g. as JSON objects.
3. Use 3rd party resources: Before starting the development of your prototype, search online for building blocks and reusable components that could cover the specific needs of your prototyping project – from UI elements and controls, APIs, services, data models, data sets, images, content, or open-source components.
4. Use prototyping tools. Simple wizard-like tools can help you easily build a clickable user interface and you may leverage templates, images, chart controls, frameworks, or even pre-built user interaction components.
5. Make assumptions. Whenever you hit a difficult decision point or unknowns, make assumptions and move fast – you are aiming for a realistic experience, not for a production-ready system.
6. Reconsider Quality: When prototyping, you need to rethink quality with a focus on user experience. You are probably writing through-away code, so take the opportunity to speed up the process. For example, you shouldn’t be concerned about best practices and how well-structured and reusable your code is, or spend time commenting, documenting, or re-factoring your prototype code. Unless you are planning to further develop your prototype codebase, it should be totally fine to hard-code and use static data as needed to move faster.
7. Relax the constraints: remove production-readiness requirements and also switch to a light version of your software development rules, practices, and guidelines.

In the ‘Innovation Mode’ I am expanding the above and propose the notion of the prototype factory – a specialized organizational entity that streamlines the prototyping and validation process and offers it as a service to various teams across a company – thus improving its opportunity discovery bandwidth.

What are the best tools to quickly build a prototype?

Teams should be using existing resources – reuse them in a different context and minimize the time and effort needed to set up a functional prototype. However, this requires some readiness from the engineering team (e.g., they need to maintain reusable components, services, data sets, UI elements, etc.) and this readiness is not always there – but certain SaaS platforms can help in this direction. For clickable prototypes, any of the modern design tools can be used (e.g., Figma) while for functional ones, platforms such as Wix or Webflow provide great building blocks for rapid implementation of digital experiences. Several Low/no-code platforms provide great development tools for the quick implementation of more sophisticated prototypes (e.g., OutSystems).

What does it cost to create a prototype?

This depends on the context – the size and synthesis of the development team, the tools used, and the complexity of the product to be prototyped.

Does UX play a big role in prototypes? Should I focus on that?

Depending on the nature of the product that is being prototyped, UX can be of critical importance. UI/UX needs to be well thought-through and present the concept, the flow, and core interaction patterns in a precise way.

There is always the case that a particular UX approach heavily influences user feedback. For example, you may end up having negative feedback, reflecting not on the concept being tested, but on the particular user experiences used as part of the prototype.

It is always a good idea to test various UX approaches or try to minimize the impact of the UI itself by switching to low-fidelity visualizations and communicating to the users the nature and purpose of the prototype. But, again, this depends on the context and the objectives of the prototyping effort. 

What should I do after getting feedback using my prototype, what’s the best step?

The results captured via a prototype – interaction data, performance measurements, structured or unstructured feedback, and other data points — must be analyzed and assessed by the product team to recommend the next best action for the idea. Stakeholders—usually corporate or product leaders with a vested interest in the idea—are asked to interpret the insights and make decisions about the future of the prototyped concept. For example, they may decide to park it or pivot toward a different direction continue the experimentation process with a more thorough prototype implementation; or expose the existing prototype to broader and more diverse audiences. In a more positive scenario, the insights may suggest progressing the idea to the next stage or even taking it directly to the development pipeline.

Can a non-technical person build a prototype? What should he/she do to succeed?

Yes, provided that there is [a] a good understanding of the objectives of prototyping (e.g., what you are trying to achieve through the prototype, what is the plan, etc.), [b] product sense (e.g., understanding of product architecture, feature prioritization, and the ability to set the right scope for prototyping a concept), [c] sufficient understanding of UI/UX and [d] access to the right visual design tools and low/no-code platforms.

Thanks to George for sitting down with us and chatting about prototyping! 

If you have any questions, you can reach him at:

• https://www.theinnovationmode.com/george-krasadakis
• https://www.linkedin.com/in/gkrasadakis/ ‍

Might you have any more questions on how to build, launch, and scale your software? Book a call with us today!