I helped the client iteratively improve a web app by understanding the flow of information within their service. As a new tool within an organisation transitioning their workflow to 100% digital means, the information and tasks required by staff needed to be intuitive in order to succeed. As a UX Consultant my role was to research the service process in order to recommend improvements for ongoing rapid development.
This is a 4 minute read
The client was transitioning their service from a predominantly paper based service to 100% digital. This coupled with significant governmental policy changes, required a very quick iterative cycle for a newly launched MVP that staff and claimants were using within the service.
The evolution of development presented challenges of balancing new feature implementation and user feedback from the MVP service, that was being used day to day. The client and the wider team needed to react to issues quickly and guide project direction due to emerging user needs.
As a UX consultant, I was part of a wide team tasked with this long-term iterative project. On site within a job centre our team consisted of Research, Developers and key Civil Servant Stakeholders.
As an MVP, a set of assumptions were made about the outcomes of using the tool for both claimants and staff. My role, within a small UX research team was to observe the service working, triage issues, work with stakeholders to explore them, and ultimately feedback into the agile build of the tool. Being onsite allowed us to have complete access to all parts of the ongoing service. Observing and working with both claimants and staff.
The core of insight was through ethnographic research. Being onsite everyday within a job centre exposed me to the vast variety of claimants within the service. Seeing how staff approach their day, deal with issues and move information around the system became the lifeblood of data collection.
Thematic analysis [Fig 1] of this data was conducted daily and constantly fluid. The challenge was to control it. How do we prioritise this? What does this mean for the success of this particular user type? The triage of information became integral to the success of subsequent iterations of the MVP.
When identified key issues arose, facilitating collaborative workshops [Fig 3] became one of my key roles. Using service staff and members of our multidisciplinary team, design thinking became an important foundation to begin with. Everyone had an idea of a solution, “add this button and PDF” or “do this feature”.
It was important to ask the team to take a step back. Who is the user? What do they need to achieve? Empathise with them. Using game storming techniques to start with a high-level view, envision an ideal scenario and brainstorm the possibilities within. For me it was critical. The staff understanding of policy and procedure vastly exceeded mine, and as it turns out, their view on their work environment was very user-centric in its view.
Key overarching deliverables were required at key markers in the project. By collating the research team insight into a service blueprint [Fig 4] enabled me to articulate the flow of information through the service. The distributed cognition of several connected tasks and claimant characteristics, when visualised, enabled us to see where issues arose.
It was key that this deliverable, although useful for people to understand the service, remained lightweight and fluid. The service and digital tools were changing on a weekly basis so being precious about design deliverables wasn’t required.
Being onsite on a daily basis gave us the opportunity to conduct rapid prototyping when landed with a problem. Impromptu sketching sessions and guerrilla testing meant we could have formulated a hypothesis, and tested it within a few days.
By having access to a HTML prototyping kit, or even just a few bits of paper, meant we could look at issues within the interaction and content quickly. The key to this flexibility though was having actual working staff embedded in our team. Using them as design partners meant we could constantly throw things at the wall and see if they stick.
Co-ordinating research on site daily as a product evolves over time, gave me the opportunity to solve a lot of UX problems. The client needed to understand how their product was being used and how user needs evolved, as the product did.
By collecting and visualising research, I was able to bridge the service “in the wild” to the ongoing agile development. The visualisation of that research became richer through a leadership role that facilitated design thinking within the wider project team.
Deciding on an effective feedback loop from research to development (remotely) is hard, and so important to be clarified at the beginning of a project. Communication lines and commitment to the prioritisation of issues that are happening right now is also a key negotiation with product owners. For me spending a bit more time at the start to define a logical plan for UX is a big learning point for me. This means clearly laid out assumptions and business objectives with their associated success metrics.
What surprised me in research? Get a digital tool out of the way. It needs to disappear into the background quickly. When a service is conducted face to face with people, especially when it comes to a family having enough money to live, don’t complicate the situation. The tool is there to capture the moments of a relationship between claimants and staff, not to become a frustrating dominant presence. People in stressful situations need to be treated with engagement. Not as an extended questionnaire exercise.