Important lessons you should know before reading this course
Every prototype should have a “Research Question”, i.e. what your experiment is about. If you are yet unsure about the philosophy of prototyping, make sure to read into our main challenge on prototyping next. Ask yourself: What is the one key insight I’d like to gain by building a prototype and document your assumptions prior to building it!
Should you build one prototype at a time or many simultaneously?
This depends on the outcome of your ideation and synthesis. Is the user’s journey short? Is it possible to build your prototype with only a few screens? If you can answer both questions with a ‘hell yes’, then you’ve got your answer: Build only one prototype. Is there a long, potentially intricate user journey? Once you’ve broken down your solution to a bare minimum, are there still multiple areas your solution has to tackle simultaneously? If your answer to both of those questions is ‘yes’, your best way to move forward will be to decompose the intricate problem you are solving into a set of sub-problems which can be tested in isolation. For each sub-problem, there will be a set of assumptions that need to be true for your product to work. Test them all by building one prototype for each subset. Moreover, if you have two areas of questions, e.g. one area focussing on early steps in your app such as the signup and one area focusing on later stages such as reporting, there is no need to build a prototype including all the steps in between. Instead, build two separate prototypes.
Before building your prototype or product, there is a secret step which will drastically improve the smoothness of your process. You first want to build the “architecture” of your prototype. In your situation – being an entrepreneur who builds an early-stage product – you won’t need many sophisticated tools. The secret will be to do the one thing that will make sure you will not get stuck: User Journeys! This is the “preparation” step for all following chapters. It’s as crucial as preparing your backpack before heading into the wild.
Hint: As part of this course, you might want to skip lesson 2 and 3 of this course, but you should never skip the first lesson: You will always need to build some form of information architecture (e.g. a user journey) before building your prototype. Now, when would it make sense to skip chapter 2 and 3?
Lesson 2 is about testing your idea using paper (‘low-res prototyping’). It is a low-fi form of lesson 3 which is about testing your idea and design using prototyping tools (‘high-res prototyping’). Lesson 4 is about building a no-code version of your app (‘prototyping functional products). The key task when deciding on as to whether you build a low/high res prototype first or whether you start to directly build a no-code product is managing the trade-off between design flexibility and functionality. What a complicated explanation. Let us elaborate further
- Mock-Up prototypes (as in lesson 2 and 3) involve tools allowing you to design literally anything. The outcome will be some sort of drawing, powerpoint presentation or sophisticated, clickable product mock-up. However, the outcome will never be truly ‘usable’ by a prospective customer. All these tools help you design a silhouette of your product, but not the real product. For example, you might need a video-call or another complicated functionality. You will always be able to create some sort of paper prototype which resembles the general idea. But you will not always be able to build an actual video call functionality by using a no-code prototyping tool. Lessons 2 and 3 will be useful to you if your main assumptions evolve around the design of your product. You will need maximum flexibility in your design to validate and test those assumptions. This is when you will go with reading those lessons.
- No-code product tools, as introduced in lesson 4 of this course, are great for building, guess what, functional prototypes.Take for example an input field. A high res prototyping tool such as Figma cannot create a mockup which allows users to click into an input field such as a search bar, open their keyboard and type something. However, a no-code product tool such as Glide or Bubble allows you to build such functionalities. You may store the answer, create logins, etc. as you please. If your main assumptions evolve around the functionality of your product, you want to jump directly to lesson 4 and build a functional product as your first prototype.
There is no golden rule and the availability of features is constantly evolving in both no-code and prototyping tools. You will have to decide on an individual basis. Furthermore, you should crosscheck the prototype(s) you intend to build with your research question / critical assumptions. Go through the elaborations (1) and (2) above and ask yourself which set of tools you will need to validate your assumptions in the most effective way.
When Prototyping is Difficult: Beyond this Course
There are cases in which building a prototype that is close to the real product is inherently difficult. Examples usually include:
- Anything including AI (when the main benefit of your product is based on the performance achieved through AI, but not its core functionality)
- Rocketships and other flying (or not flying) hardware
- The Internet of Things (more hardware)
- Pharma Products, BioTech and DeepTech in general (which require more in-depth, structured research well over the capacity of EWOR).
In these cases, you might be able to create a prototype but you should consult (your) engineers as early as possible to explore what is technically possible and feasible in your current situation.