Clarity Conference was back at the beginning of December last year, but better late than never, right? I took handwritten notes on my iPad using Notability, and have transcribed them for your scanning pleasure:
Workshop: Scaleable Design Systems with Nathan Curtis
I am so glad I was able to attend this workshop – it really solidified my understanding of design systems and prepared me for taking in all of the information to come at the conference. I wasn’t in note-taking mode during the workshop, but here are two major takeaways:
- Successful design systems have dedicated, in-house teams
- The foundation of a DS are colors, typography, sizing and icons
- Standardized values for the above are called design tokens
- A button is the perfect first component because it touches so many of these items
Creating Cultures of Empathy, Sharon Steed
- Culture = shared attitudes, values, and beliefs
- This is the experience someone has when interacting with a company, or you
- Community values = culture; culture cannot exist with a community
- Choosing empathy means choosing the little things
- Patience: Pause, remember why you are having the conversation
- Perspective: Rephrase in order to understand – we don’t always hear what the other person said, we hear our opinion of what they said
- Connection: Speak with intention and be proactive with measured responses.
- Empathy is a verb; empathy fosters collaborative environments
- Culture is the result of community
- Increasing empathy between designers and developers:
- Instead of assuming you know, step back and assume you don’t know
- Start the conversation, take the steps ahead of time and prepare for good communication
- Working remotely, build relationships whenever you can via calls and meetups
- How to build culture from the bottom up?
- Culture comes from everywhere
- (Design) Critiques can be part of culture if you pursue them
Start With Your Brand Purpose, Kim Williams
- Start with your brand purpose
- Why everyone should <3 you
- Design transformation starts with love, and love starts internally
- Design engineering = owning the fit and finish
- Design operations = the infrastructure and logistics for getting design to happen
- IKIGAI – Japanese philosophy
- Juno – Indeed’s initial design system
- Card system
- Visual refresh
- Foundation for building change and developing coherence and velocity
- Aurora – brand system
- Building trust
- Distinctiveness
- Design systems are the long game
- Must have a growth mindset => innovative and integrated
- Labor of love
- Regarding bias – assume you are bias and the bias is wrong
- We are all navigating design transformation at our companies – no one is alone
- Support through change
- Embrace the new analytical – the quantitative side is critical, but it tells you what not why.
- Qualitative research tells you why
Scenario-Driven Design Systems, Yesenia Perez-Cruz
- A system is:
- Elements
- Interconnectedness
- Purpose
- How do the elements work together? They should connect in a way that achieves something
- Start with user scenarios
- Identify key moments for brand expression
- Do not start with individual components
- Be more specific
- Visual inventory and purpose inventory
- What elements are presentationally similar, and which are semantically similar?
- Only add layout when the content requires it
- Base everything on the content’s needs
- On component variations:
- Good: Solves a specific problem, user need
- Bad: Visual variation that serves the same functionality
- Unify components that have the same goal
- Partnered with brand designers and editorial – embedded engineers
- Create a scaffold for problem solving
- Editorial:
- Express what they need to do
- Support their storytelling
- They should focus on what they do best, and the system should allow them to do it without engineering
- Be specific, but keep patterns general and push back on visual variations
- Visual variations are okay if they are critical to the brand
- What is the editing workflow?
Composable Animation, Sarah Drasner
- The core tenets of design are color, typography, and motion
- Animation in CSS affords two easing points, JS allows for more
- Accents in eases
- Including similar eases, then have one a bit different for expression
- Understand the animation before it goes into the system
- Have an opinion on animation
- Study reality – don’t just copy others!
- Define an audience for your documentation early
- BDFL – Benevolent Dictator For Life – the person who cares and supports the system
- Compose with meaningful defaults
- .entrance
- .t-x = timing 1x, 2x, 3x, etc.
- Only include what you need
- Defaults expressed as props
- Consider touch, hover, and click
- Consider responsive timing – shorter timing on smaller screens
- Consider touch targets
- Page transitions
- Transition out before transitioning in
- Use persistent items to indicate the transition
- Page-transition.com
- Rachel Nabors – easy to useful graph
- Start with a business goal for determining what to build out
- Identity and motion
- Use research to determine how people respond to different types of animation e.g. the speed of a fire crackling
- A choice for motion is also a choice for the brand
The Three P’s of a Design System, Adakunle Odouye
- 1. People
- Producers and consumers of a design system
- Design for the primary
- Support the secondary
- Accommodate everyone
- Prioritize the developer experience – design systems are for developers, at the end of the day
- Design plans the experience, developers execute – doesn’t exist until it’s in code
- Quantitative research – what are people doing
- Qualitative research – what are their needs
- You might not always have a designer for the UI, the system should enable developers to design where needed
- Ask: How can a design system make your life easier?
- Ask: What are the future goals of the system?
- Do/have these things:
- Clear component docs
- Seamless integration with pattern library and production codebase
- Communicate the updates consistently
- New components
- Have a Slack bot
- Email newsletter
- Test and validate before release
- A DS is everyone’s responsibility
- Have as little friction as possible for using CSS
- 2. Process
- Predictable
- Flexible
- Frictionless
- Do a component audit
- Create a project roadmap
- Don’t be building random components – strategize
- Have guidelines
- Commit message guides – [badge] Add spacing
- Same format for issues
- Start in small steps
- Lerna for versioning components
- Component structure, combining classes to build up to variance
- Article – functional CSS in React
- Compound component – Multiple React components that share state
- Make sure engineers have input and feel heard
- 3. Product
- Building components in the workshop/ display them in the storefront
- Docz for React documentation – .mdx and propsTable
- Front-end prototyping
- Use real content and real data
- Get away from pixel perfection
- Understand the goals and problems of the people
- Create a process that empowers people
- Create a product that brings value, and stop doing the same things over and over
- Have a process / framework for documentation
- Consider coding and work tracking conventions
- The system is a framework for anything
- The more people are exposed to it, the easier it gets
- A DS is never done – keep working on it, and focus on the things that matter
Your Face Here (about Illustration), Jennifer Hom
- Reference images of real people for illustrations
- All sizes of an image should be treated differently – can’t just resize it, needs to be redrawn and details updated according to what is necessary
- Try things you know won’t work
- A lot can be learned from a horrible drawing or design
- Never use the same reference twice
- Illustrations requested through a form with an illustration brief
Preserving Legacy Design Systems, Jesse Reed and Hamish Smyth
- Emphasize flexibility in the system – yes, you can change the button color
- Preserve and build upon the legacy system
- standardsmanual.com
- Change for the sake of change is not good
- Master crafts people (?)
Language of Design, Dr. Amélie Lamont
- Language is experience, not labels
- Discrepency in understanding of “design” from practitioners vs. the consumers (Regular Schmegulars)
- Specialized understanding = gatekeeping
- Systems
- Work smarter, not harder
- Systems are invisible
- Functionalism: design for function and it will be beautiful
- Kigali chair project
- Designed objects are the fruit of invisible systems
- Most people do not know what Design is
- This is the problem with “Design System”
- Make sure to think it through and talk it through
- Change the language so people don’t feel threatened
- If you can’t sell a design system, that’s a communication problem
- Virtues of a perfect system
- Flexible enough and easy to use
- Don’t need to know the inner workings
Putting the Design in Design Systems, Dan Mall
- Designer’s ultimate fear: what if the design system is so good they don’t need us anymore?
- Let’s make a design system for…
- Full Stack Design System (?)
- Principles
- Allow you to determine what to focus on and what to ignore
- Ask: What are you optimizing for in a design system?
- Marketing, learning, etc.
- Pilot projects
- What do we want to make with our DS? What will use it?
- Determine primary audience
- Pilots and scorecards article: http://danmall.me/articles/design-systems-pilots-scorecards/
- With a pilot, don’t make components, make the product then ask:
- What can we extract from this product?
- Learn from working with real products and real requirements
- 80:20
- 80% of a design can be done with the design system
- A DS is all the boring stuff – you don’t need to keep remaking these things anymore
- The last 20% is the real design
- Real value of a DS is so the designers can actually design and innovate and stop making the same things over and over
- A DS takes away the grunt work and designers can focus on real problems
Q & A
- Few comparability guidelines in component/design system audit (?)
- What interesting things come from not dictating what things go to gather?
- Pilots that go the wrong direction
- Consensus from everyone on what is right/wrong
- Can make those decision together
- Design system coverage
- How many of the mundane components are you covering?
- Contributors – it’s good if everyone does a good Jon
- The more siloed we are the worse our products are
- Tokens are the gateway drug for contributing code to a DS
- Humility is an important ingredient – worry about how other are doing
Note: At this point I am transcribing my notes almost 2 months after I took them and I no longer can decipher all of my handwriting, so these might be a bit sparser.
Material Theming: Building an Expressive Design System, Michelle Alvarez & Yasmine Evjen
- Theming taxonomy
- Category, set defaults and cascade the defaults to everything else
- Attributes
- Values
- Material theme editor
- Categories for variations
- Shape: Size (Small, Medium, Large), Shape Family
- Color: Container, content, color tool
- glitch.com/@material
Driving Adoption, Julie Horvath
- Define the Why
- Common problems
- Business value propositions, solving problems of inconsistency, redundancy, etc.
- Evidence
- How much time have we spend building the same component over and over?
- Polish tickets = redoing things that are “done”
- Two UIs that share the same thing
- Will working cross functionally help with goals?
- Common problems
- Build partnerships
- We are a team; the web team
- Not creating value until something is in production
- Forging a partnership; a design system is a deliverable of a relationship
- Include the system in decision making
- Accept constraints
- Get creative with the roadmap
- Make it a requirement for a high value project
- Start small and ship small
- Treat delivery like a feature
- Systems have consumers vs. producers – not the same people
Inclusive Design, John Maeda
- Red Burns from ITP
- Mentors all die
- “Someday the world will find me”…false!
- If you don’t have a trust fund, you need to collaborate
- Dezzie Garcia
- “A team of geniuses can lose”
- Octopus tentacles are smart
- Talkers vs. Makers
- Leading and organizing; the maker muscle can’t lead
- The maker-talker is doomed
- Makers tend not to lead because they are busy making
- Design Operations
- Set the stage for the next, the near, and the future
- Deep process and standards
- If you don’t have standards and things work, then its luck
- Standards and process get people to communicate
- Every design system is different because every organization is different
- How can you produce information to be shared?
- In order to get value, you have to have information
- How much knowledge is being produced outside of research?
- Learn about the process of people you admire
- Find people at your organization to collaborate with
- Hire people you think can do your job
- Remember the world
- Spend time with people who think differently and get outside of your community
- Expose yourself to different experiences and different sets of assumptions
- Question: How do you find mentors? How to figure out who your mentors are?
- Skill and curiousity; find someone with a strong thing / “radical” idea
- Look to the world, look for new models – not people in your institution
- Find people from multiple areas and stitch them together
- Maker-talker / hyper-connectedness
- Follow the ball that connects
- If you are unhappy, how can you re-word it?
That’s all I’ve got!
Hopefully those were at least useful for scanning and getting an idea of general themes and concepts – that’s usually what I look for in a “conference notes” style blog post.
Once again though, Clarity just hit the nail on the head for me. It was so awesome and really kick-started my (and thus PMC’s) design system journey. If you are new to design systems or looking for the perfect avenue for an HTML/CSS oriented skill-set, Clarity Conference and the design systems community are where it’s at.