Categories
Design Inspiration

Notes from Clarity Conf 2018

Clarity Conference was back at the beginning of December last year, but better late than never, right? I took handwritten notes on my iPad and have (finally) transcribed them for your scanning pleasure.

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.