Developing a visual language for Manchester City

For years, Manchester City's digital products have been designed and developed by a variety of agencies. With no unified visual language to draw from, City's product suite has become disjointed, providing an inconsistent experience 
for fans.

Drawing from our experiences working on GEL at the BBC, Robin Gibson and I developed City's first experience language through the process outlined below.


At the start of each project, we want to understand the product vision, business requirements and user needs. For bigger projects, we did this in collaboration with other departments through internal workshops, though ad hoc conversations (around a wall with post-its in hand) can be just as enlightening. We also worked a lot with the Research team to gather fan insights and behavioural data.


With a better understanding of the product goals, the focus shifts to idea generation. Typically we started by mapping out end to end journeys to help contextualise a person's experience and identify opportunities for digital touchpoints.

From there, we started to think about the content hierarchy and user interface. This is a useful method of obtaining feedback from stakeholders without obsessing over the particulars of the visual design.


For projects like the new City app, we clarified the design and product principles through a vision piece, which in this case involved an app prototype and presentation deck. This helped to visualise the long term goals of the product, and enabled us to engage with large stakeholder groups and senior members of the business.


Creating prototypes and testing with fans is a large part of what we have done this past year. Once or twice a month, we invited fans in – with the help of the Research team – and tested new concepts and live products. Though we were light on design resource and didn't have testing facilities, we managed, largely thanks to Robin, to set up a makeshift testing lab using two meeting rooms, a basic web cam, mic and streaming tools.

We used Invision and for our prototypes. While intended for testing with fans, they're obviously a valuable asset when engaging with stakeholders and gathering internal feeback.


After two days of testing – usually with six to eight participants – we came together as a team and collated our observations. Then we documented the insights in a brief research report, which we shared with the wider team and other relevant departments.


With the developers based just about everywhere but Manchester – London, Poland, Portugal and Ukraine – we introducted Zeplin to document our designs and have single source of truth everyone – designer, developer, tester, product manager – could access. This also enabled us to share maintain all our projects in one place.

And that's pretty much it! Thanks for reading.


Check out Victoria Black's medium post on how we changed the homepage