Notes from Clarity Conf 2018

Posted January 27, 2019 in Design, Inspiration


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

  1. 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?
  2. 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
  3. 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.