I* Make Awesome * Bobbu

Photo of Bobbu

"Of course. They have been designing user experiences since 2006. Check out their work for ITV."

The ask

ITV 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 help them fix the UX and UI for a few of their features, over the space of two weeks.

The challenge

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.

The approach

I proposed a little more than just giving them better designed screens; I would take them through 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. ITV were very excited by the chance to learn!


After a brief walkthrough of the screens that ITV wanted me to work on so that I had a basic understanding of what I were 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 I could see what the entire process looked like.

What are I asking of the user?

By putting ourselves 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.

Example questions

  • 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 paying them for?
  • When will they pay them 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.

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 I can work together."

What scenarios are I dealing with?

Now I imagine what kind of situations our users could be in when they come to use the services designed, to see whether I was accounting for every possibility.

Example scenarios

  • 1 extra, 1 agent/service company, 1 episode
  • Multiple extras, 1 agent/service company, 1 episode
  • Multiple extras, multiple agents/service companies, 1 episode
  • Multiple extras, 1 agent/service company, multiple episodes
  • Multiple extras, multiple agents/service companies, multiple episodes

What do I not know?

Finally, I ensured I recorded whatever I couldn’t figure out. This helps put up flags for where confusion can be caused by the interface.

Example queries

  • 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 BJSS and ITV delivery 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 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.

Bright ideas

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 kinda of solutions they were considering. Then I gave our suggestions; to encourage them to consider new ideas, refine their ideas, or point out 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 I wanted solutions to go in.

Sample suggestions

  • 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.
  • Rather than showing large, empty components that depend on actions in other places, hide them and show them only when they become relevant.
  • Where there is an expected maximum number of items that could be selected at once, show that maximum number of items within the viewing window of the scrollable list.
  • 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 trumps 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 to guide the user on this journey.

I can rebuild

Taking each journey, step, and problem one at a time, I create a first pass at a redesign of the features I were looking at; using the extensive understanding I had built, and the ideas I had collaboratively explored. This redesign took the form of a high-fidelity, clickable, non-functional prototype made entirely in Sketch and following the ITV style guide.


I took this prototype to the ITV and BJSS 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 serves the user needs and guides the users through the journey.

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 could further identify problems and how I could resolve them. I used the criticisms to further refine our collective understanding of the aims of, and problems with, the system.


Armed with this additional information, I revisited the design, refined our ideas or tried out new ones, and came back to the team until I had something everyone was happy with.


I came to the end of our two-week engagement having covered four user journeys from examination and analysis, through to new designs that ITV and BJSS were much happier with. I had developed an explicit understanding of the role the new system played for the users. I 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.

Client satisfaction

Well, they've asked me to go back when they next get into trouble, so I reckon that's a pretty good sign.