A leading broadcaster was building an application to track content coming into the business. The app was going to replace manual processes, clunky tools and be a one stop shop to manage content delivery.
I joined the team at MVP stage when some development work was done but the users couldn’t make sense of the app. I was the sole designer and was asked to improve the UX of the tool.
Here I’ll be talking about one particular feature among many.
There was a new request form to track content, which reduced the number of forms and input fields users had to fill in. However, it was found unintuitive and confusing.
So I started my research to find out why. I talked to users and stakeholders to:
- Build up domain knowledge
- Understand the use cases and processes
- What didn’t make sense, and why
Identified the problem
- The new form couldn’t cover all scenarios.
- There were gaps in the information flow.
- There was too much reliance on the user’s know-how, memory and experience.
Moreover, users had workarounds for edge cases that they had to remember, or ask their seniors for help. Forgetting these would result in errors and operational overhead. Current documentation they used as a reference was lengthy and it took years to master the process with it’s tricks.
Taking the form apart
Making a form intuitive has more to do with information architecture than visual styling.
So I asked lots of questions to get into the depths of it and worked out the information relationship between the fields.
By extracting dependencies, expected values and different routes to filling the form, I figured out what information should already be available in the database, and what absolutely required user input. I discovered many instances where users were filling information that the system should already know, potentially causing errors, overrides and information clashes.
I mapped out the actual information hierarchy – rather than the one seen on the form and noticed gaps.
Seeing there are missing pieces, I decided to take the form apart. This helped me see what information can be auto populated, hidden and what’s the right input to ask for at the right time. I went back to the users to fill the gaps, and uncovered hidden requirements and edge scenarios where users hacked the form to note special cases..
Putting it back together -with significant improvements
Then I put the pieces of the form back together in a new order which made it possible for the system to auto-populate some fields depending on the previous input.
1 – Programme is the highest level of information in the request form. If users are creating the request for an existing programme, then all programme level information can be auto populated. The fields would still be editable, as the users occasionally needed to make changes. This would massively reduce input errors and information the user need to have at hand when creating the request.
2- Previously users had to know the exact number for the series they are creating the request for. It’s not needed in the new form anymore as I figured the system can predict this information based on available data. They simply need to answer questions in more human terms. Users loved it. To explain how this would work to developers, I wrote the pseudo-code of the logic. PO and devs loved it.
A multi step wizard
The form was still lengthy and there was room for further improvement. I broke the form into a sequence of chunks, to reduce the complexity of the task and provide a sense of progress at the same time.
By breaking it up this way, it also became possible to present different sets of questions in the next steps, depending on the answers.
User could now switch new programme entry / existing programme search modes and the app could populate all the programme-level data. This way there would be less reliance on the user’s knowledge and memory, and human errors would be reduced.
Users no longer needed to know the exact series number for the request, as the app could pull this information from a reliable source, that is the database. The information was visible to give confidence that they have taken the right action.
The request summary component become handy to track their requests later.
I tested the prototype with users, who loved how it made the task much easier. The approach reduced potential errors, was easy to understand and reduced the burden of decision making for the user. I presented the work to the product team, who agreed that the system can bring up the data I suggested. The multi-step wizard was built soon after.
“Massive thank you for all your work to date, it’s taken us a huge step forward” – Product Owner