Do you need a prototype? Find out in this article
Businesses are always looking for ways to launch apps quickly and with minimal development costs. There are various ways to do this: sketch your app design, launch apps from scratch with frameworks, or use builders. Different situations call for different solutions.
In this article, we will tell you about the approaches we use at IceRock. Our company specializes in outsource development of mobile apps, so we constantly look for new ways to speed up the development and enhance tried-and-true workflows.
Why a Prototype is Better than a Screen Map
Before we start the development, we prepare one or several prototypes of the future app. This is more efficient than going straight to design or starting to develop the app right away.
A screen map is a set of images showing all app screens and their relationships. It visualizes the flow of the screens, but it doesn't allow you to get a feel for the result and understand how usable the interface will be. In other words, it is less illustrative.
Clickable prototypes are more informative. We divide prototyping into two parts: we use a "wireframe prototype" before the design, and a "design prototype" after. A wireframe prototype is a schematic prototype that helps us understand the navigation and functionality aspects of an app. A design prototype is a product assembled once the UI design is complete. It is used to demonstrate the future app to the customer, for marketing purposes, and sometimes for testing. It also shows the developers how the final app is supposed to work.
After the design, we make a clickable prototype. The level of detail in this prototype can vary according to the client's needs: it can be low-fidelity or high-fidelity.
Low-fidelity prototypes consist of static images with active links to the next screens on the buttons. This is the type of prototype we used for the Snow4u project.
High-fidelity prototypes are very similar to the app and fully interactive: you can type any text in the input fields, there are animations and transitions between the screens, and sometimes they can even perform complex calculations, such as commission on loan returns or currency conversion. For example, when developing the Ambit app, we created a high-fidelity prototype to work out all the little details of the interface.
The prototype explains the processes in the app better than the screen map thanks to its immersive nature. When used in a large project, a screen map turns into a maze that’s hard to navigate and blurs the logic of the app. But with a prototype, you focus on one screen at a time: the customer or developer just clicks the buttons as if the prototype were a full-fledged app, and everything becomes clear. As a result, the developer and the customer get a vivid example of the desired result, with a clear picture of how the elements would behave in different situations. This way you can solve most UX-related issues before development even starts.
When One Prototype Just isn't Enough — So You Make Several!
There are cases where it's more convenient to make several prototypes. This is what we did for the Primetime app, for example, which is used for online orders and food delivery. We created separate prototypes for different types of orders and payment methods: first we made a prototype for pickup orders from food trucks, then another prototype for takeout orders, and a third prototype just for adding payment methods. The fourth and last prototype was for loading animations. Technically, this task could have been implemented within a single prototype, but in practice it was faster to build separate ones.
We chose this approach because Primetime was a complex app with several modules built over time, so we developed a dedicated prototype for each module. This approach allowed us to start developing one prototype while experimenting with the next one. This kept the experimenters from interfering with the programmers who were implementing the app based on the first prototype without any confusion. As we had separated the prototypes initially, we organized many subsequent stages along the same lines.
As things stand, it only makes sense to use this approach for large projects. What's more, prototyping tools are evolving: at the time, this was the only optimal solution for a project of this scale. Nowadays, we tend to develop a single prototype for multiple use cases, an option made possible by the new features of ProtoPie, where we create our prototypes.
Recently two of my "for fun" prototypes have been featured by ProtoPie. The first one lets you make a wizard move around using loud sounds. And the second one is a prototype for games from the Squid Game series.
Here's another case study. Before developing an app for Russia Running, a sports event platform, we created a prototype that became the basis for the app. The prototype shows all the tabs, click animations and loading screens. You can enter search queries or adjust the filters. For this app, we developed a prototype feature that allows you to root for a particular competitor and watch them move along the track in real time. Thanks to this work, the developers were able to accurately assess how much the app would cost. This detailed prototype cost USD 1,500 and took only three weeks to make.
In the same prototype, we tested all the animation parameters for the pie charts that show the tournament participants' statistics. This made things easier for the programmer, allowing them to transfer the timings and animation variables from the prototype into the code and saving them time. Without a prototype, it's almost impossible to complete an animation at the first attempt: it is hard to explain how it works without a visual example.
In the Russia Running app prototype, you can test the whole interface: buttons, drop-down menu, search function, filters, and calendar. On the left is the prototype. on the right is the app
Why We Write Code Manually During Implementation Instead of Using Code Generators
When the prototype is ready and approved, developers start implementing the idea. Of course, there are external tools that can help turn a static design into a piece of code or a finished app. For example, Supernova Studio allows you to apply primitive logic to a static design, and then generates code that can be assembled into an app.
But the generated code has the following issues:
- The prototype doesn't indicate what data is needed for the backend and where it should come from: it is still the programmer's job to specify this.
- The program generates suboptimal code, and it takes just as much time to make this code readable and optimized as to create similar code from scratch.
- Adjusting your design and ideas to the limitations of app builders is also difficult and can be outright impossible.
This is why developers still need to get their hands dirty when turning a prototype into a full-fledged app, although we are constantly looking for ways to optimize this process.
How Prototypes Can Help When Creating an App
Can be used to test hypotheses. You can show a prototype to a focus group or an investor, get feedback, study the needs of the target audience, and decide on further development.
Helps to demonstrate an idea. When investors can experience something close to the final app, it is easier to impress them and convince them to invest in full-scale development.
Improves communication with the client. A prototype clearly shows what the end result will be like. If the client had something else in mind, you can still painlessly course-correct at this stage. As a result, the finished app will be exactly what the client is expecting, and you won't have to spend time and money redoing it.
Reduces risks at the development stage. When you're identifying the client's requirements, you can quickly build a wireframe prototype to make sure you don't miss anything important when it comes to the project's navigation and functionality. The developer will know how each button and screen of the future app is supposed to work. If something can't be done or requires certain technologies, this will be clear before development starts.
And a high-fidelity prototype put together at the design stage enables you to do design reviews and easily find and fix logical and compositional errors in the UI design.
Saves time. Creating a standard prototype takes one week, after which the client can test their idea and decide whether it is worth investing in full-scale development, which would take several months.
Within a single prototype, you can test various cases separately from each other and provide references to them in the ToR. This makes things easier for analysts, developers, and the client, and speeds up your work: while one case is being prototyped, the next team can start work on another.
For example, when a high-fidelity prototype is ready, QA specialists can get straight on with preparing multiple test cases for further testing of the app while it is being developed.
Allows you to start your ad campaign early. Even before development begins, you can use the prototype for marketing purposes, e.g., on landing pages, in posts, in videos, etc.
Saves money. Prototyping requires a separate budget, but it cuts development costs by reducing risks at the development stage. Moreover, even if the client’s idea turns out to be unsustainable, they’ve only spent USD 1,500 on a prototype, rather than USD 20,000 on developing a full-fledged app.
Do You Always Need a Prototype?
Absolutely not. Sometimes making an app prototype is not cost-effective, for instance, if your app is basic, with no problematic features or intricate artistic design.
For some features, a suitable prototyping tool doesn't even exist yet. This is usually the case when the goal is to test a technical implementation rather than a visual one, such as implementation of augmented reality. We believe that within the next few years this kind of prototyping will become a reality too. For now, the developer has to come up with the behavior of this kind of element and implement it all on their own.
In other cases, when the customer wants to see the visual result of the programmers' work, prototyping can be a quick and inexpensive way to demonstrate what an app is going to be like.
How are you doing with prototypes? Have they helped speed up development and made your programmers happier? Share your thoughts in the comments!
We'd be happy to consult on prototyping for teams and businesses, and we're also available to help with development. You can contact us on this page.