Last month, we spoke to the Scottish Parliament’s senior management team about the user centred approach we follow for our new Beta website, and how user research feeds into this.
What is user centred design?
User centred design (UCD) is a design process that also focuses on a user’s needs and goals rather than just focusing only on an organisation’s requirements.
For the Web Project at the Scottish Parliament, it’s about understanding who our users are and how they use our website. This involves:
- speaking to people from our user groups at different points in the process
- designing our Beta site based on their needs
Following a user centred approach helps us build an effective service that is both useful and usable to our users. It also enables us to:
- identify problems early on and make changes earlier, when it is quicker and more cost effective to do so
- make better decisions based on facts and evidence rather than assumptions
How does this apply to the work we do to design the Beta website? Here are the steps we follow:
Step 1: Discovery - defining user needs
“User needs” are the requirements people have of a service (digital or otherwise) to achieve a goal.
For each of our top tasks different people in the team work together to identify and prioritise our users’ needs with the following steps.
A content designer from the team carries out research, or “discovery”, to find out how users are using this section of the current website. The content designer will:
- audit the current content on the existing site
- look at analytics to find out who is looking for this information and how they are doing so
- research keywords to understand how people are searching for the content
- speak to the Public Information team in the Parliament to find out what the public are asking about the topic
A business analyst (BA) from the team looks at this section of the site. A BA reviews an organisation’s systems and processes in order to document business requirements. The BA is looking to find out if content for the new site will be:
- data driven: pulled automatically from information we store in a database
- content driven: written by a content designer
If the new site uses data, the business analyst looks at how the information can be pulled onto pages on the Beta site and if any work needs to be done so this can happen.
Our user researcher speaks to the people who will use this part of the website. Usually they will:
- hold short interviews with users, face-to-face in the Parliament building or over the phone
- talk to people about how they use the site currently, to find out what they need to do and how they do it
Engaging with our stakeholders is such an important part of the process. Our stakeholders are key people within the organisation who provide a service to our users. Our stakeholders:
- tell us about the service they provide users - they are the experts
- help us shape the questions we ask users in user research
Step 2 – Translating user needs into design
Now that we have all the research, as a team we come together to determine a list of user needs. We then prioritise the needs based on our findings. For example, for the MSP top task, our top two priority user needs were, find and contact an MSP so we made sure we tackled these first.
With our stakeholders, we have a workshop to go through the user needs. Then, together we start to sketch the basics of how this area of the site will work.
We then hand these over to our User Experience (UX) designer who turns these sketches into a prototype.
The content designer “pair write” new content for the page, working with our expert stakeholders to come up with the content together.
Then the design is ready for the next stage: usability testing.
Step 3 – Validating the design with our users (usability testing)
We test our designs with people from our user groups to make sure what we have put together is effective and efficient for the people who use the site. This is called usability testing.
In testing, we look for any significant barriers and opportunities to improve. We speak to 6 people during 60-minute sessions, over the course of a day either or face-to-face in the Scottish Parliament building. Participants are given tasks to work throughout using the prototype and we observe how they interact with it. They can carry out the testing on a desktop computer or mobile device.
Testing early and often means that we can make changes to the design and content at an early stage. We carry out as many rounds of testing as needed until we get it right.
Step 4 – User story mapping and defining the MVP
Once we have our design in place, we start the process of handing this over to our developers.
We do this via “user stories”. A user story describes the user, what they want and why. It helps to keep the whole team thinking from the end users’ point of view and creates a simple description of a requirement.
We map out our user stories using a board and post its, giving priority to those we are going to tackle first.
For example, when we were working on the MSP part of the beta site, “Find an MSP” was our top user story. This translated into a postcode finder people could use to find their MSP.
Parliament staff are able to download the full slide deck on user research and testing so far from our internal project website. For any questions on our process, or if you would like to be involved in any of the up and coming research we have scheduled, contact email@example.com