Developing prototypes

15 January 2021

Prototyping lessons learned

Part of the alpha phase of the front door of Adult Social Care project we’re working on with Blaenau Gwent, Torfaen and Neath Port Talbot councils has been building a prototype of a potential solution that we can test with users. In this post, developer Matthew Pugh tells us a bit about the approach to testing and iterating through prototyping.

Why do we prototype

The aim is to test design concepts quickly. It is important to keep this in mind, especially when designing a prototype website. As soon as a prototype becomes difficult to adapt to user research findings, it is no longer effective.  

A drawing of the track service.

For this reason, we always start the prototyping process by drawing. This allows us to bounce ideas around among the team to get quick design ideas and structures. It is best done in multidisciplinary teams so that we can get a range of perspectives on what may be workable and what won’t be. A tech specialist will typically focus on what’s possible, while designers will often focus on what would best display concepts to users. One challenge we faced with this approach is that any user research we’ve done has had to be remote due to COVID-19 lockdown restrictions. For that reason, our paper prototypes were mostly the focus of idea generation sessions to brainstorm and test solutions between the teams working on the project. In the past projects I’ve been a part of, even paper prototypes were developed and tested with some users where possible. After our paper prototypes solidified what we were looking for, we then needed to start testing with actual users. To do this we needed something that could be shared a bit more easily.

Staying flexible during design iterations

Once we narrowed down to one or two design ideas, we needed to test our findings with actual users. Our ideas and needed to be validated through user research to see if they had the intended effect. Setting up a prototype which can do this can be done quite quickly using services like Figma which allow for the quick creation of dummy applications. While this takes a bit longer to create than paper drawings, it gives better results when doing user research since it often looks better and is easier to adapt and change.

There can be a push to go straight to a coded prototype, but we still need to be able to remain flexible as ideas quickly evolve at this stage. Going straight to a coded prototype can be risky as any experienced software developer will tell you: it is often much more difficult to alter the designs once it exists in code. Radically changing the designs of a coded prototype can quickly lead to bugs and time wasted. We only want to go down this route once we have enough validation of the designs to make sure that the next step is worth the effort. To avoid this, we shared links and screen shared to the prototype and had users give their opinions on the design, taking notes about how the designs should evolve going forward.

Narrowing designs using code

After discussing the findings from user research from the first few phases of the project, the feedback has narrowed enough for us to begin focusing on a final design. At this point it becomes appropriate to code the next iteration because now we need to be able to test aspects such as different user scenarios, languages, use on mobile devices, and validating accessibility standards. The move to a coded prototype at this stage helps us avoid having a dozen or more separate Figma designs which are increasingly difficult to keep up to date.

Having most of our design validated meant we knew there wouldn’t be too much of a variation in designs. Creating a coded prototype is a significant time investment even when using existing components. Where a Figma design can be put together in a matter of hours, coded prototypes – depending on complexity – can take days to create. When we’re working on weekly and biweekly sprints, this can risk slowing down iterations on design if it is done too early.

The initial prototype design was focused on speed of creation. In order to enable this, I used an already existing design system (called Material UI) which is a set of already made components. This allowed me to create a design similar to the Figma prototype without wasting time designing my own pieces of the web application. Early designs didn’t connect to any database or API due to the need to be constantly be iterating on our designs. This design-focused development made sure that test users were continuously validating our designs. Data was still hard coded at this stage, but I made sure the live (publicly accessible) version of the prototype could be automatically updated as development progressed.

While the initial coded front-end was being used in the next round of UR sessions, I created a simple API. APIs allow for a more flexible way to interact with data, allowing us to request different data for different users for instance. This replaced what was formerly hard-coded data in the application. This change allowed me to prepare for the next phase of the iteration which would allow for different scenarios and users. Because I knew that the resulting application would require different language responses, I made sure to build localisation in as well for when we had translations ready.

Adapting the designs to user research findings

Once the API was ready, results were coming in from user research sessions. We used these findings to adapt the prototype yet again. This time, combined with the power of the API, we were able to create several users who each had different cases. This allowed us to quickly and easily test a wider variety of design ideas and scenarios in the next round of user research. One of the other things I was able to incorporate in this design was the GOV.UK GDS components. This created an even cleaner look and feel to the application which many users would already be familiar with who have used government services in the past.

Thinking about the Welsh language

While the next round of designs was being tested, we built in the bilingual elements of the service to ensure we were able to provide and test the service in both Welsh and English. Building them in at this stage meant they were available in preparation for the next round of user research with Welsh speakers. Because we knew this would be needed from the start, the infrastructure was already in place to handle the different languages. It was only a matter of dropping in the correct translations into the design so that the website could reflect language choices.

Lessons learned

With any project there are lessons to learn. Just like with the designs of the prototype, our approach should also be iterated on. This is part of what makes designing using the Agile methodology so powerful: the written-in expectation to learn and adapt. 

With the next phase of development, we’ll be continuing to iterate and test our solution. During this beta phase of development, we’ll work towards a basic functional version which we can test in a live service context. During this phase, we’ll share further learnings as we continue to progress.

Leave a Comment

Your email address will not be published. Required fields are marked *