Building delight in your design system

This is an edited version of the talk that I delivered to Design Matters in Copenhagen in September, 2022.

Delight is a word that is thrown around by designers a lot, usually when they want to complain about the work they’re not being allowed to do, or, like me, when they’re on a soapbox, trying to tell other designers how to do their jobs. So, why is delight important, and what should we be talking about when we use the word ‘delight’?

According to the internet of dictionaries, to ‘delight’ someone is to give great joy or satisfaction. There are two parts to that: Joy and satisfaction. Personally, I think a lot of focus when we talk about delight tends to focus on the joy part primarily, and not as much on the satisfaction. We aim for delight on a surface level, and not at a deeper level.

Deep Delight vs Surface Delight

This isn't a new thought. In fact, it's been mainly stolen from Aaron Walter in his NNGroup article, and in his (fantastic) book Designing for Emotion. Aaron redrew Maslow’s heirarchy of needs into his heirarchy of user needs. As you can see above, he suggests that without functionality, reliability and usability (in that order), we can’t achieve achieve pleasurable experiences, no matter how hard the design tries. As part of that, he identifies that these first three (functional, reliable, usable) are responsible for deep delight, whereas the pleasure is only surface delight.

Aaron Walter's heirarchy of user needs

You’ll only be able to effectively satisfy someone if your product delivers on the deep delight: if your product works as it’s expected to, or surprises the user by working better than it’s expected to; if it deliver the information that is required, when it’s required; If it anticipates the user’s needs and gets it right; If it learns from the user and adapts, either through fancy AI or just through the product team actually listening and making product changes.

Basically, creating an exceptional user experience is a precondition for deep delight.

And it's important — Deep delight is how you create lifetime customer value. Deep delight is how you have your product be embedded in a user’s day to day life. Deep delight is how you create psychological safety with your customers.

However, deep delight being important doesn't erase the importance surface delight.

Using MaccyDs to stretch the analogy

Surface delight is the difference between McDonalds and a fancy restaurant. Bear with me... When you break it down, McDonald’s is an incredibly efficient machine that prioritises consistency, quality and usability. They satisfy the basic needs pretty darn well, from the ordering process, to the speed of production, to the fact that a Big Mac tastes pretty much the same no matter where you go. But it’s the focus on pleasure via ingredients, techniques and atmosphere among other things that elevates a Nobu or a Fat Duck. Both a fancy restaurant and McDonald's satisfy the basic needs, but the focus on creating an elevated, pleasurable experience is what gets people talking. It’s what gives people FOMO. It’s what makes people excited to tell their friends about it.

Especially in the saturated market we live in today, where it’s rare to have an app or website that truly differentiates on core experience, or heck, even layout, the surface delight is often the area to most easily differentiate. Creating happiness, joy or any other positive emotional reactions can mean you stand out and excel. Basically, surface delight is an amplifier.

Enter the Kano

If you want some more science around this, Noriaki Kano developed the Kano model back in the 80s that shows that customer loyalty is connected to our emotional responses to product features. He did a similar thing, in that he split up these features into a hierarchy:

• must-be qualities — the basic needs. The expected qualities. Without basic needs satisfied in your product, you'll never get satisfaction from a user.
• one-dimensional qualities — performance needs. These are the things that make things work better. The performance improvements. These offer satisfaction when fulfilled well, but dissatisfaction when not fulfilled well.
• attractive qualities — the delighters. These are the sprinkles on top. They satisfy when fulfilled well, but they don't actually change anything in satisfaction if you don't fulfil them
• Indifferent qualities — the things that don't make any change
• Negative qualities — the things that no matter how well you fulfil them, they will always dissatisfy the user.

The Kano Model graph that is show absolutely everything

I'll come back to the last two later, but in essence, Kano found that if you don’t meet the base-level needs, customers won’t be satisfied with the experience and the performance and delighters mean bupkis. Similarly, if your performance needs are dissatisfying, your delighters will be less effective. He also notes that over time and with greater exposure, delighters can become performance needs, and performance needs can become basic needs. Basically, today’s shiny things are tomorrow’s table stakes.

Just think about Twitter's [pull to refresh pattern](https://uxplanet.org/pull-to-refresh-ui-pattern-42a85f671cdf?gi=545a906bf3f2#:~:text=The%20pull%2Dto%2Drefresh%20(,countless%20apps%20adopted%20this%20gesture.), or the slash command in Slack or Discord. These have relatively quickly moved from exciting delighters to standard UI patterns that dissatisfy when they don't exist (or don't work as expected).

An example of playful delight via Mailchimp

Types of delight

I’d argue that as product teams, we’re still struggling with the ‘deep delight’ part of the pie, but creating functional, reliable, usable products is another article. Let’s focus for a bit on the surface delight part, as it’s the thing that’s often sacrificed, especially when it comes to our MVP-obsessed product culture today.

So, what different types of delight are there? I think Microsoft’s categorisations of the five patterns of delight are pretty good boxes to put things in:

• Playful experiences — these are ones that try and elicit smiles and laughter. They encourage people to enjoy what they’re doing, not just focus on getting it done. These are good for providing an emotional boost to your users.
• Attractive experiences — kind of speaks for itself. We’re talking about aesthetically pleasing, or more importantly, aesthetically pleasing to your demographic. We’re aiming for a sense of belonging, or aspirational belonging. To tell the story of the product through aesthetic choices.
• Natural experiences — comfortable and intuitive. This is where that satisfaction part of delight comes in. Natural experiences excel at making a user feel at home. They’re trying to play off of memory and affordances (bordering on mimicry) to achieve it.
• Personal experiences — these empower the user. Allowing the user to personalize, or even better, automatically personalizing based on experience and assumptions (if you get it right), empowers them and helps them ground a routine because it’s what they feel like they need. It gives them agency and it fulfils their needs.
• Empowered experiences — This is where you feel like you’ve got super powers. Doing something way easier than they have before. It leaves the user feeling delighted with themselves and what they’ve done. It also makes them appreciative for the time and cognitive effort they’ve saved.

Now, it's important to note that not all of these will make sense for your product. You definitely need to figure out what fits what you're trying to achieve.

Building delight into your systems

The beginning is a very good place to start

Just like any good systems thinking exercise, it's always best to start at the foundation. We know that the foundation is where your colours, typography, spacing, grids are defined. Hopefully, it’s also where your design principles and core guidelines are established too. But before we get there, let's go a level up to the organizational level.

The way I like to look at the hierarchy of your systems

Delight as a value

If you haven’t already, work on a design team charter - this is a foundational document that not only defines how your team works, but also what values you have as a team for what you’re working on. They provide a consensus for what you do and how you do it, and help you engrain and encode important things into your team (like, I don’t know, delight).

If you want a template for a workshop on how to write a design charter, Michelle has pulled together this handy workshop. If you want to know more about them, Peter Merholz and Kristin Skinner covered them really well in Org Design for Design Orgs (which should be any design leader, designops, or design team nerd's bible).

Delight as a principle

Next level down, your principles. Your principles are similar to your values, but are more focussed on the work that you create — the outputs. They are a few statements that cover off the most important things when it comes to the things you create. They enable you to have a guiding light when you’re deciding on solutions, and more importantly, the scope of solutions. They also act as a blunt object to beat people over the head with when something isn’t satisfying the principles (or maybe just a good focal point for conversations).

Enshrining delight in your principles is a first step in saying ‘we believe in this and we are prioritizing this’. You could use 'keep it wonky' if you wanted to focus on playful. It could also be ‘make everything a learning opportunity for your product’, if you were prioritizing empowering delight. Or “Make it feel like sinking into a sofa” to encapsulate the natural or aesthetic delight you’re trying to capture. Again, if you want some advice on writing good principles, there's another great article on that.

Minimum Delightful Product ?

Having these things enshrined at a Values and a Principles level, for both your design and product teams, means that you can start having those conversations about what the V stands for in MVP. Viability should be a combination of user needs and org needs. If one of your org needs is to create a product that elicits an emotional response, or encourages users to stick around without providing extrinsic motivation, then there should be a shared understanding between your teams that delighting users is part of the ‘viability’.

I’ve heard people use terms like ‘Minimum Loveable Product’ or ‘Minimum Delightful Product’ and this just makes me throw up in my mouth a little bit. It also devalues how important delight can be to succeeding. Delight can mean viability. If it’s the case for your product, be explicit with how important it is, and build a shared understanding around that between your product, design, engineering, and senior leadership teams.

Making delight repeatable

But how do we make delight repeatable at a component level?

First up are illustration systems. Product illustration is a super powerful way of getting complex concepts across in simple ways. However, they’re also great for providing the user a guide for what emotional state they should be in. Using color, type, motion, and, very specifically, faces and body language, gives the user a shortcut for how they should be feeling when using the product.

One of the problems with product illustration is that it can be costly and hard to scale. Illustration systems are, in their simplest form, a way of codifying your illustration patterns through guidelines, templates, and libraries (ie. how to use illustrations, how to make illustrations, and libraries full of ones you’re able to use). They can also include some pretty cool modular illustration systems, much like the ones that Blush provides. I also recommend this great talk by Bonnie Kate Wolf on illustration systems.

The Blush Figma plugin in action

Next up, microcopy. Another area that is so often underloved within design is content. I was genuinely surprised by the lack of content specialists in the How We Document survey we ran last year (< 1% ?). Words and visuals are your main tools for conveying meaning, information, and emotion, and filling both of these with personality is a quick way to inject joy into your product.

Systematising microcopy is relatively easy. One - hire a content specialist for your design system. Easy. Second, and at the very least, make sure you spend time writing your content creation guidelines. This is pretty commonplace for marketing copy, but product copy goes severely unloved. What ends up happening instead is that it comes down to the designer who’s doing the screen to chuck something in there. Shudder.

One of the most obvious ways to inject delight into your product is via motion. It’s another thing that gets left by the wayside in the pursuit of MVP. Adding expressive motion to your product brings it to life. It celebrates the interaction and adds character. It’s a great way of conveying your brand to the user.

But how do you systematize it? Apart from leaving room in the product process, or having minimum guidelines for components that include animation, tokens can also help us smooth out the bumps when it comes to implementing motion and animation. We can now encode the animation values via design tools (or write straight to the JSON). These can then be translated and spat out in whatever format your devs need, meaning they don’t have to faff about with it as much. Also, things like Lottie are making advanced motion much easier to implement, as it spits out a JSON file directly from After Effects that is dropped in almost like an img into your code (as long as you reference the Lottie library).

An example of how animation tokens work from Prototypr's great article

Don’t forget your (internal) users

One area I don’t think I’ve seen as much, is taking effort to sprinkle delight on your docs and internal tooling. It will most likely have to be via copy, but have fun. Team happiness should be a key success factor in your design system. A happy, content, and satisfied team are good for business. They’re productive and won’t be as likely to leave. Yes, you have to make sure your docs are functional, reliable, and usable first, but adding a little bit of delight just makes the ‘happiness’ metric that little bit easier to achieve.

Want some examples? An oldie but a goodie is the 'I am a teapot' HTTP status. One closer to the design system world is Gitlab's inclusion of the 'socks' component. They didn't need to include these, but they add a little bit of joy to people's lives. Or even Brainly's use of beautiful motion and illustration in their Pencil docs shows that care can add some beauty and joy for your internal users.

Pencil's current animation on the front page of Pencil

Measuring it

However, doing all this joyful work means nothing if you aren't measuring it. Figuring out the ways to measure the effects of happiness is notoriously difficult. But just like anything, there are a combination of measures that can get you there. They'll likely be a mixture of qualitative and quantitative measures. The qual measures are especially good at increasing confidence that what you're creating works, but the business will likely want some kind of quant proof that it's working...

A large part of figuring out the right quant measures are figuring out your leading metrics are. These are the things that, while probably not the important metrics you want to measure like retention, signup, or word-of-mouth reach, are the things you can effectively measure and change within a reasonable time frame. The problem with a lot of the measures that directly impact the business is that most of these are lagging metrics, and will sometimes take months, or even quarters, to move.

There’s also a point where you need to realize that some things are just really hard to measure. This is where you need to come to an agreement on what a 'good enough' measure is for your business. Yes, it would be amazing to run everything through variant testing with user diaries and absolutely every facet tracked, but that would also cost a fortune and take 6 months to prove. MVP your measurement.

But what about your internal teams? Measuring team happiness through surveys, in-’product’ feedback, and user interviews is an important way to be showing the value you’re bringing.

Finally, once you’ve figured out what works for you, engrain these measures in your KPIs, OKRs, or whatever other measurement frameworks you use. This will automatically raise their importance to your stakeholders. It gives you something to lean upon to make sure it’s taken seriously.

Be mindful of when it goes wrong

Causing delight is a tricky business. It’s what Kano talks about with those indifferent qualities and negative qualities. Indifference and negative satisfaction, especially with delight, are often a matter of taste. Some people just don’t find cutesy or quirky things delightful. Others don’t have the cultural experiences or cues to relate to, to make your western-focussed natural interface a comforting experience (remember, we often deal with global userbases these days). If you assume or guess ways to empower, and they don’t land, it could end up harming an experience for some users.

This is ok, but it’s why testing with users is so important with delight.

You obviously won’t be able to show your designs to everyone, and it won’t be in the same context, but you should get some 'heads-ups' on what works and what doesn’t, and then use that to inform decisions on what stays and what doesn’t. Just make sure that when you’re doing testing, it’s with a diverse user base of different cultures, ages, genders, backgrounds, etc.

Luke is a Design Advocate @ zeroheight. When he's not enthusing about DesignOps, he's playing in bands, drawing silly things or writing academic articles about Josie and the Pussycats.