United Airlines (2018-present)
I joined United’s employee experience team when it was a very small group of hard-working designers and researchers, scrambling to react to requests from across the business for new apps, redesigns etc. We did have a simple (PDF) styleguide and did what we could to be consistent in our approach, but didn’t have much else to guide us and became somewhat siloed. On top of that, external agencies that we engaged to help had their own ideas of what United products should look and act like, which added to the lack of overall direction.
After a year or so, as our workload and team size started increasing dramatically, it became clear that we needed more than just the PDF to guide the team and achieve consistency and efficiency in our work. Having experienced the benefits of creating and utilising design systems in my previous roles, I ended up pitching and, ultimately, managing United’s internal design system (ORION), including both an internal team and external agency. Responsibilities included: identifying and prioritising the backlog; planning and reviewing the design; collaborating with development; evangelising ORION to the rest of the organisation. Effectively, operating as the product owner.
Uptake (2015-17)
Uptake started as a predictive analytics platform, had ambitions to become a more diverse SaaS provider. Seeing a need to ensure product consistency through this transition, I and a visual design peer researched, pitched and Led the interaction design on the design system for Uptake’s diverse range of SaaS products. This also involved collaborating with Uptake’s Agile development teams to ensure their design direction was in line with the design system approach. Worked closely with product management to plan and execute work.
Razorfish/State Farm (2012-13)
This was my first real taste of what would become known as a design system. Razorfish created the system for State Farm’s impressively responsive digital properties. Beyond designing the elements themselves, part of my role was to create and maintain documentation for reusable elements, enabling other project teams to incorporate them into their projects consistently. I also rewrote historical documentation when underlying technology changes necessitated adjustments to functionality and design.
OK, so what is a Design System?
First up… the name is a bit of a problem. “Design” evokes certain things to most people; generally-speaking, the visuals. And as such, it implies that a “design system” is for the people who do the visuals. If your design system only caters to that, it’s really more of a styleguide.
A better name to describe these things might be along the lines of “product system” or even “product development system”. But this humble paragraph is unlikely to change the industry terminology overnight, so for now, let’s stick with what everyone else is calling them.
Alrighty, let’s start with what, to me, is the most important thing to clarify…
A design system is not:
- A rigid set of rules for designers to follow.
- A replacement for a design team.
-
That thing we finished last August and celebrated because we were done.
OK, so what is it then?
- A language that enables design and development teams to communicate and build more efficiently.
- A foundation that allows designers and developers to focus their time and energy on actually solving problems, rather than recreating the wheel every time they start a new project.
- A product. And just like any other product, it needs to be kept alive and allowed to evolve and grow. Like a Tamagotchi. Or an avocado plant.
Who exactly is it for?
- Everyone who has any interest in the development of your products: developers, designers, product owners, all other stakeholders.
- The benefits should be felt by all the above, plus one more group: your users/customers.