The service I\u2019m currently working on aims to help support people back into work. This can be a highly emotional and sensitive area which is why it\u2019s really important to speak to real users in their own environment and measure their satisfaction over a period of time.<\/p>\n
I recently moved to DWP Digital having previously worked in a research team for an online retailer. The team was separate from the project teams, which meant getting to know and juggle lots of different projects at the same time. It was really interesting but also could be quite tricky to manage, from the initial findings to the end-to-end outputs. The pace was fast and the majority of research was done in a lab, testing various shopping scenarios with customers for a certain item.<\/p>\n
The main difference I\u2019ve found in user research in public sector – and the reason I love working for DWP Digital – is the ability to go out and do more contextual research with our users.<\/p>\n
Another big difference is that often our users are internal and our own colleagues as well as external. This helps to give us a deeper understanding of what our users really need.<\/p>\n
At DWP Digital we work in multi-functional teams of specialists. User researchers are embedded into an agile project team working with interaction design, content designers, business analysts, QAs, front and backend developers, a delivery manager and a product owner. This way we get chance to gain a greater in-depth knowledge of a project.<\/p>\n
It\u2019s also a really good way to gain knowledge of the other working areas. Taking the whole team out on research has proven really valuable to my team. It allows for better collaboration and the opportunity to constantly improve and iterate our solutions, making them the best they can be
\nfor our users.<\/p>\n
As a user researcher there are many different methods of research available to use and it\u2019s always good to explore and try new ones.<\/p>\n
Something I found challenging was working with users in a contextual environment to test prototypes. As humans we tend to like to please others and as a result I\u2019ve often found that when the user is unable to use the service their first step is to blame themselves, do a work around or say it\u2019s fine even when they can\u2019t complete a task. I\u2019ve found it tricky to assure users in their confidence to point out the flaws in the prototype or product we\u2019re testing. For example, recently when testing a new service, 13 out of 15 users did not manage to navigate and complete the task, however in the survey they completed immediately after, only 1 user reported low confidence the rest saying confident or highly confident.<\/p>\n
In my experience I\u2019ve found it much more effective to ask users to give feedback at a later date, and as well as testing prototypes, going back for feedback after the service is live, monitoring the data and sending out qualitative feedback forms. Also ensuring that you record what the user actually does, not how they respond. This is, of course, a basic in research but it just reinforces that asking alone is never enough! By following up and testing in live you can eliminate any ambiguity and adapt to any changes that you need.<\/p>\n
Ultimately all changes have an impact on our customers and colleagues and our overall aim is to make the customer journey for everyone. I feel really lucky to have such supportive colleagues here who are always willing to give feedback. As user researchers we just need to ensure we are reading the correct responses and outcomes.<\/p>\n