The challenge

Design the Freedom of Information product and service for Transport for London. In 3 weeks.

One that will serve the people of London effectively in ensuring Transport for London is operating as transparent as possible.

The outcome

A service that effectively serves the needs of Londoners in getting the information they require.

Improvements to the whole design of the service. From how TfL FOI staff take requests all the way to how users find the information they require.

A more intuitive and streamlined approach to finding existing FOI requests and answers. Meaning FOI staff aren’t wasting their time answering and signposting users to existing answers.

A more thorough and helpful user experience when a user submits their request for information. Meaning FOI staff aren’t wasting their time following up and clarifying what users want to know.

More efficient TfL FOI Case Officers who are now better equipped and able to serve users quicker.

My role

Discovery research

Reviewed TfL quantitative data on existing FOI usage and needs of users.

Interviewed FOI subject matter experts (TfL FOI Team, Data Protection Team) to gather insights which later informed product design.

Collaboratively with Product Owners created KPIs to ensure the product meets user need and business objectives upon launching.

Landscape review

Discovered, tested and reviewed other Freedom of Information products and services.

Uncovered what they do well, what could be improved and areas where we could take inspiration from.

Stakeholder engagement and discovery

Moderated co-discover and co-design workshops with senior stakeholders and Product Owners.

Unearthed insights, testing early look and feel and visual language. Ensuring stakeholders were all aligned in the direction we were taking the product.

1 to 1 interviews with subject matter experts and Product Owners to discover further valuable insights.

Product design

Paper sketches through to greyscale wireframes through to UI Design of the Freedom of Information product for a number of user journeys.

Worked within the TfL style guides and collaborated with Engineering throughout to ensure the final outputs were feasible for the fixed launch date of the service.

Prototyping

Led an intense week of prototyping and testing with users. Making iterations throughout the week following testing sessions with users.

Testing different information architectures, journeys and visual styles across desktop, tablet and mobile.

Usability testing

Moderated usability testing sessions with a range of users.

Boosted testing and user feedback through on the street Guerrilla Usability Testing with members of the public.

Presentation and rationale

Solely presented the final designs, validated user journeys and specifications for build to the FOI Product Owners, Product Design Team and Engineering.

During this project I was working with a User Researcher.

The context

What is Freedom of Information?

Freedom of Information (FOI) is a way for the general public to attain information and facts and figures, from public organisations. Organisations including the UK Government, The Metropolitan Police, NHS England, and of course, Transport for London.

What is TfL Freedom of Information?

TfL Freedom of Information is the place where the general public can submit FOI requests and uncover existing FOI answers relating to anything and everything TfL.

Why was there a need for a product?

The old service wasn’t fit for purpose anymore.

TfL FOI requests have been steadily increasing over the years. As such the old way of managing and processing FOI wasn’t effective. It certainly wasn’t meeting user expectations.

The old service was also creating internal inefficiencies within the TfL FOI Team.

A digital product was defined as a solution to tackle this issue, to provide a better user experience, and to provide a better experience for the TfL FOI staff.

Discovery

We started the project from a standing start. The Freedom of Information Act, potential user needs and organisation objectives was alien to my colleague and I.

We were truly entering the unknown, and given we only had 3 weeks to deliver an entire product validated by both user and organisation, we threw ourselves into the deep end.

Observing and shadowing

Given the unknown and ambiguous context we found ourselves in, we worked within the TfL offices and spent as much time as possible with the TfL FOI Team.

We immersed ourselves in their world, observing and shadowing FOI Case Officers, user interactions and day to day processes.

This immersion allowed me to spot opportunities where a digital product and design thinking could improve the experience. For both user and TfL FOI Case Officers.

Stakeholder workshops

We also held three co-discover and co-design workshops with stakeholders. In which we got hands on with them discovering issues with the existing product and service. And also getting their ideas for the product at low fidelity level.

The workshops were important for a number of reasons:

⁃ It bought key decision makers from different parts of the organisation into the process and our way of working

⁃ It uncovered valuable information about the TfL FOI Team - their set up, ways of working and internal processes we needed to link up with

⁃ It uncovered both quantitative and qualitative insights regarding user behaviour

⁃ It brought together different disciplines within the organisation who each had their own opinions on how the product should feel and function

⁃ Most importantly, it gave my colleague and I the opportunity to align all stakeholders behind one vision for where we were taking the product

Depth interviews

To compliment the observation I also organised and led depth interviews with FOI Case Officers and the Product Owners.

Unearthing the organisations needs and objectives, getting their thoughts on the vision of the product, and how they saw the product working from a users point of view.

The depth interviews also proved valuable as the FOI Case Officers had a lot of user insights they were able to share with us. 

After all, the Case Officers are dealing with many users day in day out, taking on a large volume of requests and interacting back and forth with users to clarify requests, uncover further information, and ensure they’ve met user expectations with their response.

The interviews often evolved into collaborative co-discover working sessions, sketching out ideas and potential solutions to problems uncovered during the depth interview.

Landscape review

During the Discovery phase I also completed a review of similar products and services.

The review allowed me to:

⁃ Uncover other digital FOI services and products

⁃ Look at what they were doing well, and how

⁃ Run through common user journeys and test the user experience throughout

⁃ Identify improvements to be made, and that I could incorporate into my product design

⁃ Uncover what happens after use of the product - confirmation communications, follow ups, progress reports. The full service experience

⁃ Read genuine FOI requests to get an understanding of what gets asked, the level of detail and how frequently FOI requests asked to get clarified - a key issue raised by Product Owners and stakeholders

⁃ A source of visual and functionality inspiration throughout the project

During the discovery phase we didn’t speak directly to any users. This was because we had a £0 discovery research budget.

Of course we could have done Guerrilla discovery, but we figured stopping random members of the public and asking about their experiences and expectations around the Freedom of Information Act, and an online service regarding the Act, we would be left with confused faces.

So with user insights and data from the organisation, combined with the competitor review, we felt in a good position to begin coming up with ideas to solve the problem, and address user needs in this context.

Ideation

With a solid base of research behind us we began ideation.

Mapping user journeys

We were aware of key user journeys that the product would have to support, these were uncovered during the Discovery phase. 

They were:

⁃ Making an FOI request

⁃ Finding existing FOI requests and responses

⁃ Reviewing answered requests and actin upon them if need be (share, follow up, report)

With the user insight and inspiration gathered we started to map out the user journeys above. We did so using Post-it notes so we could move at speed and try new ideas to streamline the journey.

Working in this lo-fi manner enabled us to try many ideas quickly and for my colleague and I to be critical of what we were producing. 

We could try something, mock it up and test it in a matter of minutes. If it didn’t work we would learn about why it didn’t, and take those learnings into further ideation.

When we felt we had the journeys in a good place we presented back our thinking to the Product Owners and subject matter experts.

Getting their validation before digitising the journeys or creating screen designs was very important. If we didn’t get their approval on the journey in it’s lo-fi form we would have wasted valuable time, and given we had to deliver a fully designed validated product in 3 weeks, we had no time to waste.

The review went well, they were happy with our proposed user journeys and the knock on effect they would have on the TfL FOI Team, something else we were also considering when designing the journeys.

Designing the experience

With approval on the user journeys we began creating the screen designs and interactions for each stage of the journey.

We had been told the product would be largely used on desktop, given it's nature and typical user base. However we knew this may change over time, so with that in mind we designed mobile first, knowing that our designs would scale well to work on desktop too.

Similarly to mapping the user journeys we kept our initial design thinking and exploration lo-fi.

Sketching on paper, whiteboards and creating page elements using Post-it notes that we could move around and create new pages with.

This was mainly so we could try many ideas very quickly, it worked.

Between my colleague and we tried various ways to solve the problem, stress testing each one with a range of journeys and use cases it would need to accommodate.

We began to build the fidelity of the design work as the direction and flow of the experience was being validated by the Product Owners and FOI Team.

We were regularly reviewing with our stakeholders, taking them through paper prototypes and greyscale wireframes. Just the right level of fidelity to communicate the design solution.

Over the course of a week we cycled through many iterations of the product. Through reviewing user insights, covering the range of use cases we needed to accommodate and also stakeholder feedback, by the end of the week we had a lifelike interactive prototype, ready to test with users.

At the same time we were also designing the information architecture and thinking about the full service experience of using TfL FOI. Designing the communications users would receive so they felt reassured that their request was being dealt with and a response was on it’s way.

Prototype, test, iterate

After a thorough week of designing and iterating our design efforts internally, we were in a good position to test the prototype with users.

I led an intense of week prototyping and iterating following feedback from the user testing sessions my colleague and I moderated. - Well aware this isn't best practice. But we didn't have budget to bring in a User Researcher who hadn't worked on the project. I like to think we did our best to remain impartial, not lead and stay clear of bias.

One day we would do a full day of testing with users, setting tasks and getting them to complete common journeys. Asking probing questions and observing as they made their way through the prototype. Seeing first hand the difficulties they encountered and the questions they had at different stages.

The next day we would review the feedback, decide on design decisions and iterate the prototype and discussion guide.

We ensured that the TfL Engineering Team who were going to be building the product observed some of the sessions. I also got along the Product Owners and some TfL FOI Case Officers, just for them to see first hand what users experience and expect during their journey of using TfL FOI.

We followed this process for another round of testing with more users.

From there we took our tested, iterated and fairly well validated prototype out onto the streets of London. We conducted Guerrilla usability testing with many more people. Getting a thorough and diverse viewpoint on the prototype and content.

Presentation and handover

With an intense but productive week of designing, prototyping and iterating complete, we had a full product we were proud of, and one that was serving users well.

We were getting approval and sharing progress with the TfL FOI Team, stakeholders and TfL Design Team throughout the project.

As such, when it came to me presenting back the final product, user journeys and handover document we created, they were all for it. No late nasty surprises, for them, and us.

The Hub

TfL Freedom of Information Hub (home), here the user can jump into a range of journeys to get to the outcome they require. Search and review latest requests given prominence to encourage users to look for their answer, before requesting - benefiting both user and organisation.

Search

Search the entire TfL Freedom of Information database of requests and responses, sort and filter enables the user to find what they need quickly. Designed mobile first (like everything) making the mobile experience just as easy to use as desktop.

Make a request

A simple form with added functionality to improve the users experience, and to improve internal organisation efficiencies. Tool tips available to the user to guide the creation of their request, along with clear signposting to review existing responses.

Request and response

Users can review the full request submitted by others, and the response from Transport for London. The information is formatted in an easy to read way, and out of shot attachments related to the response are visible for users to explore.

The product launched in January 2017, it has been well received by users and internal teams related to Freedom of Information within Transport for London. But, most importantly, it's serving the public effectively in giving them the access to the information they need.

TfL Freedom of Information

And in my spare time…

While working on this project I discovered Bots on Messenger and chatbots in general. Fascinated by the technology, user experience and general potential I thought Bots may have on all of us I looked into them.

I ended up compiling my research and learnings into a presentation that I took the company through one Friday afternoon. During my discovery of Bots I was testing lots, good ones, bad ones and really uncovering their use cases. Where is a Bot useful and where it can provide a good user experience...

That's when it dawned on me that a Messenger Bot would work very well to deliver the TfL Freedom of Information service, or any Freedom of Information service for that matter.

So I decided to do the thinking of how it would work, and mock it up... 

Up next BlackRock - Two new validated concepts in two weeks