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"