TfL STARS

Motivating school children to travel actively

The challenge

Redesign a broken service and product so that London school children are motivated and empowered to travel to school in a sustainable and active way.

The outcome

Societal change.

An experience so intuitive schools are letting children use it to plan and document activities, therefore freeing up teachers to encourage active travel even more.

Restored faith and trust in the TfL STARS programme.

Redesign of the whole digital experience and service offering, one that school teachers and Borough Officers are proud to promote and use. 

Customer centric clients. Towards the end of the project the Product Owners were organising workshops with users and arranging meetings with schools. Worlds away from where we started. Lovely to see.

My role

Alongside a senior designer I was:

• Planning

• Interviewing

• Observing

• Visiting

• Designing

• Workshopping

• Card sorting

• Prototyping

• Testing

• Iterating

• Moderating

• Presenting

• Persuading

• Sprinting

Repeat

A short history

STARS is a scheme run by TfL that aims to encourage young Londoners to travel to and from school sustainably and actively.

As you can tell from the stat above, (50% of traffic in London between 8.00am - 9.00am is caused by ‘educational trips’), getting an initiative like this working well is in TfL’s best interests and their ongoing mission to reduce congestion in the capital.

However, the current digital and service experience is very poor. It’s outdated, frustrating and taking up too much time from school teachers and Borough Officers, STARS’ main users.

So much so that schools and Borough Officers are threatening to leave STARS if the experience doesn’t improve.

From a business point of view it is also not working. Given the current application has so many flaws it needs TfL staff to keep it running and manually complete tasks. In it's current state, it’s simply unsustainable.

What’s the problem?

Before my involvement on the project my colleague spent a month discovering the current state of STARS and the true problems to be solved.

He met with schools and Borough Officers and uncovered a range of issues. From not being able to update and share content with other schools, to, the system being overly complex for school teachers to use, to, finding it difficult to extract and report on meaningful data.

Setting the vision

My involvement in the project started at this point.

My colleague had discovered a ton of insight and we were now in a position to begin to synthesise it, create meaning from it, and set a clear direction and vision for where we wanted to take STARS, one that our stakeholders needed to get behind.

To do so we created three future journeys that encompassed the main STARS tasks that schools do during the academic year.

Future journeys

     1. Initiatives & Activities

Schools will get inspired and find activities to do that will encourage modeshift. Simple documenting of evidence and comparing the activity the user did to how other schools did it.

Modeshift = Shifting your mode of transport to something active and sustainable.

     2. Modeshift surveys

Individual classes complete their own modeshift surveys and upload the results. This takes the burden off the one teacher responsible for STARS.

Simple data visualisation of survey results lets the school teacher analyse quickly how they’re getting on and the types of activities they should prioritise to achieve greater modeshift.

Modeshift surveys = All students and teachers at least once a year document how they currently travel to and from school, and how they would like to. This information is recorded into the Stars application.

     3. Travel Plans

Ability to tailor what goes into a travel plan so it best reflects the school and what the school is applying for.

A polished well formatted document is the output that schools can use to better support their applications with.

Travel plans = A mandatory document a school needs to submit when they apply for something. E.g. Planning permission, extra bike racks, the removal of parking spaces etc.

The STARS system creates the document, pulling in relevant information.

These journeys gave our stakeholders a glimpse into the future and how great the experience could be for schools if this were to become a reality.

It suddenly made the insight gleaned from schools tangible. The stakeholders could see the direction we wanted to take, and they were all for it!

Experience principles

We also created eight experience principles that would guide the future creation. The stakeholders were excited by these principles as they knew it was what schools wanted and if the product was designed following them, it would go down well with schools and Borough Officers.

The experience principles we created were:

These were printed big and stuck in our STARS War Room for all to see. They acted as a reminder for where we were heading and the experience we all wanted to create.

A powerful metaphor

We also came up with a metaphor to describe a key part of the application - getting inspired, finding and planning activities to do.

We decided all activities would be on Activity Cards, the initial idea was sparked from recipe cards you get from Hello Fresh and Waitrose.

But the metaphor went further than just a card. See a recipe has a set list of ingredients and a method.

But nobody follows a recipe exactly as it states.

You don’t like one thing so you replace it for another, you really like one thing so you add a bit more, you like it a bit more well done, so you leave it in longer, you don’t have one ingredient so you leave it out. You get the idea.

Everybody tailors a recipe to suit their individual needs. But ultimately, the outcome is largely the same for all.

STARS has to work across nurseries, Special Educational Needs (SEN) schools, primary schools and secondary schools. There was no way we could create activities that all schools could and would follow to the very last detail.

So we created Activity Cards. Use them as a guide to create the activity that works best for you and your school. The cards could also be printed and stuck around schools to encourage active travel further.

Lo-fi prototype

We also created a simple lo-fi prototype, again to give a glimpse into the future of STARS, it’s future functionality and value. It was another asset that helped tell the story of the vision and what we wanted to achieve.

The tools worked, the Product Owners were behind us and the vision.

Mobilisation phase

Equipped with all of the materials above we began a 5 week mobilisation phase.

The main objectives of this phase was to test our hypothesised journeys and prototype, gather further insight and prioritise what functionality should be built first.

Meeting schools

Over the course of the five weeks my colleague and I met with many schools, covering the different types of school that would use STARS. For example:

     - The type of school: nursery, SEN, primary, secondary

     - STARS accreditation level: bronze, silver and gold

     - Inner city and outer city

     - Well performing STARS schools - what’s their secret, why are they doing so well?

     - Poorly performing STARS schools - Why are they disengaged? Why are they not doing as well as others? What’s holding them back?

Each have their own unique needs that one STARS application would have to serve.

With each session we would give the hypothesised journeys to the school teacher responsible for STARS and the prototype. We wanted to validate if the journeys were desirable from a user point of view and if they saw any difficulties in what we were proposing.

With the knowledge gained from each session we would go back and iterate on the journeys and prototype and test again with different schools. We would also use the time to conduct discovery research into areas we wanted to know more about.

We invited the STARS Product Owners along to every session with schools. They hadn’t had much interaction with their users before my colleague and I rocked up. It was great as they were able to see first hand the surprise and delight from schools as they played with what we were proposing.

It was easily the best method for the Product Owners to buy in to how we were proposing the future of STARS should function and feel.

Meeting Borough Officers

In parallel to meeting with schools we also met with Borough Officers. Borough Officers look after all of the schools in the London borough that they represent.

We knew getting the Borough Officers on side and happy with the direction and ultimately what would be produced, would be integral to the success of the new STARS.

So in the five weeks we conducted two co-discovery and co-design workshops with Borough Officers representing different London boroughs.

This was for many reasons, firstly, to get their backing behind our vision and direction. As stated above we knew the Borough Officers were an important stakeholder to please.

Secondly to pick their brains on issues schools were facing. They each represent so many schools and deal with STARS issues on a daily basis, they were able to give a really good insight into the pain points and needs of schools.

And because they knew what their schools would like and dislike they were the perfect people to conduct a co-design with. They understood what the experience their schools needed.

We also met with them in their offices and conducted more thorough interviews and testing of the journeys and prototypes 1 to 1.

Mobilisation outcome

By the end of the mobilisation phase we knew we had a product that was desirable from a schools and Borough Officer point of view.

The speed in which we were working allowed for quick iterations and a constant feeling that the product was progressing and getting closer to what schools needed.

Getting ready for build

The mobilisation phase was also used to prepare ourselves for the build sprints that we would be embarking on shortly. Working with a Business Analyst and Project Manager to understand the development effort needed, and planning the team that we would need to deliver the outcomes we wanted.

Working alongside the Business Analyst my colleague and I produced epics, and also a prioritised list of functionality to be built over future sprints, balancing business requirements and the user need.

Build sprints

With the Mobilisation phase complete and the team assembled we began product development sprints.

I was part of a large multidisciplinary agile team working in 2 week sprints. As a team we were delivering a new part of the product quickly and often, and without fail we were delivering something new at the end of every sprint.

It was my first experience working in an agile development team and luckily it was a good one. We were under the supervision of an experienced Scrum Master who followed agile methodologies strictly.

Before each sprint we would all do sprint planning as a team together. Story pointing how much development effort would be needed using the Fibonacci Sequence.

Daily stand ups were the norm, and they were done properly. You really felt you had a good idea of what each person was working on, and if they needed supporting.

And at the end of each sprint we would conduct a retrospective, as a full team. Discussing how we all thought the sprint went, what we wanted to start doing, stop doing and continue doing.

Sprint style

My colleague and I ran one sprint ahead of development. This was to ensure development had enough to build. By being one sprint ahead we always had new functionality, screens, interactions to talk through and handover to development.

Working in an agile and iterative fashion there was no documentation. We would check in with the back and front end development leads during our design sprint to ensure what we were proposing could be built and built in sufficient time.

And then when they came to build it we would give them a demonstration of how we envisioned it working, normally through an interactive prototype and then sit with them if they had further questions.

Being located in the same space if there were any challenges that arose, or if they were unsure on something, they would just walk over and we could answer their query.

The two week sprints for me were commonly split as shown below.

Time with our users

During the sprint around 25% of my time was spent going out and meeting our users, the school teachers, students and Borough Officers.

With every session we had with schools we split our time 50/50 between testing what we had designed for the design sprint we were in. And conducting discovery research on the part of the product we were going to be designing in the next sprint.

This method allowed us to test and iterate upon the work we had produced in the current sprint. But it also gave us a good grounding of insight that set us up well when we came to design the next part of the product, in the next sprint.

Design process

The bulk of my time during the sprint was spent designing the service and product and doing so collaboratively with my colleague, the Business Analyst and front end developers.

With every sprint I was designing a new integral part of the STARS application. From how to inspire and encourage children to travel actively to school, to, the process of uploading activity evidence and what accreditation that links to, to, how to conduct modeshift surveys and present the complex data in a meaningful way.

These were big design challenges that we were tackling in 2 weeks. No tactical tweaks.

My design process during the sprints looked a little something like:

Discovery

Reading into insights relating to the user problems the sprint was solving that either I or my colleague had uncovered in previous sprints or in the Mobilisation phase.

Product owner involvement

Interview the STARS Product Owners to see if they had further insight and hypotheses on the challenge I was faced with. Quick and dirty co-design to draw their ideas out and begin concepting.

Concepting and sketching

Taking all that I had found out and begin creating solutions to the problem, all at a lo-fi level, always on paper. Working collaboratively with my colleague bouncing ideas off of one another.

Depending on schools' availability I was sometimes lucky enough to test with them at this stage. Schools don’t have much time to give away, so normally we fitted our processes around them.

Review

Review the work in progress with the Product Owners, Business Analyst and front end development for feedback on desirability, feasibility and to start deciding on the general direction to take.

Wireframes

Taking the most favoured sketches and creating wireframes of them, iterating the designs from the feedback where necessary.

Test and iterate

Get the proposed solutions in front of schools and Borough Officers for feedback. Iterate and test as much as time and bookings with schools would allow.

Keep the Product Owners informed with where the solution was and the feedback we were receiving. Ideally bringing along the Product Owners and the development team to see the user testing first hand.

Over time I found the best way to keep the Product owners engaged and involved was by ‘showing the thing’. We stuck the designs for the current sprint we were on in our War Room and covered them in user feedback post-it notes.

UX walkthrough

Taking the team (which includes the Product Owners) through the final ‘UX solution’.

By keeping the Product Owners and the core team in the loop of what we were designing throughout the sprint there were no nasty surprises during this stage when we walked through the final solution.

The core team was part of the process of creating the final solution, as such, they were all behind it.

Visual design

Working alongside my colleague to finesse the designs further and apply visual design to them.

Visual design review

Walkthrough of the visual design output with the Product Owners and lead front end developers. In which I would discuss my rationale and make tweaks if and where necessary.

I would usually create an interactive prototype to help tell the story better to development and the Product Owners. Seeing the screens in a full journey and something the team could interact with helped get the solution across better than just static screens.

Introducing STARS

TfL’s STARS accreditation scheme inspires young Londoners to think differently about travel and its impact on their health, wellbeing and the environment.

Get inspired

Schools can now find a range of activities to complete that will encourage active travel. They have the option of filtering by areas of focus should they wish to hone in on a particular type of activity.

Compare against schools

Schools can view how other schools are getting on and how they’ve got to their accreditation level.

See how others have done it

Schools can read how other others have adapted Activity Cards to suit their unique needs. The product is now much more inclusive, special needs schools feel a part of the community.

The impact

STARS launched in October 2016 ahead of the upcoming academic year. So far it’s been well received by schools and Borough Officers.

"I really like the overall layout as it has a lot of information but makes it easy to absorb. The transition from page to page for information is easy to comprehend. Looking for schools is easy and I really appreciate schools details being automatically updated from Edubase. This is a lifesaver! Overall, very happy."

Carla, Westminster Borough officer

"I’m loving the new site. It is very user friendly. I’ve added loads already!! That’s the beauty of the new site! It’s really easy to adapt titles etc to make it relevant for individual schools. Also, it looks so lovely!"

Anika, Deputy Head of Wormholt Park Primary School

"The system looks better than I could have imagined – I am so glad that the direction was to be a resource centre rather than a tick box report generator. It looks fantastic, easy to use, logical and exciting."

Jay, Havering Borough officer

"We are really pleased with the refreshed site. The schools had a showcase at the regional STARS seminar and the feedback was excellent. The borough officers have had detailed run throughs last week and again the feedback has been great. The site can already do more for schools and is much easier, simpler, clearer and intuitive to use."

Clare, STARS Product Owner, TfL Schools and Young People Manager

"…I’m so excited about the launch of the new site!! It really is fantastic from what I’ve seen so far!"

Lewis, Croydon Borough Officer

"Thank you, this looks fab. This will really help to make STARS expand further."

Marina, TfL Schools and Young People

Test and iterate

As you can probably tell by now user involvement was ever apparent throughout this project.

School teachers have limited availability so we fitted our process around them and met with them when it worked. But with the size of the product we were designing there was always something to validate, something to discover, something to put in front of the school teachers, and ask, ‘what do you think of this?'

The Borough Officers were a real ally throughout the project. They had so much insight into schools’ needs and pain points, and were always more than willing to share!

Throughout the project we kept in close communication with a small group of Borough Officers who were well representative of all the different STARS schools we were designing for. They became our 'Borough Officer steering committee.'

We would meet with them often and together alongside our Product Owners co-discover and co-create ideas that solved real user need.

Not only did this unearth valuable insight quickly and create many ideas, it also strengthened the relationship between the STARS Product Owners and Borough Officers. Organisational change.

Challenges

‘Non practitioner’ tasks

As I’ve discussed in this article WAE don’t employ Project Managers and Account Managers, therefore those responsibilities fall to the practitioners delivering the project.

This piece of work was a big one, there was a lot going on, many moving parts to it.

So not only was I having to deliver consistent design output, I was also responsible for organising all of our engagements with schools and borough officers.

Undertaking the admin heavy task of finding the right schools and Borough Officers to contact, then contacting them, and then planning carefully when to go and speak with them.

It all had to be well planned so we always had consistent user input throughout the sprint and so there were no clashes.

Doing all of this while in an intense sprint, that sure was a challenge.

I got over this by planning my time very carefully. I was strict with when I undertook the activities described above and blocked out time in my calendar every week. This kept me focussed and ensured I did it every week.

A new team

The STARS delivery team had never met one another before, let alone worked together. Apart from my colleague and I, to begin with we were a bunch of strangers brought in to do a job.

We weren’t aware of each others strengths, weaknesses, ways of working etc etc, this of course became apparent over time. But to begin with it was a real challenge.

Luckily the team was committed to getting to know one another both on a professional and personal level. We knew if we did, and we trusted one another then in the long run it would hugely benefit the product.

I put the team integration largely down to our Scrum Master. He was ever committed to get the team bonding and understanding how we worked. From team lunches, to obscure team building exercises, to motivational exercises, he brought us together as one.

I learnt a lot about team happiness and how to get a product team gelling together as one from him.

Design and development collaboration

As stated above this was a brand new team, a bunch of individuals with no prior experience of working together.

This proved problematic at the start of the project when my colleague and I, the designers, were trying to collaborate with front end development. How to pass designs to them, review check-ins, adjusting screen designs etc.

It took us a couple of sprints to really get going and working in an efficient manner that pleased both us and front end development.

Through trialling new pieces of software and ways of working, and then meeting up consistently to discuss how we all thought it was working and where we could improve our process, we soon had a well oiled machine.

Constant communication was also a big factor while working out the best way we could work together. Just one of the many reasons why being located near your development team is hugely beneficial.

Learnings

This was my first time working in a team alongside the guys building the product I was designing. Consequently I learnt a lot about agile design and development and good product teams.

So much so I complied my learnings and experiences of working in the successful STARS team, compared to a not so successful product development team I worked with afterwards. 

You can find that article here.

Up next BlackRock - Two new validated concepts in two weeks