A mini-conf bringing together designers, design system lovers and front-end developers.

We begin with Acknowledgement of Country; and a note that all profit from the event will go to IDX.

#CHD18 | codeheartdesign.com

The theme for this event is empathy.

Empathy is the thread that connects us to other humans. – BrenĂ© Brown

Disclaimer & Image Credits

  • These notes were hammered out very quickly and paraphrase what speakers were saying. If you need an exact quote, use a definitive source such as a recording or slide deck.
  • Photo credits as per the social media embeds.

Possibly the only moment all four organisers had time to stand still next to each other all day ;)

Sharon Steed – Creating a culture of empathy

Sharon opens talking about how being a stutterer has been the single most defining thing about her life, despite the many roles she plays. The act of stuttering has brought shame and feelings of not being worthy of people’s time… but it also taught Sharon to be a better, more productive communicator; and to be adaptable to change.

Sharon began to stutter around the age of three. Many kids have some kind of speech impediment and outgrow it as they go through school, but that didn’t happen for Sharon. She developed lots of bad communication habits like using filler words to avoid stuttering. Stuttering has strange effects like making people stutter on their own name, because they can’t switch out to another word – it’s their name!

Sharon started to think about how to reframe stuttering, to change how she approached communication, and who she would choose to speak to. She decided to go big, and pursue public speaking!

She noticed that people would talk about how they liked her message of empathy – which was interesting as she hadn’t used the word at all. She has ultimately become an empathy consultant – she helps people and teams overcome toxic cultures and disengaged teams.

Empathy drives every company’s bottom line. 92% of employees feel that empathy is undervalued in their company; and 90% are more likely to stay with a company that empathises with their needs. 87% of CEOs believe a company’s financial performance is linked to empathy.

Most people think empathy is something you reserve for your life and your family and your friends, but the reality is it’s an existential priority of a business. – Satya Nadella

Let’s go from the foundation: what is empathy?

Textbook definition is the ability to understand and share the feelings of another person. Another common answer is “that thing you have to do to avoid being an arsehole at work…” Neither of these are really wrong, but neither is particularly helpful.

Sharon prefers to think of the ways a word can change as a noun and a verb.

Consider Love. Brand new love is powerful, you think the person is perfect! Then over time it changes, you realise people aren’t perfect they’re just someone you have to work to get along with sometimes. It becomes a choice when things get difficult.

Love as a noun is an idea. Love as a verb is a choice.

Same goes for empathy. It’s an idea, a great idea, it’s productive and collaborative. But as a verb it is a choice, and you have to make that choice – to be empathetic – every day.

The myth of culture…

(Story of a CTO all-hands at a major bank… some brave person asked “without meaning to be disrespectful, but I’d like some clarification… what exactly do you do here?” The CTO stopped and realised they had failed to communicate, so they thanked them for asking and went on to explain. Work life has changed a lot.)

The way we work has become quite fluid. We have a workforce spread across the world and we no longer all work in cubicles next to each other. At the same time, culture has become a hot topic (defined as “the shared values, attitudes, standards and beliefs that characterise members of an organisation and define its nature”).

Culture defines you, although not in the way you think it does. Culture cannot exist without first creating a community, which comes from a feeling of fellowship with others. The big things will define your culture.

Many companies have done this to themselves ... like Uber’s reputation for aggression and discrimination. Those big incidents have defined who Uber is, even if they’ve changed since that’s what people think about them.

Meanwhile some companies like Netflix have gained a reputation for building a great, positive culture. The CEO has no office, and just sets up in the cafeteria. Little things like that add up, they create the environment where positive culture grows.

Choosing the little things creates an empathy mindset. Have patience, have perspective, and connect.

  • Patience: stop (particularly in challenging situations like preparing for an uncomfortable conversation), remember the why (why are you having conversations in the first place)
  • Perspective: rephrase what people said (reflect and check you really heard what they said, that we didn’t just hear our own opinion), focus on understanding (why do they feel this way? take yourself out of the equation for a moment)
  • Connect: speak with intention, this is the beginning

(pyramid: patience is the base for perspective, which is required to connect)

The big ideas to take away:

  • Empathy is an action – a verb and a choice
  • Culture is the result of community – build a great community and culture will follow
  • An empathy mindset fosters a collaborative environment

If at first you don’t success: try, try again. – William Edward Hickson

You only really fail if you stop trying.


Lightning talk – Patrick De Young

10 rules for building a successful product

  1. Shared documents = shared understanding. Share as much as possible. Share everything. Don’t give any context just get to read everything.
  2. Work in secret. Keep everything close.
  3. Avoid conflict. Don’t deal with anything.
  4. Assume what the user wants. They don’t know what they really want. You know best!
  5. Accessibility can wait. You can totally jam the blueberries into the muffin later! Just assume everyone uses a mouse on a high speed internet connection.
  6. Dictate the how. Tell your designers how it should look and tell your devs how it should work.
  7. Late changes build character. When a feature comes to you for UAT, that’s the perfect time to change your mind! Developers love the challenge of sweeping changes right before deadline.
  8. Good design is easy! Don’t let anyone tell you different! Don’t let your designers waste your time engaging with any design process, you already know what to do!
  9. Work in silos! People are experts in their fields, so why would you distract them by asking them to work with other people?
  10. Keep your distance. Your time as a PM is too valuable to listen to people about building the product. You should be out taking credit for the work!

Obviously… do none of these things, do the opposite.

Great design doesn’t Just Happen, it happens when people collaborate. A trio leads the team: product, design and tech. People need to learn about each other, understand their process and don’t be afraid to challenge people.

Ignore those ten rules and you are well on your way to building a great product.


Lightning talk – Isabel Brison

Design systems are so popular they are now probably influencing your work even if you aren’t specifically thinking about it.

Isabel is going to talk about two methodologies you should know about:

  • Atomic design
  • Presentational and Container Components

Atomic design: Atoms -> Moleculres -> Organisms -> Templates/Pages

This system is not perfect and there are many ways to interpret it. Because it looks so linear we think everything should follow that kind of linear path, but it’s not how it really happens. You don’t build all the atoms first, then the molecules… actually you jump all over the place. Curiously this messiness is also how code happens. You start messy, then refactor and clean up as ideas come together.

Presentational and Container Components – popularised in the React ecosystem by Dan Abramov

  • Container components contain business logic
  • Presentational components render the UI

Philosophically React supports this well as you can create components either as classes or functions, but when you really get into it, UI components do have state… because HTML and DOM has state. Basic interactions like opening a dropdown require a reference, which means you need a class component.

Eventually Dan Abramov tweeted that people were taking the split way too seriously. It’s a useful concept but does not need to be literally and directly true in terms of class and function components.

Ultimately the most important thing is to get everyone to use the same names for things, and understand what’s being used. Modularity is great, but don’t let those tools dictate your life – they need to adapt to your working environment.

Ultimately what we all want to do is make things a bit better than we found them.


What JS can learn from CSS – Jed Watson

This talk has a subtopic of 'separation of concerns’ and updating our thoughts on that.

In the early days of the web, everything was HTML; but when JS and CSS were introduced we kept them separate. Separate files, separate concerns. The ability to make systems composable led to specialisation; and it allowed us to scale solutions.

Jed believes there are fundamental principles behind engineering. These principles go from emergent, to consistent, to being taken for granted. Jed wants to challenge how we think about separation of concerns.

Quick detour: imperative – a series of instructions, declarative – state the end point you want.

CSS is declarative, but JS has been mostly imperative. When people wanted to scale up DOM scripting, they turned to CSS for inspiration and we got jQuery.

Language evolution – CSS and JS have both evolved, and our ability to use them got better as well.

By 2006 we had good-ish CSS, but SASS/SCSS came out and added variables, functions and mixins; and introduced compilation to the process. It helped us scale and do more complex things; and helped some really popular tools emerge. CSS has since evolved to use ideas it proved worked.

In 2009 Coffeescript appeared and although it wasn’t massively popular itself, it pushed JS forward by influencing the specification.

Other examples of lessons JS learned after CSS...

  • Mixins – components, in other words; which drive React and are currently being reimagined as hooks
  • React Context – having a single component behave differently depending on its context in the rendered view
  • State Management – JS is really in the middle of its adventure, going from monolithic state managers to the next step in evolution.

We have the wrong separation of concerns. Separating CSS and JS isn’t as useful as separating a component from another component. JS responded with CSS Modules and CSS-in-JS.

So what’s next? Optimisation – CSS already has will-change, and it’s exactly what JS needs and doesn’t have yet.

So let’s look beyond CSS/JS and look at Designer/Developer. These are not separate concerns. We are working on components, products, systems and experiences. These are true separate concerns. Separate the implementation, not the design and learnings.

Other false separations:

  • Server/client – they will be separate at the end but need to be designed together
  • Mobile/desktop – we actually did pretty well with this, with mobile-first design

It’s better when we work together.


Accessibility in Design Systems – Russ Weakley

Five tips for creating more-accessible design systems

  1. A11y should be 'baked in’ at all levels
  2. Accessible components don’t guarantee accessible applications
  3. Components should be built so that they can’t be broken
  4. Purpose of each component should be clearly defined
  5. Accessibility is the responsibility of everyone

Baked in

What does 'baked in’ mean for design systems? They need to be part of the design system principles and practices. They have to be part of the design process, so they’re considered from the start. Include disability in personas, actually do user testing with people who have disabilities. At the code level, components need accessibility baked in when they are first added. Basic things like valid and accessible markup.

Some obvious ways to build a11y into components:

  • Forms: use the label element with for and id attributes (use the attributes even when the label wraps the input)! Sounds simple? Lots of design systems don’t do it.
  • Inline error messages: dynamically-injected error messages need to be programmatically associated with their form input. Many forms place them visually together but do not programmatically associate them. One way to fix this is to wrap the error inside the label; another is to use aria-describedby. Devs should also use aria-invalid (text boolean) and aria-live (makes the screen reader aware that an element may update), to add extra information. Avoid aria-live=“assertive” or role=“alert”, they are too shouty. Stick to aria-live=“polite” in most scenarios.
  • Give radio groups an overall description: wrap them in a fieldset and legend.
  • Segmented controls – they’re just glorified radio groups. Button groups are really just radio buttons (or checkboxes depending on the interaction – additive or exclusive).

Accessible apps

Just because your components are accessible doesn’t mean they have been combined properly, or the rest of the UI is also accessible. You should test at different levels – test your components, test modules, test pages, test the full app.

Unbreakable components

Account for the way people copy and paste code and mess with it.

Example: bootstrap modals have the right role and aria-labelledby to announce what the modal is all about. Which is great, but if devs copy and paste it they can easily break the association.


Common issue in design systems – buttons and links that look like each other. Buttons do something and links send you somewhere. They have a fundamentally different purpose and assistive technology relies on that. If you use a link but make it work like a button, the screen reader has announced “link” but the user isn’t taken anywhere.

So the system needs to clearly define when these things should be used.


There are design tools for checking colour contrast, there are automated tools for testing the accessibility of code. But all the tools in the world are pointless if people don’t have a basic understanding of accessibility, at least within their own discipline.

UX Designers

  • Should have a basic understanding of HTML
  • Form accessibility – why you need labels, how to show required fields, etc
  • Heading hierarchy and usage
  • Focus order – eg. if you are specifying a date picker, how will focus move through it?

UI Designers

  • Everything from the the UX list… plus…
  • Colour contrast
  • Text size and spacing
  • Understand target size

Frontend devs

  • Semantic markup – it’s astounding this is no longer common or assumed
  • Accessible forms and tables
  • Making things keyboard-only accessible – unplug the mouse and see how far you can get through your application
  • Understand that non-native widgets will need extra work to make them accessible (usually ARIA). Define the role, state and relationship with other elements in the page.


It’s not easy, it’s a journey and not a destination.


Component architectures and design systems – Mark Dalgleish

This is really about the future of design.

Design systems rarely start as full living style guides. Seek was no different – it started with a static style guide, moved to a shared Sketch file, went through some InVision tools but kept hitting issues keeping code in sync with design.

This is what led to Seek starting to use CSS Modules; and using tools to sync React and Sketch (reactsketch.app). Crossing the divide between code and design in that way was a key moment for the industry.

But Seek ran into some requirements, reactsketch.app required React, CSS-in-JS and building with cross-platform primitives. Many projects just don’t meet all of the requirements and Seek was one of them. This is where html-sketchapp came in – a less restrictive option which just needs HTML to create Sketch assets. Sketch files are just zip files full of fairly easily-undertood elements.

The system was able to set up…

  • symbols
  • colour sets/palettes
  • text styles
  • breakpoints

...all in Sketch ready to go for the designers, based on config in the code.

However html-sketchapp was just one part of the puzzle:

  • compile html-sketchapp script
  • start static web server
  • open puppeteer
  • inject compiled script
  • capture symbols, resize window, repeat
  • write JSON to disk
  • shut down server and puppeteer

...and handle any errors in all of that. Mark realised this was going to be a problem for everyone, there’s a lot of moving parts.

But Mark just wanted to capture some symbols. So he created html-sketchapp CLI, which does all of that for you.

This does require one thing, an attribute to define and name the symbols:

<button data-sketch-symbol="Button/Primary"></button>

The result is an automated pipeline for Sketch. In addition to direct components, they’re also shipping helpers like a colours component that’s more usable than the built in palette.

This was an important first step. A pragmatic step to get designers and devs collaborating.

There is a problem with the setup, which is it’s still relatively unconstrained:

  • unconstrained layout – you can drag and drop anything anywhere
  • unconstrained responsive design – mobile and desktop can still be radically different
  • unconstrained system deviation – the components can be modified, there’s nothing stopping a deviation coming through in the final mockup. The tools don’t prompt discussion.
  • unconstrained communication – when you create a design in Sketch, even with Symbols, other people still don’t know what everything is. The devs still have to reverse engineer the design from pictures.

So what should we do? We need a new paradigm. We need a new way to think about this problem.

We need to design with actual components, not pictures of components. Not a snapshot, the actual production version.

  • Framer X is one tool getting a fair bit of buzz
  • Haiku is a totally different approach but still interesting
  • UXpin
  • Modulz Studio
  • Interplay – seek is actually using this internally at the moment

...and many more

These tools are truly embracing the design systems era. It’s helping the feedback loop from design to code and back. That loop needs to be quick. It does change the role of developers, to becoming the custodians of design and not just the implementors. Components are the new design API. This means the components have to be up to the task!

How do we train ourselves to work in this way? Seek created a code-oriented design tool, which showed the results of components in multiple screen sizes. Upsides included:

  • designing in the final medium
  • create quick mockups and prototypes in high fidelity
  • evaluate the flexibility of the design system
  • share work by copying the URL (base64 hash in the URL)

It has been shared as “Playroom”.

Generally this aimed to fill out a suite: storybook + styleguidist + playroom. It’s not trying to replace the other tools, it’s trying to fit in.

Is all this too constraining? It’s a common question. Well, that’s exactly the point! The tool is for use when you’re about to build something. You need to know what’s available to use and what’s not. You should be prompting discussions between the designer and developer. If something doesn’t meet the needs of the product, you should fix it.

What does it mean for the future of product design? It’s about bringing design to development; and development to design. They’re just getting started.


Patrick Thompson


Every design process includes some kind of customer contact or validation, so why doesn’t it happen for real?

If a picture is worth a thousand words, then a prototype is worth a thousand meetings. – @ideo

Two big values of prototypes:

  • customer validation
  • internal communication

There are many degrees of fidelity you can protoype in, from paper through to full builds. As the degree of fidelity increases, the time and effort goes up but so does the confidence you can take from them.

With all the innovation going on, we can easily imagine a world where the cost of code-oriented prototypes will become much easier and quicker to do. This will create greater realism, ealier and cheaper in the process.

So what are the common pain points of customer validation with visual prototyping?

  • only testing the happy path
  • customers don’t see real data
  • unsure how repeat usage will impact the experience
  • there are lots of decisions missing in the prototype – devs will have issues implementing it

Other industries have this happening already – game designers and developers work in the same tools (Unity, Maya).

Relevant trends for the web:

  • mass adoption of component based frameworks and design systems
  • lower barrier to create product experiences
  • the emergence of the “devsigner”

Why should you do code-based prototypes?

  • design in the same medium the customer uses the product
  • fully interactive, components manage state (you will never have to do another artboard for hover)
  • no more testing the happy path
  • show real customer data via APIs – make user testing much more realistic
  • add conditional logic and use variables to create live-data experiences
  • ease handoff between design and dev

(iterative.ly demo)

Wrapping it up…

Engineers – help your designers close the gap. Create a comprehensive design system library and stick to it. Make the props understandable for everyone. Document them well.

Designers – broaden your horizons beyond Sketch and InVision, invest in standardisation, make code-based prototyping an integral part of your process, invest in learning your medium (yes, learn to code!).



I didn't have my laptop during the final talk and panel, you'll have to watch the videos for those! (the event was recorded)