The Ultimate Design Library

I’ve personally built or assisted in building several design libraries for use in large-scale, multi-platform, long term digital application projects and I’d like to share some of my perspectives on these specialized and increasingly critical types of design resources.

First, some background: I was curious about what kind of design library I would build if I knew it had to be current, useful for the widest variety of users and, of course, relatively future proof. I say “relatively” because design tools and project workflows are changing so rapidly that my expectation with design libraries has become “let’s try to get as close as possible at the beginning and adapt as time goes on”. With this in mind, I did some analysis on current trends in what could be considered design resources (let’s call them “libraries” of a sort) and plotted them on the chart below:

I included these types: brand guides, visual design guides, design systems, playbooks, client-facing FAQs, developer documentation, tone and voice guides, curated and automated content storage views, A.I. bookmarking and KPI & data measurement platforms.

Obviously this doesn’t represent every possible resource (for example: component libraries live somewhere in the middle) but it was enough for me to set up two axis — Y: Control (closed or static with centralized control) ⟷ Freedom (open or organic with freedom of control) and X: Design Resource ⟷ Data Resource — and attempt an analysis.

Here’s what I observed:

• Design resources are changing and the trend is towards highly functional, code-based repositories with a focus on data insights, collaborative or automatic creation and decentralized control.
• The “Big What / Small How” paradigm is at least somewhat active in design resources. Another way to say this is: If we accept that some resources are traditionally made first (such as “Identity” deliverables), once those kinds of high-level decisions have been released in some public-facing way, it’s a relative free-for-all with respect to what resources will be needed after that (and who will create them). And that’s a good thing.
• People are working across disciplines, solving for specific, concrete situations and those efforts produce outputs, data, insights and other kinds of knowledge that straddle multiple types of “documentation”.

In general, it’s getting to the point where everyone involved in digital needs to have (and, more often than not, must have) their own kind of design resource.

Based on what I’m observing, I’d like to propose the ultimate design library, or at least the design library I would want to build as part of my next project.

My ideal Design Library would consist of three sections:

1. Resources
2. Knowledge
3. Playbook

Readers: The following schema is an ambitious and malleable goal I’m setting for myself and future design teams. It’s important to note that at the start not all of these sections need to exist. I’m also not 100% sold on the names so there’s still some work to be done and your suggestions are welcomed!

1. Resources: Day-to-day reference

Built for builders: All team members should be able to visit this section and have access to the resources they need for prototyping, building and shipping. Some content will be technically specialized and for this reason certain areas should be safely de-coupled from the rest of the library.

• Onboarding and foundational strategy
• Components and patterns, visual assets and UI elements
• Code, interfaces, content and data integrated as cohesively as possible (based on internal workflows and processes)

2. Knowledge: Source of truth and history

Built for everyone: All team members should be able to visit this section and learn about the user, their motivations, goals, pain points and the problems we’re all supposed to be solving together.

• Insights: What we have learned about our users and how are we solving for their needs
• Measurements and KPIs: The data we have and how we’re using both qualitative and quantitative measurement to arrive at good decisions
• Learning and documenting: Reports, case studies and archive

3. Playbook: Problem solving and continuity

Built for everyone: All team members should be able to visit this section and know how they can learn about, use and apply user-centered design.

• Team design process overview
• FAQ and help topics
• How to start a new project
• Research techniques, strategy, guidelines and best practices

Let’s go deeper and focus more on the specifics of each section…

1. Resources: Day-to-day reference

• Strategy: foundational overview of the project, background and shared team efforts organized for speedy onboarding
• Single page design reference: all the most important stuff organized for immediate application, understanding and socialization
• Detailed pattern and components: detailed states and the “factory” for components
• User roles and personas: introductions, details, motivations, etc. regularly updated with historical archive (note: your user can and will change as you study them and create solutions to address their needs, so it’s super useful if your team can observe that over time)
• User journeys: common pathways and interaction scenarios described visually (again with historical archive so changes can be observed)
• Brand and identity materials
• Controlled Vocabulary: plain language guide (jargon, phrases)
• Communications materials: assets, decks, templates, etc.
• Prototype links
• External file and cloud sharing links

2. Knowledge: Source of truth and history

• Insights: captured, analyzed and centralized actionable insights
• Measurements & KPIs: selected performance indicators and processes explained
• Data and reports: creating and archiving
• Case Studies: what we’ve done in the past
• Project one-pagers: circulating and socializing
• Historical documentation: projects, customers and activities
• Research, collateral, data and other artifacts
• Internal Ideas: an open “suggestion box” for team members to contribute, store and develop ideas

3. Playbook: Problem solving and continuity

• Inspiration page: updates, articles, videos and other resources aggregated or contributed regularly
• Why we do UX: our user-centered design process, the values underlying the process and the benefits received by the client organization
• Starting a project internally: how to get started, what to use, how to scale from “good idea” to “serious effort”
• Research and testing methods: techniques, tactics and tools
• FAQ: get help with common design questions
• Guidelines and best practices
• How to hand-off: meetings, packaging, interactions, animation, documentation, etc.
• Workshop resources: running your own internal and external efforts

I realize that’s asking for a lot from a design resource and maybe “Design Library” is not even the most appropriate name. Whatever you decide to build, starting small and selecting the features you need right away is the best approach to treating your design library like its own product (credit @nathancurtis).

Getting started

1. Definitely decide to build a Design Library: build it early and update it as you go along, using existing frameworks if you don’t have time to start from scratch
2. Focus on the content and information architecture of your design library (you’re free to use mine above and adapt to your own needs)
3. Scope and estimate level of effort so you have the time and resources to do it right (this includes people, production time and the CMS)
4. Design and build your ideal library (starting small and building up)
5. Use your library → Share it → Test internally → Refine → Expand

I’m a User Experience Designer living and working in Singapore.

I write, discuss and photograph as @elbuenob so feel free to follow and reach out to me. I value your thoughts and will do my very best to return your gift of time with a considerable measure of my own. Find me at bschmittling.com and say hello@bschmittling.com.