From time to time, the subject of “prototypes” crops up during conversations with customers about UX improvements. During these conversations, I pick up different views. This is what I will focus on in this blog. I would like to share my thoughts and considerations about this subject and provide an idea about how to identify a good scope to start a prototype.

The difference between a prototype and a proof-of-concept

You might be wondering right now whether or not I’m talking about proof-of-concepts rather than prototypes. So let me start by recapping the difference between the two concepts.

A proof-of-concept has the purpose of proving that something can be done. You might for instance want to prove that a specific UI technology is capable of supporting a specific design idea.

A prototype has the purpose of simulating the subsequent implementation of the idea. With the terms “low fidelity prototype” or “high fidelity prototype”, some people define how close this prototype should be to the final, real implementation. A proof-of-concept might be part of a prototype practice or a prior exercise.

Arguments for prototypes

Why are prototypes important for our UX improvements? I see three major arguments:

• Risk mitigation
  From a business perspective, each project involves different types of risks. One is that the project will end up providing something that nobody wants. Or even worse: The complete project fails because of technical issues or insurmountable implementation challenges. The prototype helps us to discover obstacles at an early stage of the project, where costs for fixes are still small.

• Quality improvement based on user feedback
  Prototypes can also help to improve the quality of the final solution. Design thinking for instance includes prototyping as a central element to interact with users and to gather valuable feedback about acceptance and usability aspects that need to be addressed.
  

• Increased speed and decreased costs
  You might wonder why a prototype should help to get things going faster. Just imagine that you discover fundamental functions missing in the middle of your implementation phase. Going back to the design table and re-coding your development will cause a serious setback in terms of time and money.
  

The value of a UX design prototype?

In the context of UX projects, prototyping is often perceived as a pure design prototype and early activities such as wireframes and mockups. Before I get to the additional sorts of prototypes, let me review why the UX design prototype is quite important. Actually, there are still many people out there thinking that a design prototype is not necessary in their project. But there are good reasons for executing design prototypes:

• Fail often and early
  From a business perspective this might sound terrible, because failing is connected with costs. But in reality, failing early also means failing cheap, as early stages of the project are much less cost intensive. There is a huge difference in costs, between just wiping something away from a paper mockup and throwing days of coding away to just recode.

• Increase accuracy of project estimations
  In early stages, the design prototype can help to sharpen the accuracy of your project estimations. It can of course even help you out in very early stages where you even not have a project, yet and still need to persuade your management.

• Increase your ability to set priorities right
  Sooner or later you will have to set priorities. The design prototype helps you to understand which UX improvements have the most positive impact to the users long time before one line of codes was developed. With SAP Splash and Build for example, SAP provides a good toolset to help you with a clickable design prototype without the need to code.

• Establish a common sense across different teams
  A design prototype is not the task of a designer only. It is a task performed by a group of people across the organizations. Users, designers, developers, key users, process owners and others build the prototype together. This is not only a great chance to identify concerns, challenges and road blocker of later project phases. It also helps increasing the acceptance of the later solution, as it comes from all instead of just one.

Sorts of prototypes in an UX improvement project

Prototypes are also very useful in other phases of the project. For example a development or adaptation prototype can help to understand whether the teams are well prepared to deliver the real solution. During the implementation phase too it might be of interest to prototype the activities necessary to successfully deliver the solution to the users.

The following list provides more details of the sorts of prototypes I have in mind.

Though development and implementation prototypes might be close to the real solution, they are often not intended to go-live. This is why these are often referred to as “throwaway prototyping”.

On the other hand, going live with a prototype can be a feasible approach if it is clearly defined as such from the start. This is typically called “evolutionary prototyping”. The advantage here is that the time expended on the prototype is not completely lost. The disadvantage though might for example be the quality of the code, as you might rely on code that was being built during the early stages of your project when the coding was still at a rudimentary stage of development.

Note: There is a serious risk of a prototype that was NOT intended to go live actually going live. Important functions might be missing or the quality might not be sufficient, all of which put the user acceptance at risk. To avoid this risk, it is very important to make it extremely obvious to everybody (including the users) if a prototype is not a productive implementation.

How to find the best scope for a prototype                                        

The final question remains: How to find the best scope for a UX improvement. I’m going to focus intentionally on an example of an evolutionary prototype, so that we can look into all different arguments of the selection process.

I believe a good approach would be to do the following:

1. Understand what is used most frequently (create a list of top applications)

There are various ways of gathering this kind of information. One would be to ask the business directly. Another one is to perform a usage analysis in the application systems. The blog “How can I identify the top transactions in my environment?” provides a few pointers for this.

2. Identify the cases with the highest impact to filter your list
There might be no direct correlation between the call frequency of an application and the monetary impact of this application to the business. You should double-check your list with the business management in order to identify the monetary impact on the business. There are other parameters you could double-check and rate at this point. For guidance on this approach, see the video How can I identify a good starting point for my UX improvements? – Part I and Part II.

3. Filter your list by the cases requiring design thinking activity
Steps 1 and 2 should provide you with a good list of top applications. You have probably developed a gut feeling about which of these entries will become candidates for adaptation or development activities. As a result, these are suitable candidates for design thinking activities as well.

Note: It also makes a lot of sense to start design thinking activities in the case of pure SAP software adoption (adopt case) to always put the user at the center of your analysis. Though this effort will require less time compared to adaptation or development scenarios, since there would in theory at least be no development and only a small amount of adaptation activity needed.

4. Filter your list by cases requiring specific, missing technology skills
Does your list contain UI tools or UI frameworks that your teams are not familiar with yet? In this case, you should put your focus on a scope that incorporates these tools and frameworks. Though there are a lot of different technologies out there, the tools and frameworks you should concentrate on are: SAP Screen Personas, SAP Web IDE, Floorplan Manager (FPM), SAPUI5 and Web Dynpro ABAP (WDA).

5. Filter all the rest of your cases in the list by mapping them to users and teams
Another dimension that is very important to me is the target group. Take the opportunity to learn in a convenient environment with a small group of users that are cooperative, probably a bit technology minded and willing to provide you with constructive feedback. This is necessary to be prepared for the bigger roll-outs of your solution where you don’t want to endanger user acceptance.

Summary

You might have experienced yourself that there are various ideas as to what prototypes are. We can at least distinguish between three sorts of prototypes that reflect design, development or implementation activities. In my opinion they are all equally important.

It is also important to make the right selection on the prototype scope. As well as gathering as much information as possible in order to improve your solution, you also need to ensure successful adoption of it in the user base later on. As mentioned in step 5 above, this includes how and to whom you start rolling solution out at the end. A small group of users honoring what you are doing and providing valuable feedback is the best way of preparing yourself for upcoming implementations across your enterprise.

If you have any ideas or thoughts about this topic that you would like to share, please use the comment section.

With regards,

JJ (Twitter: @JJComment)