Takeaways from Converge 2024

Amy Hupe works on some very serious systems that touch a lot of peoples lives. Gov.uk, NHS, national services. Amy spoke about how the design decisions you make can seriously impact peoples lives and mental health.

In a personal anecdote, she spoke about being in the process of separating from her husband and being faced with endless form fields asking for her marital status (not single, not really married, not divorced) and being unable to select an appropriate option. This feeling of being told your existence is invalid extends into questions on gender, names and more.

My main takeaway from this talk was to consider the impact questions, language and forms have on our users and to provide inclusive UX patterns as part of the design systems we manage.

Amy Hupe talked about inclusivity in systems design. She discussed the importance of thinking beyond design systems. In the case of the relationship question, does it actually need asking in the first place? She argued for the importance of patterns in creating change, rather than being limited by what is already being done. Too often in UX and design systems, we copy the best practices of what is already being done - but is that always the best solution?

Reinventing the wheel is a bad idea unless you designed it badly in the first place.

Patterns have fallen by the wayside in many design systems teams, however, it is by considering the system and the final product together that the best systems are created.

Torrey Podmajersky gave a talk about using proven writing patterns to create better (and better converting) web experiences. As a developer, I understand trying to use simple language and letting context provide some of the words for you, but this talk gave a huge array of great little templates for content that help users and help businesses achieve both their goals.

One of our in house phrases at Etch is that design is “putting words in boxes”, so the words matter a lot! It was great to see how content can be broken down into a scientific framework that can be distributed across teams who may not have content writers so they can still create awesome, on brand, experiences.

Content design came up a lot, including in two talks where it was the whole focus. I liked Torrey Podmajersky’s suggestion of using content pattern templates in component documentation - it makes a lot of sense to have easily digestible guidance on content situated alongside the component it would be used in, rather than bloating the documentation with pages and pages of text that no-one wants to read. Natalie Hernandez showed that content design can extend far beyond putting words in boxes on a page: documentation, naming conventions, and newsletters are all part of her job description.

I have to admit that Torrey’s book has been sat on my shelf un-read for a couple months now, but has quickly made it’s way to the top of my TBR list after her talk on UX content design. Her talked focused on a whistle-stop tour of simple and effective patterns for UX copy.

I also particularly liked Torrey’s approach to communicating UX content best-practices and her suggested approach of putting pattern constructs directly into component stories. This makes it almost unavoidable and marries the components and the copy together as one, rather than two separate ideas.

Beyond Torrey’s talk, Natalie Hernadez discussed how to apply design thinking to content writing about a design systems. This included how to write better documentation, communicate about a system better and apply clearer naming conventions.

Heydon Pickering cuts through nonsense. It’s so easy to get distracted with our processes and components and tokens and forget about the point of what we are doing, which is helping people use online services. Heydon gave an awesome (and rather sweary) talk on not making assumptions about your users based on the tools they are using, such as screen reader users being blind or being experts at using screen readers.

He made some very good points that we can carefully craft complicated interfaces, marking them up with all the appropriate semantics elements and aria attributes, but they can still be a worse experience (for all users) than just putting the content on the page. There’s a lot to be said for striving to provide the simplest solution.

Do less in general. Just put the text on the page. Create simple, logical, interfaces.

Heydon discussed the importance of not trying to guess who your user is beyond what you actually know. For example, a screen reader user might be blind, low vision, dyslexic or have any number of other reasons to be using the tool. Many developers might use alt=“” for unnecessary background stock images, but for a low vision user who can only partially see the image this might be more confusing than useful. Instead your priority should be on creating equatable experiences, regardless of the tools a user is utilising to access the site.

Beyond this, Pickering made the point that the easiest way to create a more accessible experience is to create a simpler ones. Hiding text behind toggles, adding tabs and carousels all add more complexity to the site - and more complexity means more cognitive load for all users. Not all users using accessibility tools will be power users who understand aria attributes and tab navigation fully, the best way to create a more equatable experience is to create a simpler one.

Not everything needs to be accessible. Some things shouldn’t exist at all.

Tesco’s Diane Larsen talk discussed how to get design teams onboard with using a new design system. Whilst she discussed a range approaches and issues that might arise - the biggest takeaway was the benefit of having better integration between product and systems designers, as well as how you allow for customisation within a rigid system. I liked her breakdown of different types of components that have different levels of reach, and therefore governance, within a system:

• Foundations - Used by all products, including non-digital ones
• Global components - Used across all digital products
• Platform components - Used across a smaller range of products
• Product components - Only used within a single product
• Snowflakes - Unique components only used once

Ben Callahan shared some learnings from his design system-focused weekly collaborative conversation “The Question”. It seems like a really valuable resource for anyone who works on design systems so I’ll definitely be checking it out.

Callahan's project, "The Question" seemed like a more collaborative and interesting approach to sharing knowledge than a podcast or blog, so I will definitely be checking it out in the future.

David Darnes highlighted the power of web components. Although I’m reasonably familiar with web components, there were a few things that were new to me, and frankly I liked the silliness of the demonstration (more websites should have a sound effect of a honking goose).

Design Systems seem to be everywhere right now, in our work and in our minds. The main drive for me now, is to go beyond “just a component library” and start stretching into UX patterns, content design and analytics. We can equip teams with components, but we need to help guide them in their usage or they are just a set of shiny toys.

Across the two days, the talks covered a wide range of topics around design systems; as well as the usual design and development-focused talks you might expect, we heard about managing workflows for huge design systems, customising the tiniest details of typography, and everything in between.

Across two days, converge covered a wide range ideas and parts of design systems. The talks covered everything from Nathan Curtis discussing his approaches managing huge multi-platform systems, to a talk about the tiny details that went into Spotify’s new custom typeface. My main takeaways were around writing and communicating UX content better, accessibility and, more generally, how we think about design systems within the wider product context as a whole.