THE ROLE OF A FUNCTIONAL PROTOTYPE IN SOFTWARE ENGINEERING

Here are some striking stats:

• 66% of software projects fail.
• 44% meet the original business goal.
• 59% are considered valuable by the customer.

Besides, the Consortium for Information & Software Quality (CISQ) report states that the total cost of poor-quality software has hit $2.08 trillion and is rising in the US alone. That’s a pretty troubling trend.

Why is this happening? Reasons are numerous, ranging from unrealistic expectations to limited time for development. But, most of those costly mistakes could be avoided if stakeholders had a clear understanding of what they wanted to achieve. Often, they have only a rough idea of the project, which leads to confusion and complications once the development of a digital product begins.

Instead of making decisions based solely on gut feelings, successful companies follow the test-and-learn path. They set up experiments and learn from their results where to go next and whether the idea is viable at all.

With functional prototypes, companies can embody their product idea, simulate the real user experience, spot limitations, and discover ways of improving the final product. Although prototyping requires a portion of the budget, its cost is nowhere near the compound losses caused by the launch of a product that no one needs. So, there’s simply no reason to ignore the actual value of software prototyping.

The best way to see the benefits of prototyping is by using an example.

Do you know Zappos.com? It’s a pioneer in online retailing that sells shoes, clothing, and accessories from multiple brands US-wide. The company’s annual revenue hovers around $500 million. But few know that Zappos.com originated from a small shoe-only store that wasn’t even a real online store — at least not in the way we perceive it today.

Back in 1999, Nick Swinmurn came up with a simple yet groundbreaking idea — creating an online platform where people could buy the shoes they wanted but couldn’t find in local stores. This idea hit him when he was vainly trying to buy dessert boots in one of the San Francisco malls. Some stores had the right size but not the right color. Others had the right color, yet the wrong style.

Nick didn’t have enough budget to buy shoes from warehouses as it would require him to invest in numerous models, each with lots of sizes and colors. But he still needed to validate his concept. So, he decided to go to local stores, take pictures of available shoes, and post them on his site. Once someone placed an order for a particular model, he went to the store, bought it, and mailed it to the client.

Was it profitable? Of course, not. But this is not something Nick was trying to test. The goal was to validate whether his business idea was feasible, and he achieved it.

With that in mind, here’s an action plan you’d want to stick to during the project’s early stages:

Brainstorm ideas → Form a hypothesis → Prototype → Test → Learn the results → Make improvements or Pivot

A chunk of the above text points to the functional prototype’s unmatched advantages. That’s true. Still, don’t rush into building one — rather, take one step at a time. Before investing any resources in digital prototyping, you need to know for sure that it will add value to the final product.

A prototype comes in two forms: 1) with a low level of detail (low-fidelity) and 2) with a high level of detail (high-fidelity) respectively. While one is built quickly and basically, thrown away, the other is improved upon iteratively and developed into a full-featured product. Both models are effective — though, each for different purposes.

NON-FUNCTIONAL PROTOTYPE

A low-fidelity software prototype is useful in the early stages of development. It allows you to visualize the different screens of a digital product and understand how a user might navigate through them.

Such prototypes can be as simple as hand drawings. Paper prototypes are good for collaborative idea-sharing, finding big-picture problems, and making instant changes. That’s because it’s easy to test multiple interface variations during a single brainstorming session.

A more advanced form of a lo-fi prototype is a wireframe. This is a digital prototype since the designer uses software prototyping tools like Figma to draw it. By linking multiple wireframes together, the designer can create a clickable wireframe and simulate user interactions.

Non-functional prototypes are particularly beneficial when the team needs to get quick feedback on the concept or idea. They are fast and cheap to build.

WHEN TO USE

• Visualizing information architecture
• Testing user flows

FUNCTIONAL PROTOTYPE

A functional prototype feels real enough for end-users to think that they are interacting with the actual product. This is because the prototype is built in its natural environment.

Such prototypes contain almost all UI elements that will appear in the final product — i.e. graphics, animations, buttons, content, etc. So during usability testing, users will behave as naturally as possible. And this, in turn, will provide stakeholders with qualitative findings regarding the concept viability.

Hi-fi prototypes are responsive across different devices, allow for real page transitions and micro-interactions. They help understand the true capabilities of the product, as well as its possible constraints.

WHEN TO USE

• Testing real user interactions
• Checking the exact functionality

At CXDojo, we can help you build an interactive digital prototype — also known as a coded prototype — using HTML/CSS or JavaScript. Coded prototypes are close to the release-ready products both in terms of functionality and visual design. The only difference is that these prototypes have a core set of features and no back-end.

We advocate for the following approaches to functional prototyping:

• Evolutionary. We start by defining the requirements that are crystal-clear and, then, put together the initial specs. Based on them, we construct a prototype that will become the core of the final product. This prototype is refined after each feedback loop when new undiscovered requirements pop up. The process is repeated until a satisfactory prototype is created. This model is best suited for large projects with many high-risk areas that need to be tested through prototyping.
• Incremental. Here, a separate prototype is built for each independent module of a single system. Once each increment is thoroughly tested and improved, we put them together to build one consistent prototype of the product. This approach is used for multi-module enterprise software or microservices apps.

Our team takes software prototyping seriously. A prototype is not an optional extra that can be discarded as useless. This is something that can either make or break the subsequent development process. With this in mind, we prototype software in the very same way as we would build it.

✅ Discovering a product

✅ Outlining fundamental requirements

✅ Visualizing user interfaces

✅ Putting it all into code

✅ Collecting feedback

✅ Finalizing a prototype

That’s a sound question. But instead of simply saying ‘Yes’, we’ll introduce you to common scenarios that push our customers towards prototyping.

Does any of the above cases resonate with you? Well, you know what to do and whom to ask for a helping hand — CXDojo is always-on. If none of the pains is familiar to you, but you still believe that a digital prototype might prove effective in your case, drop us a line. Let’s discuss your project details and think of the most appropriate solution together.