To prototype, or not to prototype?
All web and mobile app experiences are becoming highly immersive. Gone are the days of designing a series of linked webpages. Thoughtful animation and interaction design is key to defining amazing user experiences. Apple’s world famous design director Jony Ive has this to say about the modern day design process:
[The design process] is about designing and prototyping and making. When you separate those, the final result suffers.
Applying that to modern day web and app design, you need to see and feel the interactions rendered by software to know if you’ve nailed the experience. Prototyping helps get you to that a lot earlier and faster in the development cycle.
Now I know what you’re thinking: Okay, great! I understand how to design and how to make things, but what exactly does it mean to prototype? Let’s go to the Wikipedias:
A prototype is an early sample, model, or release of a product built to test a concept or process or to act as a thing to be replicated or learned from.
There are various ways to prototype, with various levels of detail and what to use depends on what stage you’re at in the project.
| Type of Prototype | What | Best for |
| Paper | Sketch out the screens you want to test. Put them in front of a customer and when a customer taps or clicks on the screen, swap out the screen for a new one manually. | Very early rough concept validation. |
| Wireframe | Stitch together your wire frames with links that transition between each screen. Sketch will let you do this. Even keynote can be surprisingly effective. | Early validation of the information architecture, or common user journeys within a website or app. |
| Visual design | The same as previous but at a higher fidelity. If you are getting closer to shipping your designs, you need to start getting much closer to the actual designs customers will see. Tools like InVision are really easy to pickup and use, even for non designers. | Getting concrete feedback on proposed finished designs from customers. |
| Code | If you can code, or are comfortable with tools like framer or principal you can create the real thing. | The real deal. If you can get quickly made prototypes in code, these are as close to the real experience that you will ever get. |
How does one approach agile design?
The agile manifesto promotes “working software over comprehensive documentation.”
Just like a picture is worth a thousand words, a prototype is worth a thousand user stories.
Prototypes help you simulate working software much earlier in the cycle. You don’t have to go through the expense of time and effort before you genuinely get to experience the software and give feedback. It also reduces the need for documentation. You can save time, minimise wasted effort, and avoid frustration during the development process as cross-functional teams will require less back and forth to validate interactions and flows.
By having a prototype that simulates working software, you will notice that the rest of the team not only better understands your design intent, but they also become more engaged, leading the team to have conversations about what it is we want to build, and what it is we can build. Individuals and interactions!!!
Agile teams value customer feedback early in the development cycle. The other beauty of a prototype is that you can see customers interact with your finished design, before you’ve written a single line of code. Conducting well structured user research using a prototype is extremely cheap and easy, even if you don’t have access to a full-time researcher. To conduct our user research at Atlassian, we set up our own usability testing lab (“AtLab”) with very little time and effort. We even created a simple step by step guide for how you can do it yourself. When you combine a well crafted prototype with simple-to-setup usability testing, you can save yourself a ton of wasted engineering hours building something that either customers do not want, or that has a poor user experience. Much better to find and fix these things early, than ship a poor experience to customers.
Integrate design into your agile development workflow
There are often some common challenges that tend to arise when a project moves into the design phase, some examples include:
- Product Managers get anxious that designs will not be ready before the start of a sprint
- Some designs may make it into a sprint with no time allocated for customer validation or feedback from engineering teams
- Engineers picking up stories and then wasting time locating the latest design file. Where’s the link to the design? Where’s the attachment? Is this the latest design?
However, a lot of the problems above can be avoided by integrating design directly into your agile workflow. Here are some tips for how to do that:
- Consider incorporating an “in design” status into the workflow and track this via a team board.
- If your team is following a SCRUM framework, designers should attend all planning sessions and standups.
- Many SCRUM teams at Atlassian will create a specific “design debt” project, board, or component within a workflow. This picks up existing known design bugs associated with the product. The team will usually try to integrate at least one of these issues into every sprint, so they are continually improving the overall user experience for our customers.
- On longer running pieces of work, design work may simply become a story within an epic. Or even sometimes a sub-task of a parent issue. This can help teams understand where they are “blocked by design”.
- Demo trusts are important at the start of a project to align senior stakeholders on the objectives of a project.
- It is also helpful to organise E2E demos to solidify that shared understanding amongst the team, as well as run to invite open and honest feedback from stakeholders.
Designers don’t like being harassed for links to assets and having to constantly find issues and re-upload each design revision. On the flip side, developers hate having to track down updated designs and all the details they need to code the design properly. All this back and forth can really hinder innovation.
Recently, we’ve been playing with the new InVision for Jira integration to tackle this problem. This allows our teams to integrate directly between a Jira issue and the corresponding InVision prototype. The integration with Jira Software promotes not just visibility into the interaction design, but also encourages others to comment and give feedback – an important part of the agile process.
The prototype is always updated whenever the designer makes a change, which means a single source of truth for the entire team to work from. This allows teams to stay more in sync with each other, and waste less time searching for the latest design file.
To Prototype. That is the answer.
Regardless of the method you use, prototyping is no longer just a nice-to-have. Aligning a multi-disciplined team and ensuring that everyone comes away with a completely clear picture of the intended interaction design is key to successful product development, and building experiences that customers will ultimately love.
Once you build prototypes into your design process, you get a better feel for whether you are solving problems in the right way for your customers. You will also find it invites more constructive feedback from customers and internal teams, as it feels more real than a static mockup ever can. Taking the agile design prototype approach and refining the prototype multiple times allows your team to find better, more elegant solutions, faster.
Jason Wong, Jira Software Principle PM, also contributed to this post.