Hi, we’re Jen Rahman (UX Interaction Designer) and Paul Welsh (User Researcher) based at the Digital Delivery Centre in Newcastle.
If you’re interested in how we manage the process of designing digital services then read on and we’ll tell you how we’ve created a user needs prototype to help us to keep all stakeholders bang up to date with progress on digital service projects, no matter when they join the project.
Work here moves at a fast pace, progressing each digital service project quickly, with design often changing from sprint to sprint. To keep everyone up to date on progress and engaged we hold fortnightly Show and Tell showcase events. This is where stakeholders are invited to view a demo of our digital service and we give updates on the work the team have completed in the previous sprint.
During these sessions we encourage stakeholders to feedback and voice any questions or concerns they may have about the direction of what we are doing.
As interest in our service has grown, so has the amount of stakeholders attending the Show and Tell. With new stakeholders joining the sessions each time we noticed the same questions were being asked again and again by different stakeholders who were unaware of what we’d discussed at previous Show and Tells.
So this got us thinking. We needed to find a way to reduce the repetition of answering the same questions over and over again, bring everyone up to speed but without discouraging stakeholders from taking an interest in the design process.
So we created our prototype. We put together a body of work within the prototype kit that showed how our service had evolved over time into it’s current state.
Our ‘user needs prototype’ is an on-going piece of work that we update to show design progression, log user testing analysis and chronicle which user needs we have met, as well as new emerging needs that we’re working towards.
We take the ‘best of’ pages from the latest design work to show the design hypothesis behind the changes compared to last sprint. Over time we’ve added navigation tools and an index page so stakeholders can easily move through each stage, as well as jump straight into our current work. There is a page after each prototype that documents the key findings from the user research session it was tested in. We also document what changes and tweaks we want to make to improve the next iteration of the prototype.
We group each feature of our digital service into key user needs such as ‘what happens next’, ‘why has this happened’, a ‘help’ section and other quick wins over technical constraints that our team faced. We then give an overview of each sections user need so stakeholders can fully understand what we are working towards and why.
By grouping each aspect into key groups we’ve chronicled how our service has progressed to try and meet these core user needs, first at an MVP (Minimal Viable Product) level, and now at a wider phase 2 level (the second part of the service that gets delivered that builds on the original release to make a better functioning product).
It’s an on-going piece of work which we update regularly to highlight some of the ‘best of’ moments as well lessons learned.
After demonstrating the user needs prototype at our Show and Tell and giving stakeholders access to look through it in their own time there seems to be a greater understanding from them how the design has progressed along with a noticeable reduction in the same questions being asked!! :).
The user needs prototype has also been a useful tool when it comes to GDS updates and assessments. Previously we kept independent logs within Confluence to map design changes and user research, which meant there was a lot of digging required to unearth how each design related to the user research.
Using our user needs prototype means we now have quick visual reminders and prompts to discuss with others about how we got to this point, each one backed up by evidence and analysis from every user research session.
We have also shared this work with other teams within the Digital Delivery Centre to show changes we’ve made based on user needs, not business requirements. It’s been really well received.
We’ve found it to be a great reminder of how far our UX team have come in developing the service and keeping our scrum team encouraged and engaged with easy access to the bigger picture.
It would be nice to say job done - but there’s always room for improvement when you work in an agile way so we’ll keep at it and hopefully soon we’ll change the word 'prototype' to something more permanent.
Jen and Paul
And don't miss any of our blog posts, sign up for email alerts