I helped the client articulate a vision for the use of a complex internal system. This was achieved by helping Transport For London (TFL) stakeholders understand the needs of staff when using internal systems. The resulting user-centric principles and requirements were then collated into a proposal for the next phase of development. My role as UX Consultant was to oversee this process.

This is a 3 minute read

The problem

Specific management roles within TFL need an intranet system to supply them information for a range of situations, in a variety of locations. At the time, their intranet was broken into several components or systems, each doing different things whilst tentatively being held together. One system did email, one did scheduling or one did reporting. Lots of people creating their own workarounds to get around the complexity of system managed information. The evolving requirement of staff to be mobile within the transport network only complicated the issue.

With an agreed definition of key user roles, the challenge was to work with relevant stakeholders to envision what a successful (and realistic) system should do in order for them to do their jobs better. This insight would then be used as the foundation of a UX strategy for the next phase of development. Helping leadership understand the needs of workers on the ground.

The process

As the UX consultant, I was responsible for interviewing stakeholders, working with them to understand the opportunities, and then articulating the stories and anecdotes I uncovered.


Stakeholder interviews were conducted to understand a “day in the life” of their role. The people, information and systems within the pattern of that day was discussed in order to understand the current issues. What was evident was the increase of physical notes in order to compensate for the mistrust in the collection of systems they use. Couple this with obscure and complex mobile devices (in regards to usability), painted a picture of frustration.

Combining the interviews with an ideation workshop, enabled me to decipher their anecdotes clearly. Themes developed between the different roles. Parallels in workarounds and strategies with technology limitations became apparent.

Asking stakeholders to map out what the experience is now alongside a map of a desired set of scenarios enabled us to see what the genuine priorities were. Single system sign ins, incomprehensible threads of collaborative changes in documentations and tools to quickly curate content such as photos, were just some of those key markers. The benefit of having the stakeholders with me there, constructing the experience maps [Fig 1], was to understand the “why” behind solutions they have on their mind every day. Understand the distributed cognition within the system they currently operate in. Separate behaviour intent from “solutionising”.

Image: [Fig 1] Experience map
[Fig 1] Experience map


As a key deliverable of this UX consultation, storyboards [Fig 3] were produced to encapsulate the research conducted so far. Details were important, but at this stage of an embryonic project the client needed to visualise the current situation for the organisation leadership. Developing the stories I’d heard in research, I worked with an illustrator to rapidly capture and encapsulate them. These comparative stories of the current and ideal experience were then used to aid the planning of the next phase of the project.

Image: [Fig 2] Sketching out user scenarios from research
[Fig 2] Sketching out user scenarios from research
Image: [Fig 3] Storyboards
[Fig 3] Storyboards


This insight uncovered was just the tip of the iceberg. Being able to help a client visualise what the present and desired experience is, was crucial in setting them on a user-centric path. Design models and stories became the basis of that understanding.

As a consultant, within a short space of time, high level issues and opportunities were highlighted. The client knew what the problems were, they just didn’t know how to simplify the understanding and take it out of a complex technology context. Get them thinking about design problems. That was the value I brought to this brief.


Intranet systems, built on separate platforms and doing jobs in different ways. Wow, that gets complicated. No unified vision or understanding of all those moving parts. Technology decisions sometimes mean that constraints are prevalent, and they really haven’t been thought out from the user perspective.

You can do a lot of good in short space of time though. This project made me realise the importance of thinking and reflecting on a situation. Organisations build systems, and sometimes they don’t work. The key is about effectively understanding why they don’t work.

View more case studies or read more about me.