Whether we’re developing an entirely new app or adding a new piece of functionality to an existing app, we always prototype before we start writing code. As Lead Designer, this is most certainly ‘in my wheelhouse’
The main purpose of prototypes is provide a shared understanding between ourselves, and the project owners. Prototypes should be seen as a tool with which to communicate – there’s nothing more dangerous (slight exaggeration) than a prototype that hasn’t been discussed and simply handed over to a developer to produce. We use prototypes in tandem with user stories (more on that later) as a cue card to a discussion. It indicates what could happen, but is open to discussion if there is a better option.
It’s also important when prototyping to spend only enough time on them to communicate the idea, rather than spending 3 days on polished designed only to realise you haven’t quite understand the technical limitations of what’s possible. This leads to unhappy designers and developers
This is why we use prototypes of varying degrees depending on the situation. Here’s a quick rundown…
Here’s the situation – following a sprint review, it’s been decided that the registration process for the current app needs revisiting. Following an internal discussion on what the flow should be, we need to articulate that process to ensure we’re all on the same page. I start by creating a flow diagram:
Fig1: Example of a user flow diagram
From here, if I get the okay from the rest of the team, I can move on to creating a prototype. Now, I haven’t got much time in the sprint and we need to convey this flow quickly, but we need a bit more information on how these steps might sit on a screen. This is where the rapid prototype comes in.
I sketch the flow into separate frames, like a storyboard, so I can see each stage of the process. I keep these screens in mobile format as it focuses the attention, and it’s less stuff to draw! Using the marvellous Marvel app, I then get these in to a working prototype – adding hotspots to link the screens together. Here’s the ‘finished’ prototype – together with the diagram, this will have only taken a morning or afternoon to create – and it communicated to the rest of the team exactly what was needed without the need of another meeting, or a full set of designs.
When we are mapping a new app, or new piece of functionality we will use user stories and wireframes as the foundations for development work. As mentioned above these work in tandem to aid the team in a shared understanding of the end goals and requirements. We tend to isolate wireframes in to performing a task – Adding a new user, assigning that user to a location, adding a note and piece of evidence to that user.
This means that we can link wireframes directly to a user story in the sprint. A developer can read the user story and the acceptance criteria – and have a visual representation of the story. This keeps everyone focused on individual tickets and encourages the shared understanding and discussion.
It’s important to keep elements within wireframes simple, bold, and easily editable. it’s likely you’ll need to create several similar layouts so I find it really essential to make the most of Symbols in Sketch. Keeping a neat and tidy Symbol library in Sketch means that you can easily update existing symbols and re-use and tweak others when creating new layouts.
Here’s an example wireframe for a flow we’ve been working on for adding a new employee to a training system:
The next (and final) layer of prototyping is designs. It’s far less important with designs to create every layout and to have the shared understanding between designer and developer. Designs are adding the polish to the work – so it’s important the designer and frontend developer are on the same page at this stage. Designs could be as simple as creating a sheet of html elements and ensuring you have considered every element on the page. However, it’s likely you’ll need to explore how these smaller elements fit together on a page; how the header works alongside the main navigation, or the side navigation. This is where designs come in – to give instruction for how the main architecture of the interface will look, and how the tiny details will look and feel. Here’s an example of designs for the training application that we’re currently working on:
What we use
We favour Sketch for all our design work – there are plenty of articles on why Sketch is best for UI design – we favour it because it’s geared towards UI design. Creating artboards, making global changes to a design, exporting options – these all have the UI designers scenarios in mind so it really saves us a lot of time.
Marvel is a prototyping tool used by the likes of UsTwo and NHS Digital – it’s a great tool that’s easy to use, highly flexible, and looks great. It’s definitely worth a go on the free version if you fancy dipping your toe