Jack Tarantino

Clarity Conf Day 1 Notes

Here are my notes from day 1 of Clarity Conf. Apologies in advance to the speakers whom I am certain I misquoted and misrepresented. Also if I missed things. Also for having some personal stuff just in the middle of there. Also because there's probably like 90 typos. I may or may not fix those later. Apologies to readers because this is seriously all I could jot down while trying to pay attention.

Jina Anne (host)

Code of Conduct

  • it's solid

Chris Coyier

  • pattern libraries, design systems, style guides
  • clarity - it's a way to see and understand things better
  • style guides aren't new, style guides for the web and at the scale that we're engaging them are new.
  • why do we need a design system? not having one is kindof like death by a thousand cuts. or like 500 cuts and then life with 500 band aids.
  • brad frost
    • he really likes style guides, resources, styleguides.io

Brad Frost

  • vaughn vaper the fake CEO says we're gonna redesign the homepage
  • team is super excited about "doing it right" this time with modern tools and all that.
  • getty images basically has no consistency
  • canon has 500 different location based experiences
  • browsing through the ebay site, we can see our journey back in time
  • united airlines has 13 different button styles just on the homepage
  • users see a signle brand and expect a cohesive experience
  • what is a style guide? brand identity, design language, voice and tone, writing, pattern libraries, code.
  • google's material design
  • mailchimp's voice and tone
  • the economist styleguide
  • SMACSS
  • github styleguide
  • it's in nobody's best interest to think of the internet as pages
  • it's not fun to design 3 separate versions of each page
  • frameworks are great but they all start to look the same
    • how is your site compatible with existing sites and patterns
  • dave rupert - responsive deliverables should look like a filly functioning bootstrap customized for each client
  • walmart's stylgeuide
  • how do we make these things happen?
    • we have to sell it - more cohesive experience = more conversions and moneyyyyy
    • faster production = roll out more features faster
    • shared vocabulary = more times collaborating and less time in meetings
    • easier to test = more responsiv, performant and hub for best practices
    • useful reference
    • future-friendly foundation = modify, extend and improve over time
  • how to sell?
    • show them, don't tell
    • show what sucks about the current interface and how inconsistent it is
    • categorize every element in the UI
    • if you ever want to make your CEO cry just show them how inconsistent the current site is.
  • establishing how inconsistent the current site is provides a scope of work for what needs to be fixed
  • "if the boss still says no, do it anyways"
  • "in order to make the whole, you need to make the parts"
  • "atoic design has everything to do with considering the whole and the parts at the same time. it's not about just making buttons in isolation."
  • >> atomic design theory
  • atoms molecules organisms templates pages
  • creators > build > clients
  • t-shaped people - breadth vs depth
  • "the letter t doesn't really stand up on it's own. we need to build table-shaped teams. groups of t's all hooked together that can stand on their own"
  • "front end designers bridge the gap between design and development"
  • kill the waterfall process
  • samantha warren's style tiles
  • dan mall - ui element collages
  • working as a front end developer is kindof like working as a prep chef. you cop all the carrots so the next day the real chefs can focus on their work.
  • when you use atomic design, the higher up the templates you go the more you see just lists of partial incldes
  • "no matter what you're doing, use photos of beyoncĂ© for your fill images"
  • beyoncĂ© lorempixel?
  • if you wind up at a point where you've finished one organism but not others, and the rest of them look like shit, that's okay as long as you communicate and are clear about expectations.
  • "oh great, here's this nice design system! TRASH CAN."
  • we need to maintain the pattern library as central architecture. a living part of the process.
  • nathan curtis - a style guide is an artifact of the design process. a design system is a living funded part of the development process
  • a great-looking style guide reflects an organization's comitment to a thoughtful design system.
  • coyier - my worry is that orgs will say "oh we don't have time for that."
  • make something > show that it's useful > invest in it.
  • the holy grail is a real living stlyleguide.
  • a pattern library should serve as a watering hole and encourage people to participate in it.
  • USDS design system
  • nathan curtis - when you put a styleguide behind a wall it takes an outrageously long time to get access or they never get access at all.
  • "make it agnostic" "patterns should be versatile" - list group and feature block
  • "make it contextual"
  • mariott digital standards
    • announcechanges
  • a design system should be like a fine wine. it should provide increasing value over time.
  • franklin "when you're finished changing, you're finished."

Conversation after

  • cooking metaphors are awesome
    • mise-en-place
  • for all the guides and stuff we use, should we define one of these or use one consistently?
  • atoms molecules and organisms implies a sense of hierarchy
    • you can call it whatever you want so long as it's consistent and you agree on it.
  • that consistency should exist across devices and properties
  • the magic elevator of knowledge
  • getting people excited about investing is the key
  • nathan might have better notes on that
  • creating atoms isn't about creating them in isolation

Isaak Hayes and Donna Chan

  • building empowering style guides with practical research
  • usable and impactful
  • version 1 of style guide was just in psds and in design team only
  • many companies start out with style guides silo'd to one team
  • lack of communication makes the guide unusable by designers, developers or across teams.
  • "style guide reserach process"
    • who do you need to talk to?
    • what should you be researching?
    • interview - understand - define
  • who are the users of a guide? designesrs, sales, marketing, PMs...
  • who are the builders? designers, engineers, writers...
  • who are stakeholders? ceo, managers, project leads...
  • the style guide should account for future projects as well as current ones
  • app direct lets users theme websites
    • theme-able components are essential to their business
  • "what problems are we trying to solve with a styleguide?"
  • what are your biggest pain points?
  • what would a style guide allow you to achieve?
  • what information would you need from a style guide?
  • builders will also be users!
  • what constraints surround the creation of a style guide?
  • face to face interviews > pull out nuggets > sticky note the ideas > always communicate out your findings
  • designers and developers both hate red-lining stuff > employees are wasting time on repetitive tasks.
  • "i don't konw what other people are doing" > information is not being readily distributed
  • "engineers are not recycling old code!' > unweildly code base
  • principles > user stories > metrics
  • fixed problems: efficiency > communication > simplicity
  • user stories: as a designer i need to quickly communicate. as an engineer, i need to get clear instructions.
  • if you're having trouble pinpointing measurable things in your company, try using surveys. some data is better than no data.
  • "this is a process!" it's continuous and needs to change and scale with the team.

Conversation after

  • don't just talk over the fence, kick it down
  • it's hard to implement style guides because people have abandoned them before and they're bitter about it
  • "i always just start making a style guide and talk to the engineer who's passionate about it."
  • "styleguides are like unit tests for design"

Nathan Curtis

  • "beyond the system"
  • google's material design is ahome run.
  • i can't get a client to make their top nagication consistent across applications.
  • how many times have i asked "do we need a variable for border radius?" - YEAH WE DO.
  • it's not reds 1 through 8 because when you need red 7.5 you're kinda screwed.
  • it's not just about creating a photo card. it's about establishing a design system. it's about solving a problem once.
  • print out all the pages, cut up ui components, group, label, prioritize...
  • a design system is a lot of work. and it's fun work!
  • dot voting to prioritize
  • one company doesn't use a tracker because they paste everything on the wall in the office.
  • the mission is efficient, collaborative, scalable, cohesive and high-quality.
    • tooling, connections, shipping, experiences
  • foundation is created by people who created system for people who create systems for people who create products
  • choose flagship projects that'll commit to you too
  • use their launch dates or make your own
  • in a portfolio of "web products", things that don't have a dedicated team, usually have a stakeholder or product owner.
  • what's your get?
  • avoid distractions
  • "the homepage is a frickin distractions!"
    • massive numbers of stakeholders who all have opinions and you're constantly changing stuff
  • be careful not to make the style guide the arbiter of what makes it to prod.
  • make one-offs if you need to!
  • there's a strong relationship between metrics and all your different components
  • @livlab - the demo convinced anyone in 1 minute which left me 59 minutes to talk about heftier topics
  • sun microsystems style guide
  • "overlords don't scale"
    • a single engineer making a style guide can't work.
    • iit's only built for one person's needs, not everyone's.
  • a centralized design team doesn't scale either. they're too disconnected from other teams.
  • a distributed "federated" team works better because you're getting more of the team involved. salesforce uses a "cyclical" design system team.
  • sometimes you play the role of "connector" instead of building or deciding you just help.
  • @cap's sliding scale of giving a fuck
  • designate "go-tos", not deciders.
  • civx > content, interaction, visual, uesr experience
  • "mix doers with delegators"
  • retro survey employees: what was particularly satisfying or dissastisfying about working on this project?
  • embrace new responsibilities! PM, seller, evangelist, connector, aligner
  • "get endorsed" > the way to get a design sytem that works and matters is to get support from "the top"
  • @jonwiley - first thing's forst: you must have total support from the top.
    • a google-wide diesng initialitive required the vision of a CEO who can make that happen.
  • a style guide is an artificat of design process
  • a design system is a living funded project
  • we all use blue because links were blue in 1996

Conversation after

  • do you find there's success in using manual tools?
    • it creates an atmosphere around which people are engaged physically and engaged together.
    • physical stuff disarms people from feeling like things should be perfect.
  • maybe being the style guide lone rogue isn't the best idea if you8 can't get buy-in
  • any decider who only works on a single product is a bottleneck to the other teams
  • snarky websites that make fun of how every website looks the same..
    • there's a system and then there's the expression that the systsem evokes
  • tiny bootstrap is a great reference
  • bootstrap is a tool and not a style guide
  • allow autonomy despite having a set of rules that we should all adhere to.
  • the ability to cede authority oveer a decision makes me a better systems designer
    • i don't care where the icons go or what they look like as long as we make the decision together.

Miriam Suzanne

  • natalie downe - barcamp 2015
  • we need frameworks for building those into every site as quickly as possible
  • our team's product is the architecture. the architecture is what we're selling them.
  • quality architecture is just patterns
  • patterns are also integration tests. they are made up of may disparate patterns working together.
  • patterns are a combination of languages
  • maintenance of a style guide should be integrated
  • make sure that a style guide is easy to get to
  • ITCSS?
  • separation of concerns
    • data logic structure presentation
  • specificity is your guide
  • css was designed for patterns
    • what did you think 'classes' are for?
  • don't repeat yourself but don't stretch for patterns
    • "these elements share a purpose" - that purpose is represented by a border style
  • natalie of sass - extends work well when used semantically to represent "is-a" relationships
  • i don't use grids anymore. i don't think you need them
    • why? - don't use crazy grid systems. only use basic ones if you need to restrict design. otherwise just use good design + flexbox.
  • naming conventions must be consustent across the whole team.
  • layour region > component > element > state > js-hook
  • adding js- to a class name makes it obvious that it's for javascript
  • "there's no right answer but if you have no answer that's totally wrong."
  • maps are more semantically valuable than plain namespaced varialbes but they still have problems.
    • use helper methods to make these more useful and readable.
  • "make documentation the lazy option"
  • SASSDOC!!!!!!!!!!
      • Herman(beta) ?
  • toolkits are a byproduct of pattern design
  • tools should fit you
    • "sorry, this hammer only builds patio chairs"
  • SASS TRUE
    • @include test('merges 2 maps')...
  • add sass-lint to ui component generator
  • "template logic is great"
  • code patterns are central to a pattern library

Conversation after

  • sometimes overtooling happens and you need to pull back
  • "the way i was taught, the html comes first"
  • i like to build abstractions so the developers i hand this code to don't even know what's in the classes i write, let alone need to look at them. they can just call this "icon()" function and it ouputs all the mess
  • claudina trained her to use this "documentation first" approach.
  • IF YOU DON'T DOCUMENT IT, IT DOESN'T EXIST.

Stephanie Rewis

  • css written by people who want to write java
  • how to make specificity wars work?
  • "how do i make my app look like salesforce?"
  • turned standardized properties and patterns into "tokens"
  • using variables for all the styles also allows external developers to override our internal styles.
  • take current patterns and break them down to their smallest parts
    • this is how we identify atoms while keeping scop in mind.
  • enterprise applications have some unique traits
    • set all headings to the same size and then change design with accessory classes
  • bem + xml = broken xml because dashdash
  • accessibility is a mandate at salesforce
    • semantics
    • aria
    • REM sizing - people with bad vision just change their base font size, they don't zoom!

Brandon Ferrua

  • "if you build it, they will come." lot of confidence there...
  • HOW DO WE LOWER THE BAR FOR ADOPTION?
  • how do we keep our design system agnostic?
  • minimize dependencies
  • you don't know what you don't know!
  • what makes up your ecosystem?
  • who are your customers?
  • minimum deps: tokens icons html css guidelines
    • no javascript?
    • js isn't easy to understand for all users
    • rely on IA and documentation
  • don't document javascript behaviors with readmes. document it with demonstrations of what happens. document the user experience, not the code.
  • avoiding potholes:
  • we have to be forward thinking but backward compatible.
  • 3 releases per year. need to support the last 3 releases.
  • does this make deployment/attaching a particular feature to a particular release any easier? cherry picking only different versions?
  • deprecation becomes your new best friend?
  • as a developer or a consumer, how do i know what is deprecated?
  • what can we do with the tools at our disposal?
  • sass deprecate?
    • sass mixin to compile or not compile a block of code based on a named variable that represents a semver.

Conversation after

  • Theo is a pretty good tool to abstract away from a particular stack.
  • is it a problem when there's 50 classes on div?
  • is it any better to use a single long fuck classname?
  • when you deprecate is there a danger of losing trust?
  • how do you handle making one-offs and tracking them?
  • What's it like to work on a small team in a huge changing org like that?

Anna Pickard

  • I like 'hello'. Hello is one of the bets pieces of copy. It means I'm here and you're here and we're about to have a conversation. It's very nice.
  • how do you scale a feeling of humanity in a product?
  • styleguide is split into 2 section. the first is the rules: grammar, oxford commas and all that. the second is voice and tone.
  • it's all about being human. (there's a tiger on the screen...)
  • "we do not sound like corporate drones"
  • saying "it's not these things. i'll know it when i see it" is like saying "i've hidden a diamond the size of your fist somewhere in the world. it's not in your laundry room and not in bhutan."
  • slack is confident, witty, concise, helpful, human, empathetic, courteous.
  • **who am i talking to?
  • what emotional state are they in?
  • what is the context? frequency? placement?
  • what do i want them to take away from this?**
  • courtesy is about getting out of people's way.
  • what can i do to simplify this message?
  • am i helping the user?
  • working with transparency, giving up your ego
  • we are inclusive. puns are fun but they're not inclusive and that's why we don't make them.
  • playfulness: being in the spirit of the game. wanting to improve..
  • be nice just because you can. just because it's human.
  • being truthful, open, authentic and fair.
  • how human does it sound if i read it out loud?
  • emojis: not, hat, shooting star, rabbit. "it's not magic"

Conversation after

  • Dev relations is allowed to use puns sometimes but only because we can't stop them :P.
  • "you can't sound like this all the time. when a bank says 'you look nice today' you're like 'really???'"
  • we don't say things like chat, collaborative, rockstars, ninjas, ...
  • we say "we" because we're a team.
  • "because i'm human and especially because i'm british i can nice anyone into apologizing"