Laying the foundations for system design
Great digital products are built upon solid foundations
Building on-brand, quality and consistent digital products at scale is hard. It’s even harder when your designers and engineers span different product teams, departments and locations. Success requires more than an assortment of PSDs, Sketch files, styleguides, a print brand book, pattern libraries, InVision, and whatever else your team claim to be working from. You need a source of truth. You need to lay strong foundations — then use them to sustainably build (or repair existing) products and design systems.
A building built on sand will only stand for so long without strong foundations.
At WeWork, over the past year I’ve lead what I call a ‘Foundations Initiative’ focussing on establishing our digital brand guidelines, design systems, best practices and documentation for our digital products. This article covers what that means, the value of establishing ‘Digital Foundations’, what they include, and the design systems they’ve helped us build.
P.S. While I’m referencing a real, working example for this article — the principles here could similarly be applied to any brand/company/product(s).
What are foundations?
I use the term ‘foundations’ as part of a hierarchy for design systems and thinking. Think of the foundations as digital brand guidelines. They inspire and dovetail into our design systems, guiding all our digital products.
- At a brand level they cover things like values, identity, tone of voice, photography, illustration, colours and typography.
- At a digital level they cover things like formatting, localization, calls to action, responsive design and accessibility.
- And in design systems they are the basis of, and cover the application of, things like text styles, form inputs, buttons and responsive grids.
Why are foundations important?
Startups build products fast. The perceived visual quality can be good, and the UX good enough. But when you make changes and add new features, the product can quickly deteriorate and the code can bloat. These problems become more evident and harder to solve with time.
The seemingly little things like:
- “How do we format time/date/currency?”
- “What colour/typeface/button should I use?”
- “Should this be sentence case or title case?”
…become a bigger problem when there is no clear answer to these questions, and everyone inevitably does their own thing.
Established guidelines, documentation and design systems help designers and engineers spend less time debating, or needlessly creating the same things over-and-over (slightly differently every time), and more time focussing on user experience, problem solving, iteration and building great products!
Documenting the foundations
Brand guidelines existed in the print and physical realms at WeWork (see a sample page spread above), but no design systems or guidelines had been established specifically for our digital products. This was my starting point — to extract from these guidelines anything applicable to digital, then greatly expand upon them to include digital best practices.
✍️ Digital Foundations
The documentation acts as a source of truth — a reference point. If you’re unsure how to approach, do, write, format, or design something — the documentation is where you’ll find the answer! It benefits everyone, from the most junior to most senior members of our teams, and of course is great for onboarding new team members.
To get started, a Google Doc was the perfect medium! It’s simple, fast to set up and write, and free from distraction. It’s easily accessible, and your team can comment inline, which is great for feedback and iteration. The ‘Document Outline’ feature, plus the ability to link/anchor to bookmarks and headings within the document, provides ample navigation. It operates much like a website, though not as engaging or efficient (more on that later).
What do they include?
Below is a high-level summary of what the documentation covers:
Brand mission and values. Guidelines for our logo, a digital brand colour palette, the typefaces we use, use of imagery, etc.
Brand tone of voice and personality. Guidelines for writing copy, titles, form labels and calls to action, including brand terminology, capitalisation (sentence case vs title case), use of ampersands and periods, etc.
Time and date formatting, and things to consider re: localisation. You could even include currency ($ € £ ¥), taxation and legislation under formatting. All very important for an international company!
Calls to action
Best practices and principles for buttons and links. Consistency for actionable and navigational links is important for user experience and conversion.
Best practices for designing responsively. Great for the more junior members of the team.
An introduction to what system design is, and defining the terminology so we’re all speaking the same language. Setting the precedent for why it’s important and encouraging adoption of design system thinking.
The standards we strive to adhere to in our digital products, and guidelines for how to design for accessibility (e.g. colour, form input considerations, etc.)
🚀 From a Google Doc to a website
A Google Doc in our shared Google Drive was a good home for this documentation to begin with. It achieved its primary goal of educating, and acting as a source of truth.
P.S. The documentation for WeWork’s Plasma design system, written in Google Docs, was referenced in a great new book on system design by Alla Kholmatova!
The Google Doc sowed the seeds for establishing our foundations with our designers, engineers and product teams, and gave me (as a design system lead) good reference materials for pitching the value of designing and building design systems.
But a Google Doc can only take you so far. One of the biggest growing pains was the inefficiency of quickly linking to specific content within the document (e.g. from Slack or an email). Searching for content could be easier. And despite my best efforts to format the content ‘nicely’, a Google Doc isn’t the most engaging of content. (P.S. The Google Doc did its job for a year!)
GitBook: ‘Documentation made easy’
One of our lead engineers, Ramin suggested we use GitBook as the platform to take our documentation further. It works with GitHub to allow for version control and easy access by our team to write and contribute to the documentation. You write in markdown, and with a little CSS customisation you can tailor the documentation to your brand! GitBook is not perfect, it’s not responsive, but it does the job 👌.
Foundations applied to a design system
One of the main founding principles of the Digital Foundations was they would be a solid base upon which to build on-brand and consistent products and design systems that embody the brand’s digital guidelines.
Design systems are a visual evolution of the Digital Foundations, built on their founding principles.
Design systems take the Digital Foundations further by reinforcing and establishing their guidelines and principles. They bring order and consistency to products. They help to protect the brand, elevate the user experience, and increase the speed and efficiency of how we design and build products.
There are now two on-brand design systems built upon these foundations: Plasma and Rivendell.
1. Plasma design system
The first design system we created was the Plasma design system, designed for WeWork’s data-heavy internal business products. While Plasma embodies the brand’s digital guidelines, its style is very reserved to suit the products it was designed for (think: data tables, numbers and filters).
For the full story: Read about how we created the Plasma design system ✏️
2. Rivendell design system
Where Plasma was created for data-heavy, employee-facing products, Rivendell is a more visually engaging system created for marketing, public-facing products. Remember: both design systems are built upon the same foundations, only tailored to different product needs and target audiences.
The Rivendell design system evolved in 3 key phases:
Phase 1: Alpha
Not wanting to dive straight into a live product, I started small and offline, designing and building a basic proof of concept website, using the Digital Foundations documentation as example content. An initial concept was designed in Sketch, then iterated upon, designing in the browser.
Phase 2: Beta
Somewhat opportunely, a digital enterprise project came up around the time I was working on the above concept. This was the perfect test to push the young system further, graduating to a ‘real' project, with stakeholders and business requirements. The system evolved quickly, as did a component and pattern library in Sketch that enables a team of designers to quickly and consistently concept new products and features.
With every new project, our Digital Foundations and design systems are further stress-tested and improved upon.
Phase 3: Evolution
The real challenge for the system lies ahead with the websites and products it is being (and could be) applied to. Its success lies in the adoption of it across teams, and building a shared component library so our engineers on different teams can access and contribute to the system. The same can be said of any design system. Design system documentation, paired with our Digital Foundations, goes a long way to helping us succeed.
The foundations we’ve laid help us design and build on-brand, consistent and efficient products and design systems. They are a source of truth, and hold us all to high standards. And the design systems we’re building upon these foundations help us to concept, build and ship new features, iterations and products much faster, and more efficiently. I hope this inspires your team and company to do the same. 🚀
Please share this article if you found it interesting! 💛