A media company were working with BJSS to build an MVP which would replace the system they currently use to pay their actors. They knew that some of their designs were not working quite right but couldn’t identify how to fix them. They asked for me to come on board for two week, to help them fix the UX and UI for a few of their features.
There was no budget allocation for user research, so this would rely entirely on my knowledge and experience. They were also enthusiastic about UX, but inexperienced. There was an existing way of approaching the problems, and a lot of built up ideas for how to solve problems that would need examining and potentially rebuilding. This included a static style guide that was not optimised for expanding, as an atomic design system would be.
I proposed a little more than just giving them better designed screens; I would take them along on my UX and UI design process, to provide them with some of the tools and skills that I use in my approaches. That way, they would be better armed to avoid making the same mistakes in future. The project team were very excited by the chance to learn!
After a brief walkthrough of the screens that they wanted me to work on, so that I had a basic understanding of what I was looking at, I went off and pulled them apart. Not to immediately redesign them, but to get as close to a new user’s experience of what the interface would tell them as possible.
I interrogated the design for a few things:
What does the user journey look like?
First, I broke down the features into a user journey, and presented them as a journey map so that we could see what the entire process looked like.
What are we asking of the user?
By putting myself in the shoes of the user, I took the information required by the interface and formed it into questions, so that I could explore the service from a conversational perspective.
Who are they working with?
What are they working on?
When are they working?
What work are they doing?
Who manages their payment items?
What are the details of their financial agreement?
What items are they being paid for?
When will they be paid for those items?
What are the user needs?
I attempted to extract the user needs from the designs. As with everything else, this wasn’t to find the real user needs, but to allow us to later examine the disparity between the perceived needs and the real ones the team already knew.
Example user needs
"As a production manager, I want to record the details of the agreement made with a contributor to an engagement, so that we can work together."
What scenarios are we dealing with?
Now I imagined what kind of immeidate variables could contribute to the situations our users could be in when they come to use the services designed, to see whether I was accounting for every possibility.
Finally, I recorded whatever I couldn’t figure out. This helped raise flags for where confusion could be caused by the interface.
How are the relationships with multiple agents/service companies and extras managed and recorded on a shoot?
What is the reasoning and actions around submitting multiple episodes at once?
Are being able to change details in bulk desirable?
How much repetition is acceptable?
Using these key points to steer the conversation, I started collaboration with the project team. I did this first by walking through the journey, using goal & task analysis on each step of the journey, in the light of the assumed user needs and scenarios.
What’s the problem?
By looking at the assumptions drawn from our examination and comparing them with the intentions of the delivery team, it was very easy for us to identify where the design wasn’t meeting the requirements of the user, or the business. I listed these out as I walked through the journeys, and prioritised them according with their complexity, as well as their importance to both users and the business.
With the problems clearly defined, I then began to look at how to fix them. I started by asking the team what they thought would be good solutions, to get an idea of what kind of solutions they were considering. Then I gave my suggestions; to encourage them to consider new ideas, refine their ideas, or point out potential problems with their suggestions.
By the end of this session, I had a clear idea of what the problems were, what priority they were in, and what kind of direction was desirable for solutions to go in.
Avoid large modal windows that require scrolling, as they quickly become difficult to interact with.
Avoid toggling between two components being visible when there is a need to see both at once.
Rather than showing large, empty components that depend on actions in other places, hide them and show them only when they become relevant.
Larger click areas on actionable targets helps accuracy and ease of use – ideally 45px square minimum
Progression action buttons to the right, cancellation or back buttons to the left; this gives a feeling of moving forward to each positive action, due to a heuristic created through left-to-right reading.
Microcopy on buttons should specify the exact action to be taken, not "cancel" and "confirm". Instead use terms that make the action clear, and match the question asked.
Coherency of the current screen should take priority over consistency across the entire service.
Time to bring some ideas into reality!
A new map
Firstly, I rebuilt the journey map to include anything I missed, or that the original UI had not covered, so that I could use this to shape the new interface towards better guiding the user on this journey.
We can rebuild
Taking each journey, step, and problem one at a time, I create a first pass at a redesign of the features we were looking at; using the extensive understanding I had built, and the ideas we had collaboratively explored. This redesign took the form of a high-fidelity, clickable, non-functional prototype made entirely in Sketch and following the client's style guide wherever possible.
I took this prototype to the project team and walked them through the design. I explained how the information I had gathered had informed our decisions, especially focusing on showing how I had applied UX principles to produce solutions that quickly and efficiently serve the user needs while guideing the users through their experience.
They were very happy with most of our new designs - but of course, not all of it was right. For every critique I pushed the team to explain their reasoning, so that we could further identify problems and potential routes to resolve them. I used the criticisms to further refine our collective understanding of the aims of the system, and the problems it had achieving them.
Armed with this additional information, I revisited the design, refined our ideas or tried out new ones, and came back to the team until we had something everyone was happy with.
We came to the end of our two-week engagement having covered four user journeys, from examination and analysis through to new designs. I had helped the client develop an explicit understanding of the role the new system played for the users. They had a clear idea of the benefits of the new designs over the old, as well as how and why they were designed. Each suggested design change had been explored to consider its priority based around rough estimates of impact and delivery cost. This meant the client felt confident in their decisions, understood the mechanisms they had used to make them, and was empowered to continue with the work in future as a team.