Building a scalable typography system

OneFootball is one of the most (if not the most) successful football apps available on iOS and Android. It's a football app for the fans that combines the personalized scores and live stats experience with curated and internally written articles about all the different leagues and teams across various languages.

The state of typography on our various platforms was fragmented, poorly named, hardcoded Why? inconsistent, undocumented and didn't look that great! We the designers were just defining them as we go which got worse as soon as the team got bigger. The only thing we had close to a typography guide was this table that had some names and values but it never sat right with me and the team. It wasn't built to scale and there were no rules to control them.

So when we took a step back before designing the reading experience v1.2 and took it as a chance to set some groundwork for a Design System. For starters, we defined a set of guiding principles for what will come - shown below. We wanted to build something scalable and reusable to enable us to redesign some parts of the app with each new iteration or feature. Also to sell the benefits of a design system as a strategic move for management and how it can optimize our work and bring up our quality as a product.

Skipping ahead to where we made it to typography, we collected information about what we currently have in typography whether it's documented or not and collected around 45 unique styles per platform. It looked similar to this after clustering them into symbols in Sketch…

Typography is simply defined by a set of attributes. If they are controlled, they can scale up and fit in different cases without breaking the system as a whole. The obvious first step to the solution was to replace the broken naming convention with something that can scale and be self-explanatory. With Involving platform engineers and the product team in the process, they gave us their feedback and lucky for us the engineers to be specifically shared some of our concerns and were happy with the initiative because it would simplify their code. All they asked for was a clear way to document and hand over which makes total sense as we iterate and evolve the system.

After doing some research and looking at how other systems define their typography. I guess Google's material design is really comprehensive and yet very simple. We can easily see that it's just a set of well-defined controlled attributes.

I think that's exactly what we are after, so after extensive exploration on various different styles and how we can fit strong typography in for a modern content first app we decided to define lock away some attributes within the system and never change them. By locking everything except for alignment and colour we can easily see that it's already a scalable system and what was left is defining those attributes with meaningful names, so we opted-in for something similar to the semantic web and close to what Google did with Material design. Mainly three main classes: Display: for Section titles, article titles, and quotes. Heading: for subheads, card titles, and labels. Body: for content and paragraphs.

The result was 13 new styles shown in the figure below that covers all of our needs…

Moving forward we had two missing parts documentation and handover.

Abstract was the obvious answer here because it plays well with Sketch and Sketch libraries but there was a bit of a learning curve for non-technical designers to how Abstract works with branching and versioning. It helped a lot though to have a consistent way of committing as much as possible and a standard way across designers to open branches which were giving a relevant name for the branch alongside the ticket attached to it

One of the super advantages of Abstract is making the design process transparent. Getting immediate feedback or sharing your progress with a link to anyone on the team was amazing and anyone throughout the process can just follow along with each new commit.

The tool we used to spread the design system around was zeroheight.com it was pretty cool because we can just upload Sketch symbols and it sorts everything out by reading the attributes of that symbol and here's an example from the Typography section…

With all needs covered across teams we were set and ready to move forward in making this design system even better and to implement it with every new feature or redesign one. You can read more about what came after in this piece designing the reading experience v1.2

Opening up the design process and bringing design much closer to product and engineering to have a sense of contribution has remarkable results and I believe it's one of the key values to spread design as a culture across companies and build healthy design systems. It makes team collaboration more comfortable in what they do and what they expect.