They say that only the most agile of us will survive. So how can we keep up with how quickly user needs and expectations change these days?
Design sprint: what has Jake Knapp taught us?
Those of us who had the opportunity to try out the five-day design process invented at Google know how much positive, creative energy can be released in such a short time.
This methodology is based on including people from multiple departments in a single project. Even though those people don’t normally cooperate, when they get together, they have all the knowledge necessary to design solutions with a high probability of market success.
During workshops, the general idea of a sprint can be solidified. That not only creates a better, shared understanding of the idea, but also lets you identify long-term goals and project risks, and the process itself starts to take shape. Using little effort and resources, you can confirm the market hypothesis—or rebut it and discover that it has to be modified. This quick validation of your initial hypothesis formulated at the beginning of the workshop is the main point of a sprint. You don’t have to wait until a working build of your app is released to validate your hypothesis.
“I love design sprints—performing early research, building common understanding of the users, utilising creativity, and testing with prototypes. Those are the most interesting parts of the descriptions of Alior RBL_Lab job offers. When you use design sprint, you save money—you discard ideas with serious flaws or make quick, limited changes to them. Ev Rogers (known for introducing the “Early Adopters” term) came up with 5 factors of product adoption. Design Sprint lets you optimise the idea at a very early stage but doesn’t answer the question of whether your solution will be a long-term success. A good example of how easy it is to fall for the “first impression effect” are Personal Management tools used in banking—customers love to try them out, but trying is not the same as habitual everyday use. This is an important reason why you should test working solutions, for example by releasing a working app as an MVP. One of the ways to do it effectively is to cooperate with startups experienced in using design sprints. Getting the organisation’s permission to terminate a project if users don’t adopt your solution permanently is quite challenging” — says Paweł Stężycki, Director of Innovation Planning & Head of the Design Lab at Alior Bank.
Accelerating development… without development: the value of high-fidelity prototypes
Once you complete your design sprint, the natural choice is to build a more accurate app model that lets you illustrate the expectations of how it should work for the dev team.
Thanks to that, engineers will have something more than just written descriptions in the form of user stories acquired with the User Story Mapping technique made popular by Jeff Patton—they’ll have a clickable version of the UI.
This version consists of detailed clickable mockups that let you experience the user’s journey, and graphical layout suggestions. Those are complemented by a visual style guide enabling you to adopt a consistent style when formatting app controls (such as icons, buttons, text links, content formatting).
Building a prototype offers many advantages like visualising the idea and optimising the time requirements and costs of building your app. It also motivates the development team and increases their understanding of how the app should behave to meet business requirements.
“Thanks to the prototype, we knew from the beginning how subsequent functionalities would fit in with the product as a whole. We minimised the risk of loss resulting from the need to re-do the same components multiple times. Now, we can incorporate new ideas within the project into our previously designed information architecture” — says Paweł Marek, Product Owner at Transcash.eu.
Moreover, with prototypes you can quickly confront creative ideas with the technological capability of implementing them, as well as their feasibility within a given timeframe and budget.
And all this without typing a single line of code.
The “happy path” pitfall: when to consider edge cases
Prototypes allow you to quickly understand how the software is going to work. This is especially important when you plan to release a completely new app.
“When we present a readymade UX prototype of new functionalities, the business can quickly assess if this is what they need. We are looking at prototypes through the prism of use cases supporting a particular business case. Prototypes allow the development team to understand the complexity of the task at hand. This lets them create a more precise estimate for preparing the functionality visualised by the prototype. This way, it is easier to predict the general value from introducing a new functionality in the app” — says Gaweł Boguta, CTO of iTaxi.pl.
According to the Pareto principle, visualising a part of the scenarios, i.e. the top 20%, affects the correct understanding of the operation by the user of the prototype.
That is why a prototype rarely covers all paths and usage scenarios, as it would be time-consuming, whereas prototyping is about ensuring the highest value of your project with minimum effort.
A prototype is therefore not a complete documentation handling the so-called edge cases, i.e. relatively rare situations your software must be resistant to. The easiest way is to gradually incorporate edge cases while developing the software. It becomes even easier when your team includes a UX designer, with whom developers can cooperate to come up with ways of handling edge cases as they are revealed. This ensures the consistency of the interaction model.
Finally, top 5 rules for easier prototyping
1. Prior to prototyping screens, start with personas and flowcharts. Make sure that you know who the end user of your app is and what their goals are. Visualise the step-by-step user path, even in the form of basic flowcharts.
2. Begin with fast prototyping — like sketches on a paper napkin. The less precise the tool, the better. A marker and a whiteboard or a pencil and a sheet of paper are the perfect tools for this job. The goal of this stage is to prepare quick sketches to get the ideas in your head down out into the world.
3. Invite different shareholders to join the paper prototyping workshops. Even though business employees or developers are no experts in interaction design, they can bring interesting ideas to your project that may be worth considering at a later stage.
4. Ask each participant of the prototyping workshop to draw a few versions of the prototype. This way, based on the inverted IKEA effect, they will be less sensitive to criticism when discussing their suggestions. At the end, instead of defending particular versions, you will be able to take positive solutions from each of them and use them to build the final concept.
5. You should proceed to electronic prototyping environment, such as e.g. UXPin, only after you have tested the understandability of the paper prototypes. You can use corridor tests that enable you to quickly check if the users understand the interaction model.
