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.  

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. 

• the main take-away for this alpha project for me personally was an understanding about how users interacted with components in the application. For example, some components that allowed users to show/hide sections of content on a page were often ignored by users as they weren’t aware that they could click on them to expand for more information even with visual indicators. This came as a surprise to me as such components are frequently used in various applications on the web, and I was quite used to how they worked

• a second learning is that it would have been much easier if I had used GDS components earlier in the process. That way our UR testing time would be more focused on the content and not testing component structures and design. The GDS components have been exhaustively tested, and users will more likely know how to interact with them. The components I used in the start of the prototype were ones that I was more familiar with. So, while it was easier for me to develop the original prototype version with them, some users weren’t sure how to interact with the application’s structure earlier in the process

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.