How can I identify the right scope for UX improvement prototypes in my project?
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.
or adaptation activities
as part of the
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.
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.
JJ (Twitter: @JJComment)
Nice table... would like to see it updated to be stronger on the benefits and purpose of design prototypes.
They are much more powerful than just a handover to developers.
For starters they create a shared vision for end users, stakeholders, designers, and developers, and others.
But to me above all the design prototype communicate the HOW (UI design) of UX - that is how will the changes in the UI support the desired business and end user outcomes. Because you can use the prototype to check your business case assumptions around:
* reduced training costs - is it intuitive
* increased productivity - have we reduced the number of clicks & thinking/wait time for end users
One other thing... I would add that as well as the design prototypes it is critical that developers be given the Points of View insights gathered during end user research. There are so many situations where developers make tradeoffs in the underlying system that have nothing to do with the UI itself but can make or break the user experience.
For instance, we have a customer I am currently working with who is looking to replace a system that was built to be simple - before it's time almost. But what has absolutely killed it's usefulness is a technical decision to replicate certain underlying data - on which the UI depends - between systems overnight. Because the IT developers, system architecture and admin folk had no idea how critical same day access was, they thought overnight was fine. Instead it's been a death knell.
Keep going! I think what you are trying to do is right... and it would be even better if the discovery and design aspects were strengthened. I recommend https://experience.sap.com/basics/ as a great source of information.
I appreciate your feedback and do understand your points.
Of course I agree that the values of design prototypes is an important topic though I think these have been described in many other blogs, already.
Actually, my intention was to generate a point of view that helps to understand the difference prototypes and how I can identify a good scope so that my prototypes of several sorts can be as effective as possible. I didn’t want to promote any specific prototype. To me all are equally important, especially in an enterprise project (see product vs. enterprise UX strategy).
Let me try to add some points to my table and the blog that reflect your feedback while keeping my original intention of the blog stable.
Again, thanks a lot for your feedback.
Thanks JJ - that's all I'm asking for.
I found your blog good but weighted more heavily to the development prototypes than the design. I just want to see a better balance.
Especially given that a good design prototype is typically a lot cheaper to build than a development prototype. And of course it can also considerably cut the costs of any subsequent development by resolving a lot of decisions up front before any code is cut.
While yes design prototypes are described elsewhere, out in the field we find there are many customers who are still development-centric and don't fully appreciate the pros and cons of each option. These are the sort of customers who may think a design prototype is simply a handover to a developer and may not appreciate its other benefits.
So it's great to see prototypes discussed side by side - and important to make sure your table is even-handed so that people get a clear overview of their choices and can make an informed decision.