Delivering a chunky programme phase is never more uncertain than when a global pandemic arrives at your doorstep.<\/p>\n
#1. Create services and products that meet user needs<\/h3>\n
This may sound obvious: only design, write, develop services and products that meet a real person\u2019s needs. Over the last few months, I have witnessed a huge increase in the demand for my team\u2019s skills at a particular time where everything feels urgent. \u2018Getting pulled in different directions\u2019 was one of the main themes in our team\u2019s retro – something I also experienced first hand.<\/p>\n
Whilst we weathered the storm, I feel it is important to remind my colleagues across the University, who understandably sought fast solutions to complex problems, that (external) users who come looking for our services have a choice<\/em>. They can easily go elsewhere and find an institution that will meet their needs better than we do. With difficult times upon us and more still on the horizon, reducing unnecessary choice and burdens for our users have become more important than ever.<\/p>\n There were many occasions in this phase where I had to \u2018stick to my guns\u2019 and express the importance of going through a user-centred design process properly (albeit rapidly or retrospectively at times) and advocating for our users. For example, if you\u2019re a student who is about to start your journey at any given university, how critical is a good digital experience when no physical events or learning can take place?<\/p>\n I think there might be a misconception that user centred design (UCD) is a lengthy product development process. It doesn\u2019t have to be.\u00a0 I\u2019m grateful for the colleagues who have witnessed first hand the speed at which products can be created and delivered. They have put a lot of faith into our practice.\u00a0<\/span><\/p>\n At the same time,\u00a0<\/span>in some areas we have seen knee-jerk solutions pushed through, which have not fully considered the problem they are attempting to solve. What would a good benchmark or KPI look like? How is it going to be evidenced? Issues and challenges that we\u2019ve all been aware of for years have been magnified to the extreme because – guess what – when you design a digital service, the backend office gets exposed, and that\u2019s not always a pretty sight!<\/p>\n Holding the line is hard. Over the last few months, we conducted design research throughout the product build, facilitating multiple rounds of moderated usability testing to make sure we\u2019re building the right thing for people as quickly as possible.<\/p>\n Some of our new designs may look very simple. But to get there we had to iterate several times as we developed our understanding of our users through their inclusion at all stages of design and testing. Our multidisciplinary teams relied and acted on users\u2019 first-hand knowledge and feedback throughout, making it a point never to trust our first assumptions.<\/p>\n Audiences and users are not the same thing. The products we design and the content we write might have more than one user with a range of different needs. It\u2019s not enough to imagine one kind of user.<\/p>\n One of my team members, Maria, said \u201cjust because we think that something might be the right thing to do, unless it\u2019s proven by the real users, it\u2019s not\u201d.<\/em><\/p>\n Empirical evidence is the cornerstone of all good decision-making. You need to do research to learn about the range of users and their contexts. It’s important to find out about their specific and diverse needs, such as:<\/p>\n Accessibility requirements are an absolute must and one of our key guiding principles. We have to conform to WCAG 2.1 AA compliance<\/a> and it is also an important requirement to meet user needs.<\/p>\n We\u2019ve just completed an independent accessibility audit and we\u2019re working through it to address some fundamentals before release. But it all becomes much more challenging when other teams don\u2019t necessarily work in the same way as you. This results in a solution that, while technically correct, does not stand up to user needs scrutiny and is now too late to change.<\/p>\n Projects and activities should have a desired outcome – the anchor point. This remains fixed whilst the problem and solutions can change. For example:<\/p>\n Moving towards our desired outcome may raise additional practical questions, such as:<\/p>\n The answer, always, is: the user knows<\/strong>.<\/p>\n We must adopt a different posture as an organisation, as stakeholders, and as colleagues – our opinions might be interesting, but are unlikely to be the final answer. Don\u2019t seek to argue – seek to understand.<\/p>\n This might be unsettling to some because it contradicts many preconceived ideas about the way we should do things. We\u2019re encouraging you to take this journey with us. It has great potential to change your perception of the problem and solution for the better.<\/p>\n In large organisations there are always services, systems and content owned by other teams within the organisation. By far one of the most challenging parts of running a multi-year transformation programme is managing content requests as part of the business-as-usual workflow.<\/p>\n We\u2019re currently working on a new easy step-by-step guide to help our team and stakeholders manage their content, provide feedback and suggestions. A few critical observations from recent activities may offer some further enlightenment to others who find themselves in the same situation:<\/p>\n To understand what works and what doesn\u2019t you need to identify what content is (and isn\u2019t) used. Generally speaking, the more content you have, the more complexity you add for the user. There is no excuse for failing to analyse and evaluate your content, how it is performing, and how your users are accessing and consuming it. Put simply: you can\u2019t measure your success (or need to improve) without measuring anything at all.<\/p>\n Watch your users struggle, do some readability tests, identify their pain points and respond accordingly by iterating your product. I know that user research is a craft, and we\u2019re lucky to have a few in our teams. But even if you don\u2019t have access to a user researcher, or you\u2019re unable to talk to users, there are some things that you can do, such as desk research<\/a>.<\/p>\n Digital services and content, like all living things, have a lifecycle and lifespan. It helps if you have maintenance reviews where you take a look at performance analytics and user feedback to flag up areas that may need to be removed. This is something we are looking to address very soon.<\/p>\n Our organisation, like many others, still feels that FAQs are an effective way to communicate important information. They are not. Good structured content really matters. Information Architecture (IA) really matters<\/a>. We know people don’t think in terms of neatly framed questions and FAQs don’t assist natural online reading behaviour. They make the user do the hard work and are inherently antagonistic to good IA<\/a>.<\/p>\n Just by writing this, I can sense the palpitations of any content designer taking on a long list of FAQs, and trying to turn it into something useful against a tight deadline! This is also frustrating because it feels like we\u2019re letting users down by not doing an adequate job in communicating vital information as effectively as we could. The misalignment between stakeholder perspectives and real user needs is the elephant in the room that needs addressing.<\/p>\n#2. Simplicity isn\u2019t simple, consistency is even harder<\/h3>\n
![\"user](\"https:\/\/www.southampton.ac.uk\/blog\/wp-content\/uploads\/sites\/27\/2020\/08\/user-testing-in-progress.png\")
User testing in progress: only hard work makes things simple<\/span><\/p>\n#3. Users, not audiences<\/h3>\n
\n
\n
![\"Double](\"https:\/\/www.southampton.ac.uk\/blog\/wp-content\/uploads\/sites\/27\/2020\/08\/Double-diamond.png\")
Outcomes based solution: the Design Council’s double diamond model\u00a0<\/span><\/p>\n\n
#4. Working with us early<\/h3>\n
Not all content is equal.<\/h4>\n
There is no substitute for observing people interacting with your services.<\/h4>\n
Some content, websites and products need to retire.<\/h4>\n
I still don\u2019t get FAQs.<\/h4>\n
![\"Users](\"https:\/\/www.southampton.ac.uk\/blog\/wp-content\/uploads\/sites\/27\/2020\/08\/user-needs-vs-stakeholders-needs-1024x562.jpg\")