Better Collaboration By Bringing Designers Into The Code Review Process
Smooth collaboration between developers and designers is something everyone aspires to, but it’s notoriously difficult. But with today’s advanced web, it’s difficult — if not impossible — to build a truly great product without collaborating across disciplines. Because of the range of technologies required to build a product, the product can only truly succeed when all disciplines — developers and designers, content creators, and user experience strategists — are deeply involved from the early stages of the project. When this happens, all ends of what it takes to build a product come naturally together into a unified whole, and a thus great product.
Because of this, no one is really promoting waterfall processes anymore. Nevertheless, involving other people early on, especially people from other disciplines, can feel scary. In the worst case scenario, it leads to “design by committee.”
Moreover, both designers and content strategists often have backgrounds in fields in which a sole creative genius is still the ideal. Having someone else proof your work can feel like a threat to your creativity.
So how can you involve people early on so that you’re avoiding the waterfall, but also making sure that you’re not setting yourself up for design by committee? I found my answer when learning about code reviews.
The Aha! Moment
In July 2017, I founded Confrere together with two developers, and we quickly hired our first engineer (I’m not a developer myself, I’m more of a UX or content designer). Our collaboration was running surprisingly smoothly, so much so that at our retrospectives, the recurring theme was that we all felt that we were “doing it right.”
I sat down with my colleagues to try to pinpoint what exactly it was that we were “doing right” so that we could try to preserve that feeling even as our company grew and our team expanded. We came to the realization that we all appreciated that the whole team was involved early on and that we were being honest and clear in our feedback to each other. Our CTO Dag-Inge added: “It works because we’re doing it as peers. You’re not being berated and just getting a list of faults”.
The word “peer” is what gave me the aha moment. I realized that those of us working within UX, design, and content have a lot to learn from developers when it comes to collaboration.
Peer reviewing in the form of code reviews is essential to how software gets built. To me, code reviews offer inspiration for improving collaboration within our own fields, but also a model for collaborating across fields and disciplines.
If you’re already familiar with code reviews, feel free to skip the next section.
What Is A Code Review?
A code review can be done in various ways. Today, the most typical form of code review happens in the way of so-called pull requests (using a technology called git). As illustrated below, the pull requests let other people on the team know that a developer has completed code that they wish to merge with the main code base. It also allows the team to review the code: they give feedback on the code before it gets merged, in case it needs improvement.
Pull requests have clearly defined roles: there is an author and a reviewer(s).
As an example, let’s say our senior engineer Ingvild has made a change to Confrere’s sign-up flow. Before it is merged into the main code base and gets shipped, she (the author) creates a pull request to request a review from our CTO Dag-Inge (the reviewer). He won’t make any changes to her code, only add his comments.
It’s up to Ingvild how she wants to act on the feedback she received in the review. She’ll update her pull request with the changes she sees fit.
When the reviewer(s) approve the pull request, Ingvild can then merge her changes with the main code base.
Why Bother Doing Code Review?
If you’ve never done code review, the process above might sound bureaucratic. If you have doubts, here’s a tonofblogposts and academic research about the advantages of code review.
Code reviews set the tone for the entire company that everything we do should be open to scrutiny from others, and that such scrutiny should be a welcome part of your workflow rather than viewed as threatening.
Code review reduces risk. Having someone proof your work, and also knowing someone will proof your work, helps weed out errors and heightens quality. In addition, it ensures consistency and helps every team member familiarize with more of the code base.
When done right, code review also builds a culture for collaboration and openness. Trying to understand and critique other people’s work is an excellent way to learn, and so is getting honest feedback on your work.
Always having at least two people look over the code also curtails ideas of “my” code and “your” code. It’s our code.
Considering these advantages, a review shouldn’t just be for code.
Review Principles For All Disciplines, Not Just Code
With reviews, there is always one author and one or more reviewers. That means you can involve people early on without falling into design by committee.
First, I have to mention two important factors which will affect your team’s ability to do beneficial reviews. You don’t necessarily have to have mastered them, but as a minimum, you should aspire to the following:
Don’t forget to praise the good parts! What’s clever, creative, solid, original, funny, nice, and so on?
These principles weren’t actually written down until after we discussed why our collaboration was working so well. We all felt we were allowed to and expected to ask questions and suggest improvements already, and that our motivations were always about building something great together, and not about criticising another person.
Because we were being clear about what kind of feedback we were giving, and also remembered to praise each other’s good work, doing reviews was a positive force rather than a demotivating one.
To give you an idea of how our team uses review across disciplines and throughout a process, let’s look at how the different members of our team switched between the roles of author and reviewer when we created our sign-up flow.
Whiteboard sessions can be exhausting if there’s no structure to them. To maintain productivity and creativity, we use the author/reviewer structure, even for something as seemingly basic as brainstorming on a whiteboard. In this case, in which we were coming up with the requirements for our sign-up flow, I got to be the author, and the rest of the team gave their feedback and acted as reviewers. Because they also knew they’d be able to review what I came up with in step 2 (plenty more opportunity for adjustments, suggestions, and improvements), we worked swiftly and were able to agree upon the requirements in under 2 hours.
As an author, I created a mockup of the sign-up flow with microcopy. Did the sign-up flow make sense, from both the user and engineering perspective? And how could we improve the flow from a design and frontend perspective? At this stage, it was essential to work in a format in which it would be easy for all disciplines to give feedback (we opted for Google Docs, but it could also have been done with a tool like InvisionApp).
Step 3: Implementing the sign-up flow
Author: Ingvild (engineering)
Reviewer: Ida (UX) and Dag-Inge (engineering).
We had agreed upon the flow, the input fields, and the microcopy, and so it was up to Ingvild to implement it. Thanks to Surge, we can automatically create preview URLs of the changes so that people who can’t read code are able to give feedback at this stage as well.
Step 4: User testing
Author: Ida (UX)
Reviewer: The users.
Yes, we consider user testing a form of review. We brought our newly built sign-up flow face-to-face with actual users. This step gave us a ton of insight, and the most significant changes in our sign-up flow came as a result.
Step 5: Design
Author: Eivind (design)
Reviewers: Ingvild (engineering) and Ida (UX).
When design suddenly shows up here in step 5, it might look a lot like a waterfall process. However, our designer Eivind had already been involved as a reviewer since step 2. He gave a bunch of useful feedback at that stage and was also able to start thinking about how we could improve the design of the sign-up flow beyond the existing modules in our design system. At this step, Eivind could also help solve some of the issues that we identified in the user testing.
Step 6: Implementation
Author: Ingvild (engineering)
Reviewer: Eivind (design), Ida (UX) and Dag-Inge (engineering).
And then we’re back to implementing.
Why review works
In summary, there’s always just one author, thus avoiding design by committee. By involving a range of disciplines as reviewers early on, we avoid having a waterfall process.
People can flag their concerns early and also start thinking about how they can contribute later on. The clearly defined roles keep the process on track.
Regular Review Walkthroughs
Taking inspiration from code walkthroughs, we also do regular review walkthroughs with different foci, guided by the following principles:
The walkthrough is done together.
One person is in charge of reviewing and documenting.
The idea is to identify issues, not necessarily to solve them.
Choose a format that gives as much context as possible, so that it’s easy to act upon the findings later (e.g. InvisionApp for visual reviews, Google Docs for text, and so on).
We’ve done review walkthroughs for things such as accessibility audits, reviewing feature requests, auditing the implementation of the design, and doing heuristic usability evaluations.
When we do our quarterly accessibility reviews, our accessibility consultant Joakim first goes through the interface and documents and prioritizes the issues he’s found in a shared Google Sheet. Joakim then walks us through the most important issues he’s identified.
Meeting face-to-face (or at least on video) to go through the issues helps create an environment for learning rather than a feeling of being supervised or micromanaged.
If you find yourself always being tied up with something that’s due for release, or fixing whatever is at the top of your inbox, reviews can help remedy that. If you set aside regular half days for reviewing work you’ve already done, you can identify issues before they become urgent. It can also help you refocus and make sure you’re priorities are keeping along the right lines. Your team should maybe not begin building that new feature before you’re confident that the existing features are living up to your standards.
User Testing Is A Form Of Review
An important motivation for code reviews is to reduce risk. By doing it every single time you introduce a change or add something new to your product, and not just when you suspect something is maybe not up to par, you diminish the chance of shipping bugs or subpar features. I believe we should look at user testing from the same perspective.
You see, if you want to reduce the risk of shipping with major usability issues, user testing has to be part of your process. Just having your UX designers review the interface isn’t enough. Several studies have found that even usability experts fail in identifying every actual usability problems. On average, 1 in 3 issues identified by experts were false alarms — they weren’t issues for users in practice. But worse, 1 in 2 issues that users did in fact have, were overlooked by the experts.
Skipping user testing is just as big a risk as skipping code review.
Does Review Mean Death To Creativity?
People working within design, user experience, and content often have educational backgrounds from art schools or maybe literature, in which the sole creator or creative artistic genius is hailed as the ideal. If you go back in history, this used to be the case for developers as well. Over time, this has changed by necessity as web development has grown more complex.
If you cling to the idea of creativity coming from somewhere deep within yourself, the idea of review might feel threatening or scary. Someone meddling in your half-finished work? Ouch. But if you think about creativity as something that can spring from many sources, including dialogue, collaboration, or any form of inspiration (whether from the outside or from someplace within you), then a review is only an asset and an opportunity.
As long as we’re building something for the web, there’s no way around collaborating with other people, be it within our own field or others. And a good idea will survive review.
Did you know that poor web design can hurt conversions and sales? An unattractive site deserves a website redesign. No matter what your company size or industry is, though, it’s crucial that you take a strategic approach to your website redesign. Know what isn’t working, what does currently work, and what goals you wish to achieve. Otherwise, how will you take advantage of your existing web traffic? Worse, what happens if your web design is causing people to avoid visiting your site at all? Let’s look at some of my favorite techniques for creating a website redesign strategy and implementing…
Landing page optimization doesn’t happen overnight. That’s why marketers get frustrated — and often give up. If you want better landing pages, focus on collecting data. You should design your landing pages based on what you already know about your audience, but don’t stop there — make sure you collect even more information as more people visit your website. Converting that data into informed decisions about your marketing funnel can produce more leads and sales. Today, I’m going to teach you my best landing page optimization tips and tricks so you can attract more prospects and convert more customers. If…
I’ve written a lot about user experience over the years: how to improve user experience, when to implement it, and how to test for it. There’s a reason I cover it so widely, though. It touches every aspect of your business, from SEO to customer service. If you owned a brick-and-mortar store, you would worry about things like end cap displays, signage, aisle navigation, and sales support. Those things matter online, too, except they’re more difficult to observe and track without specialized tools. You can’t enter your customers’ homes and look over their shoulders while they check out your social…
Smashing Book 6 Excerpt: Bringing Personality Back To The Web
Generic web layouts have become somewhat of a misnomer in conversations circling around web design these days. We’re bored and slightly annoyed by how predictable and uninspired most web experiences have become. Not without reason, though. Every single landing page seems to be a twin of pretty much every other web page.
In the header, a compelling hero image with a short main heading is followed by a lengthier subheading. Beneath them, uniform blocks of media objects are alternated — an image and a few paragraphs of text. First, text on the left, image on the right; then image on the left, text on the right. Rinse and repeat. Rounded profile photos and a square grid of thumbnails complete the picture, with perfect shapes perfectly aligned along the 12-column grid. The only variations come from sporadic parallax transitions and notorious carousels, positioned at the top or bottom of the page — or perhaps both.
It’s not that somebody imposed these rules or limitations on our creative output; usually they originate from good motives and the best intentions. After all, one of the main tenets of web design has always been creating a subtle, almost invisible and functional interface — an interface that doesn’t make users think, where less is more, and form follows function, where simplicity prevails — an interface where everything feels just right.
Yet when everything is structured in a predictable way, nothing really stands out. Given how remarkably similar names, logos, icons, typography, layouts, and even shades of gradients on call-to-action buttons often are, it’s not surprising our users find it difficult to distinguish between brands, products, and services these days.
Very few people miss the golden times of the infamous Flash, with its strikingly experimental layouts and obscure mystery-meat navigation. Admittedly, in many cases the focus has shifted from creating an experience to merely providing content in a structured form. Yet unlike in those good ol’ days when we talked about how wonderful or horrible websites were, today most experiences are almost invisible, making it exceptionally difficult to connect emotionally with them.
If I asked you to think of a recently visited website that left a lasting, memorable impression on you, or what websites you truly love and admire for their unique design, or what website had a truly remarkable personality, would you be able to answer these questions immediately? Would you be able to provide more than one or two examples? Chances are that you won’t.
Not every website has to be unforgettable. It’s not that memorable websites automatically perform better, or hit better key performance indicators. However, if you want your product or service to stand out in a highly competitive and challenging environment, you need to be different in some way. Many of us would consider this to be the task of the marketing team. After all, they are supposed to place the product in the right light, at the right spot, for the right audience, at the right price. Yet in a world where many digital products are fairly usable and feature-rich, this would be a daunting undertaking that would often require months of extensive research and testing without the guarantee of a successful outcome. And even then, unless you are extremely good at predicting and shaping the next shiny big thing, it might not be good enough.
Customers are used to and expect decent experiences. They aren’t always fast or straightforward, but simply because of the sheer number of offerings, there are always decent tools and services out there that would be good enough.
We tend to believe we rationalize our decisions to extremes, choosing the best candidates, but it’s not necessarily true. According to well-known Herbert A. Simon’s satisficing theory, we tend to prefer the first option that meets an acceptability threshold, just because we don’t know if we can find a better option or how much effort it would take. We rarely study the entire spectrum of options in detail (and sometimes it’s nearly impossible), and as a result, we satisfice with a candidate that meets our needs or seems to address most needs.
To draw an audience’s attention, we need to be better than “good enough.” Nothing can beat word of mouth, but to get there we need to come up with something that’s worth looking at. What if I told you that there was a shortcut to getting there?
It’s not just about price. It’s not just about features. It’s not just about choosing the right placement of buttons, or the right shades of colors in endless A/B tests. And it’s not about choosing a cute mascot illustration that shows up in email campaigns. In the end, it’s about creating an experience that people can fall in love with, or connect deeply with — an experience that, of course, drives the purpose of the site, but also shows the human side of it, like the personality of the people building it, their values and principles, their choices and priorities.
That means designing voice and tone, interface copy, and embracing storytelling, authenticity, inclusivity, and respect; and all of that while establishing a unique visual language supported by original layout compositions and interaction patterns. Together with clear and honest messaging, these create a unique signature, which, used consistently, makes the product stand out from the rest. This task might sound as daunting as months of marketing research, but it doesn’t necessarily require an enormous amount of effort or resources.
In this chapter, we’ll look into a few practical techniques and strategies that might help you find, form, and surface your personality efficiently. By doing so, we’ll explore how doing so consistently could fit into existing design workflows, along with plenty of examples to give you a good start. But before we get there, we need to figure out how omnipresent design patterns and best practices fit into the equation.
Breaking Out By Breaking In
The creative process isn’t linear. Every single design decision — from colors and type to layout and interactivity — requires us to consider options and evaluate combinations. While the creative process is often seen as a straightforward, iterative process, in reality it’s very rare that we smoothly move from one mock-up to another through a series of enhancements and adjustments. More often than not, we tend to float and diverge, heading from one dead end to another, resolving conflicts and rerouting our creative direction along the way.
Those dead ends happen when we realize we aren’t really getting anywhere with the result exposed on our digital canvas. We’ve been there so many times, we know how to explore uncharted territories and how to maneuver the flanks, and so as we keep sculpting our ideas, we keep making progress, slowly but steadily moving towards a tangible result. Two steps forward, one step back, revisiting what we’ve done so far and refining those precious pixels — based on… frankly, based on intuition and random experiments. Eventually the back-and-forth brings us to a calm, peaceful, and beautiful place — just where we think we’ve found a solution — the solution.
We know, of course, that it’s unlikely it’s going to be the one, though, don’t we?
This journey from nothing to something isn’t just full of conflicting micro-decisions; it’s crammed with unknowns, traps, friction, and difficult constraints, be they of a technical nature or time-sensitive. And at every moment of the process, the beautiful, harmless creatures of our imagination can be mercilessly smashed against the harsh reality of user interviews and client revisions. So we swizzle around from one direction to another in a fertile yet remarkably hostile place. As a result, usually we can’t afford the luxury of losing time, as we know that the path to that deadline, harmlessly floating in the remote future, will be full of surprises and unexpected turnarounds.
To avoid losing time, we rely on things that worked well in our previous projects — the off-canvas navigation, the accordion pattern, rounded profile images, and the holy 12-column grid layout. It’s not for lack of knowledge, skill, or enthusiasm that we fall back to all those established practices — it’s just infinitely more difficult and time-consuming to come up with something different every single time. And because we lack time, we use all those wonderful, tried-and-tested design patterns — all of them tangible, viable solutions for a particular kind of problem. Obviously, this process might be slightly different for different people, but broken down into its essence, that’s what’s happening behind the scenes as we make progress in our designs.
When we started working on the redesign of Smashing Magazine a few years ago, one of the first steps we took was listing and exploring components and micro-interactions. We built the article layout and a style guide, responsive tables and forms, and used many of the established best practices to keep them accessible, fast, and responsive. Yet when putting all these perfect components together, we realized that while they were working well as standalone solutions, they just didn’t work together as a whole. The building blocks of the system weren’t sufficient to maintain and support the system. We had to redesign what we’d built so far, and we had to introduce overarching connections between those components that would be defined through the personality and voice and tone of the new identity.
When we apply design patterns to our interfaces, we essentially bring together a group of loose modules or interactions that lack any connection to everything else. Rather than asking how a particular pattern helps drive the purpose of the experience, we often explore a micro-problem in isolation, putting micro-solutions together. With design patterns, we run the risk of adding a component just because it’s trendy these days — like a parallax-effect, slow and impactful transitions, and fade-ins. By doing so, sometimes we might lose the big picture of what role that component would play at a bigger scale, and how it could be connected to everything else. As a result, we produce soulless, dull, bloated designs with generic compositions and generic visual treatments. That’s how we create something that looks like everything else.
It’s not that design patterns and best practices are necessarily evil, though. They are merely a double-edged sword helping and troubling the visual output.,When applying them, we need to do so carefully and thoughtfully. Whenever you consider resolving a problem with a design pattern, it’s a good idea to ask yourself a few questions:
What problem exactly are we solving?
Is the pattern really the best solution for the problem?
How do people experience this interaction, and what pain points do they encounter while doing so?
How does this component help us reach the overarching goal of the system?
How do we connect that component to the rest of the system — in terms of both aesthetics and interaction design?
Is the solution really universally understood, or do we need to provide more clarity to the design (labels, better copy, affordance, replacing icons with words)?
Is it a good idea to keep the pattern as is at all times? Or is it better to load or adjust it conditionally, perhaps based on the viewport, or how many times a customer has visited the page?
Essentially, we try to break down a design pattern by exploring when and how it’s useful or damaging, and how it helps in achieving our goals. We break out of predictable patterns by breaking in to their nature and understanding why we actually use them. First, we examine the component in its bare, abstract form, without the context of where it’s typically used and how it’s usually designed; for example, rather than thinking of an off-canvas navigation sliding from the left to right, or right to left, we look into the interaction pattern on its own — essentially, progressive disclosure in which content is hidden by default and displayed on click/tap. Then, for every pattern, we explore its usability issues and problems, resolve them, and then style and design the module in a way that feels connected to everything else. That last step could be something as simple as a consistently used transition, or a geometric pattern, or a non-conventional position in the layout. Finally, once everything is in place, we repackage the design pattern and add it to the library, ready to be served for the rest of the system.
Of course, best practices and design patterns are fantastic shortcuts for getting on the right track faster. They let us tap into predictable interactions and sequential knowledge that most of our users will have. In fact, they are as relevant today as they’ve always been. The key is in finding a way to apply them meaningfully within the context of the visual language used throughout the site, and knowing when to break them deliberately to trigger an emotional connection.
Humans Connect To Humans
Do you remember the good ol’ days when we used an omnipresent “we” to make our little web shops appear bigger than they actually were? You might have been the only person freelancing from home in slippers and a bathrobe, or one of the very few people in a small design agency, but that profound “we” made the company sound more serious, and hence more trustworthy, didn’t it? We’ve pretended to be somebody else to get projects we wouldn’t be entrusted with otherwise — and I’ll be the first to admit that I am as guilty of it as everybody else.
These days, when so many things around us are exaggerated and deceptive, authenticity remains one of the few qualities people genuinely connect to. Too often, however, it’s not exhibited through a website at all, regrettably creating a vague image of yet another obscure entity covered with corporate stock photos and meaningless jargon. When every brand promises to disrupt or be different, nothing truly feels disruptive or any different, and this causes alienation and skepticism.
Humans can genuinely connect to brands they trust, but brands need to earn that trust first. Obviously, it comes from reliable recommendations and positive experiences. But as designers communicating on behalf of companies, how do we efficiently elicit trust in people who aren’t yet aware of the brand? As it turns out, trust can also come from the appearance of the brand, which can be influenced by its values, beliefs, principles, and activities. It isn’t easy to fall in love with a company or organization without knowing somebody who admires it almost contagiously. It’s much easier to connect with people whose values you support, and with people who stand behind their beliefs and principles.
If humans connect best to humans, perhaps if our interfaces reflected the values of the people creating them, we might be one step closer to triggering that desired emotional connection. We’ve been there before, of course, and so that’s why we show the people working in the company on a “Team” page or in the footer of the front page, right? Well, let’s look into it from a slightly different perspective.
What if you were asked to describe the personality of your brand? What adjectives would you use? Think about it for a minute, and write them down.
Ready? Chances are high that you’ve come up with common and predictable answers. Perhaps words such as “simple,” “clean,” “strong,” “dynamic,” “flexible,” or “well-structured” have come to mind. Or maybe “attentive to details,” “focused,” “user-centric,” and “quality-driven.”
Can you see a problem with these answers? These words describe our intention rather than our personality. While the former is usually very specific and stable, the latter is usually very fuzzy and ever-changing. The qualities outlined above don’t provide a good answer to the question, as they describe how we want to be perceived, but not necessarily how we actually are. In fact, usually we don’t really know who we are or how we are perceived outside of the comfortable company bubble we find ourselves in.
Instead, what if you asked your colleagues and customers a slightly different question: what they care about most in their work, and what they value the most about the company or the product. Maybe they care about the diversity of talented, motivated co-workers who are knowledgeable and experienced, yet also approachable and humble? Maybe it’s the fact that the company is actively contributing to pro bono projects for non-profit organizations that make a real difference in the world. Maybe because it supports schools and newcomers to the industry by providing an annual scholarship. Or because it ties in the profits with a fair salary bonus for all employees. Or just because it allows you to play with the latest fancy technologies and crazy experiments, and contribute to open-source in five percent of your working time. The company doesn’t need huge ambitions, idealist goals, or a fancy working environment to stand out.
Sidenote: Designing humane experiences means being kind and humble, and emphasizing qualities that matter to the company and to users. That means highlighting privacy, respect, ethics, and transparency, but also reflecting the personality of people working on the product.
Here’s an example. Your company could care deeply about diversity, data privacy, accessibility, and transparent pricing. That would mean your interface is accessible and honest, you publicly take a stand against giving away customer data to third parties, and you include features that support pricing comparison without pushing your agenda over the edge. You could highlight those values prominently along with the competitive pricing tiers, and measure the outcome.
Now, can you spot a similar thread among all of the statements above? Because they come from personal experiences, they seem much more human and relatable than more general and abstract terms you might come up with initially.
That’s why companies like Slack or MailChimp feel so much more tangible than brands like Uber or General Electric. They employ quirky and informal microcopy and illustrations that reflect their human side. They don’t shine through a mission statement or press releases, but through the quirks in the interface and how they communicate publicly, via email, or in social channels. That’s the underlying foundation of a character deeply integrated into the user experience.
To avoid a generic appearance, you need to define your personality first. That means asking the right questions and finding accurate answers. When conducting user interviews with our readers, we quickly realized they had a quite different perspective on the Smashing brand than we did. Frankly, we confidently described the brand by listing all the usual suspects, the qualities you probably came up with initially. The truth was baffling, though: we couldn’t have been further away from how the brand was actually perceived.
We always wanted the magazine to be a professional, respectable publication with a strong voice in the industry, highlighting important work done by members of the community. User interviews brought up qualities that didn’t really describe that goal in the way we always strived for. Instead, we heard words such as “informal,” “quirky,” “friendly,” “approachable,” “supportive,” “community,” and — most importantly — “cats.”
Now, we never wanted our legacy to be cats, but it wasn’t really up to us at this point. Back in 2012, our dear illustrator Ricardo Gimenes chose to bring a Smashing cat to life as a mascot for our very first Smashing Conference. There was no conscious decision for or against it. We didn’t even properly discuss it, as we didn’t know if we’d host more conferences in the future anyway. This small decision put something in motion that we couldn’t dismiss years later. Because conferences turned out to become one of our central products, we’ve been promoting them heavily in our mailings, announcements, release posts, and social media messages.
Over time, every conference had to put up with a cat illustration of its own, and all these cats were facing our customers over and over again for years. Cat illustrations heavily influenced the perception of the brand without us actively fostering or guiding it. So we had to make a decision: either let the cats slowly fade away into oblivion, or integrate them heavily into the new design. You probably have discovered by now what we’ve settled with. As of this point, we have over 70 quirky and friendly cats freely wandering all over the new Smashing Magazine website.
However, as much as a mascot can help make the brand more approachable, it’s rarely enough to convey the full story. Interviews also helped us realize how important the community aspect of Smashing Magazine actually was. The words “community” and “people” appeared in user interviews a lot, and not without reason — the magazine wouldn’t exist without humble and generous open-source contributions from people behind the scenes. Our design didn’t really reflect it, though. So we chose to shift the focus slightly towards highlighting the people behind the scenes — authors, editors, and members of the community. Showing people prominently has become another attribute defining our design signature — and that explains why author thumbnails take up such a prominent position in the design, and why we highlight authors publishing on their own blogs or other platforms on our front page.
What does it all mean for you? Ask questions to surface humane qualities that lie in the very heart of the company first. This will give you a foundation to build a visual language on — a language that would translate your qualities to the interface design. Every company has a unique signature in some way, and often it’s reflected through the people working there. Ultimately, it’s just about finding the time and courage to explore it — and to embrace the fact that our flaws and quirks are a part of it as much as our big ambitions and good intentions are.
Personality Is Never Perfect
As designers, we often take pride in being perfectionists. Every pixel has to be polished, every angle has to be just right, and all components should be aligned to the grid. Remember that never-ending discussion about the perfect border-radius on call-to-action buttons? After an eloquent and long-winded debate, the design team eventually settles on 11px, just to switch over to 13px a few months later, just to move back to 12px by the end of the year. In many companies, these changes are prompted through numerous ongoing A/B tests, in which nothing is left to chance, and everything — from assumptions to design decisions — has to be tested and proved first.
We restlessly strive to reach the most effective, the best performing solution — a solution that’s just right. However, aren’t we riding our horses to death trying to improve the same tiny component over and over again, just to find a slightly better variant of it, with all those minimal, microscopic changes?
Espen Brunborg, a creative lead for a graphic design agency in Norway, suggests to never conduct A/B tests alone.1 According to Espen, A/B tests help us reach a local maximum of the user experience, but often they aren’t far-reaching enough to encompass the big picture in its entirety, effectively stopping us from reaching a global maximum.2
1 Jakob Nielsen wrote an article called “Putting A/B Testing in Its Place” back in 2005. The article highlights some of the limitations and downsides of A/B testing; most notably, that it should never be the only method used on a project — observation of user behavior often generates deeper insights.
2 Bill Buxton was probably the first to discuss this problem in his book Sketching User Experiences back in 2007. According to Bill Buxton, designers often end up with a local hill-climbing problem when the design gets plateaued on a local maximum.
That’s why in addition to A/B tests (in which microcopy and colors and positions in the layout are tested), they run so-called A/Z tests, testing an existing “baseline” design against completely different designs. Their differences lie not only in the shade of a button or copy, but in absolutely different layouts and visual treatments. The branding and the core principles remain the same, but pretty much everything else keeps evolving. This allows Espen and his team to reach new absolute maxima in terms of conversion and KPIs every few months.
In one of our conversations years back, Elliot Jay Stocks, who was involved in the 2012 redesign of Smashing Magazine, briefly mentioned one fine detail of his design process that stayed with me for quite some time. He said that a good design possesses one of two qualities: it’s either absolutely perfect in every way, with perfect alignment, sizing, and hierarchy (which is usually quite hard to achieve), or it’s deliberately imperfect in a few consistent ways (which is much easier to achieve). According to Elliot, in a good design there shouldn’t be anything in between. In other words, buttons should either be perfectly aligned to the grid, or not aligned at all — offset by 20–30 pixels and more. Being off just by a few pixels would feel wrong, while being off by 20–30px looks deliberate, and hence less broken.
So what if, instead of chasing the perfect solution for every single component, we ran and tested various expressions of our personalities? In interface design, it would mean entirely different creative directions. Perhaps a multicolumn layout with bold typography, against a geometric layout with a single accent color? What if, rather than seeking the perfect roundness of a button, you deliberately introduced slight inconsistencies? A custom animation on one of the call-to-action buttons, or a dynamic placement of an image outside of the box in which it’s usually supposed to be placed? Or perhaps rotating a subheading by 90 degrees? The personality can be expressed in many entirely different ways, so the task is to discover variations that are promising enough for testing.
A personality is never perfect, and so perhaps our websites shouldn’t be perfect either. What if you set up a publicly visible art board in your company, with magnets representing the qualities on one side, and magnets representing components or visual treatments on the other side, and then randomly clashed one against the other to produce a visual direction for the next A/Z test? Apply perfectionism to the level of detail required to produce deliberately imperfect designs.
This approach won’t always win, but complemented with A/B tests, it might bring you to new heights you wouldn’t be able to achieve otherwise. Ultimately, we want customers to fall in love with their experience and consequently the brand, to form a lasting bond. A deliberately imperfect yet humane interface can help us get there. It requires you to find just one distinguishable quality that nobody else has, and boost it up.
Choose One Thing And Boost It Up
In our interfaces, personality can be expressed through a design signature — a recurring visual treatment, the voice and tone of the copy, or an interaction pattern used consistently from one page to another. It might be tempting to explore a diverse mix of sophisticated, non-conventional treatments that would be seen in the interface miles away from the mouse cursor. However, that’s a recipe for a disastrous experience that prioritizes a designer’s expression over users’ intentions. However bold the personality is, its design signature should remain subtle.
When working with Dan Mall on the Smashing redesign, one interesting detail Dan brought up at the very start of the project was the role of the signature in the final outcome. According to Dan, choosing a few distinct, competing expressions of the personality is often too much: it’s enough to choose just one little detail and boost it up all the way. In more practical terms, that means picking one pattern and using it consistently, everywhere: on every page, and in every user interaction. How do you find that sacred detail? You go back to the roots of the company.
In the very early days of Smashing Magazine, we didn’t have any branding at all. We chose a pretty random WordPress theme, placed the name in Arial, and that was it. Eventually, in early 2007 Ryan Denzel from South Africa designed Smashing Magazine’s logo, which included a letter S tilted by 11.6 degrees. Despite minor alterations in the shade and colors of the logo, we stayed true to the design for over a decade, and with the recent redesign, we weren’t considering changing it. However, when seeking a design signature that would be deeply connected with the brand, we actually took the tilting of the logo very close to our heart — from the very start.
Early design explorations with Andy Clarke used the tilting consistently for every single visual element on the site. This signature carried over to the final design as well. Today, all icons, author images, conference flags, job board logos, illustrations on product panels, and book covers on product pages are all consistently tilted. That tiny detail doesn’t break the experience, yet it lends a unique visual treatment to the design that’s clearly distinguishable from everything else as a result.
Admittedly, we did redesign the tilting through the process, moving away from 11.6 degrees to 11 degrees, and adding 11px roundness to all components. It was months later that the bold colors and typography and layout came into play, supporting the quirkiness and informal style of the tilted elements — all slowly crawling up into the design mock-ups eventually.
At this point you might be slightly worried that you don’t really have any distinctive element that could be promoted to become your signature. You might not have the tilting or a particular color palette that stands out. As it turns out, anything can become a design signature. In the next sections, we’ll explore some examples and ideas you could use for you own particular situation.
Why Custom Illustrations Work Better Than Stock Photos
Once the qualities of the personality have been identified, the next step is to translate these qualities into a distinct visual language. Initially it happens via color and typography, so when defining the visual style, look out for these qualities in color combinations and type families.
Probably the easiest way to come up with your own design signature is by using custom illustrations designed specifically for the brand. Every artist has their own unique style, and unlike stock images or stock photos that often almost enforce generic appearance into layouts, custom illustrations give a brand a unique voice and tone. You don’t need to go overboard and create dozens of illustrations; just a few would probably do. Think about replacing all the stock photos you’ve purchased with custom illustrations — this should give you a good enough baseline to start with.
Atlassian is a wonderful example of an illustrative style applied thoroughly and beautifully at every touchpoint of the experience. The illustrations are more approachable than stock photos. Notice, however, that they rarely appear on a plain background — they are supported by the color palette and typographic choices that complement the illustration style.
Why are custom illustrations not enough to stand out? Because just like many other attributes on the web, illustrative style also follows trends. Compare Atlassian’s style to Slack’s visual language. Yes, the fine details are different, but the pastel color combinations are similar. The illustrations from these different projects could happily coexist within one single website, and many customers wouldn’t notice a difference.
A distinct visual style requires further attention to other elements on the page, primarily backgrounds, typography, shapes, and layout. Notice how all of these elements play together on Bond. Illustrations aren’t just added to a blank white canvas — they interplay with the background, text colors, and the layout.
Medium uses a collage-like style for all its illustrations on landing pages and help pages. The key is that illustrations are used consistently across pages. They might not make sense to every visitor, but they contribute to the unique visual appearance of the brand.
Health insurance is a very competitive and not particularly friendly nor transparent environment for citizens and business. With custom illustrations, subtle animated GIFs, and straightforward copywriting, Oscar, a newcomer to the industry, appears more approachable and relatable.
WebConf.Asia is a conference website with vivid color combinations and background, and boxy components designed as if they were three-dimensional. This is enough to set the design apart. The visual treatment produces depth, which is used for speakers, talks, and main navigation.
Bandenjager uses slanted shapes and compositions consistently on call-to-action buttons, in the navigation, and even in the quantity selector on the product page. That’s their design signature. Notice how even micro-components such as product labels use the same pattern.
Maru Mori Project uses a tree shape… everywhere, accompanying custom illustrations that highlight the ongoing activities of the foundation.
Storytrail lets its visitors explore cities with an interactive guide, complemented with videos and photos. Every single city has its own signature which is a wavy horizontal line, outlining that city’s most important landmark. The cities differ in the curves of the lines, and the design uses lines as a signature for animations, transitions, and arrangement of items in the layout.
Haufe uses overlapping backgrounds to add more dynamics to the design. The main structure of the grid is derived from the letter H, which is the main character of the company’s identity. All components are laid out on the grid to support that personality trait. A nice play of photos, original compositions, and a variety of geometric backgrounds at once. Haufe’s design system beautifully describes the underlying principle of Haufe’s dynamic grid.
Another way of drawing attention is by adding randomness to your compositions. Rich Cahill’s portfolio contains illustrations split into three vertical parts, randomly offset horizontally and colored with a set of predefined colors. It’s really not that difficult to add a little bit of personality to stand out. It’s a nice example of introducing some chaos in the design language by combining predictable parts of the system in seemingly random, unpredictable ways.
Lynn Fisher also adds some randomness to her portfolio. The layout changes completely between different breakpoints, creating a totally different experience on mobile and desktop devices. Even the favicon changes dynamically as well.
When considering the visual direction of a site, it’s a good idea to consider custom illustration style, backgrounds, typography, and shapes. Establish strong connections between all of these attributes by reusing design decisions, such as the choice of colors and spacing. While doing so, of course, it wouldn’t hurt avoiding predictable options used widely everywhere else. One of the effective ways to achieve this is by keeping tabs on ongoing design trends, then pick the most prevalent one and… smash it to pieces.
Pick A Trend And Smash It To Pieces
When talking about great design, Yves Saint-Laurent, a well-known French fashion designer, once noted that “Fashions fade; style is eternal.” According to Saint-Laurent, to create timeless designs it’s important to take note of trends, yet serve an interpretation of trends through the lens of your own personal style. That’s not what we usually see on the web.
It’s almost ironic that it has become trendy to dislike trends these days, and for good reason: usually their primary purpose is visual embellishment, rather than driving a designer’s intent, and often they don’t add much to the experience beyond friction, confusion, and fancy whistles and bells. No wonder then that designers have started to fight back with “brutalist designs” — websites that aim to exhibit the essence of a website in its unstructured form, exposing the website’s functions to extremes.3
3 It’s worth noting that brutalism in architecture is characterized by unconcerned aesthetics, not intentionally broken aesthetics. When applied to web design, this style often goes along with deliberately broken design conventions and guiding principles.
While doing so, designers often deliberately break design patterns, usability practices, and design trends. At first glance they might appear as designs created with the sole purpose of being different, but because they have a striking personality, they draw attention to themselves. Admittedly, sometimes they seem to be too far-fetched in how they deliberately turn their back on well-established design principles. Not everybody can afford it, and not everybody would feel comfortable connecting such non-conventional aesthetics to their brand.
A slightly more pragmatic strategy, of course, lives somewhere between generic designs and brutalist designs. To get there, you could pick a trend, find a unique perspective and apply your personality to it. For example, if you see many websites using smooth and silky animations, think about how they would fit into your story, and find the twist that would enrich it, and make it more personal. Break down the trend into pieces to understand its mechanics and what’s happening behind the scenes, then twist some parts of it, repackage, and integrate into your design.
Instead of using bouncy animations, you could introduce an artificial delay, effectively slowing down the appearance of items on the page. If most profile images you see have a perfect circular shape, try to come up with another shape that would work well for you to display avatars. If most photos are rectangular, think of another shape that might do the job well.
Instead of using off-canvas transitions, think about a particular kind of transition or animation that would best reflect your brand. For more corporate entities, a fast-paced transition might work best; for creative projects, a slightly more playful and slow transition might be a better fit. Waaark is a wonderful example of the latter. If all transitions were removed, the portfolio website would look pretty much like every other portfolio out there.
Implement Consulting Group uses a short and subtle geometric animation to highlight the featured article on the site. Foreground and background images are a bit offset and animated, with a geometric shape in the background and a story preview in the foreground. That’s enough to give the experience some personality.
Imagine for a second that you have to redesign your ongoing project, but can’t use any basic shapes such as circles, rectangles, or triangles. What would you choose? We all know there is an infinite amount of options, but why is it then that so often we are constrained by highly predictable and heavily used choices? What is neither a circle nor a rectangle nor a triangle? Well, slanted or tilted elements aren’t. Neither are letters and large typography. Nor are custom responsive illustrations or iconography. Nor whitespace, audio, and video. Nor transitions and animations. Nor pretty much any other shape created via a polygon, with content embedded via SVG masks.
District0x is a network of decentralized markets and communities. The site uses custom shapes, smooth transitions, and animations to provide a distinct experience. No rectangles or circles. And notice how well the colors, background images, and typography work together on the site.
It’s not that all basic shapes should be ignored and dismissed from now on, of course. Avoiding basic shapes deliberately is one of the very first exercises we do when we try to come up with a slightly more original art direction. Once you’ve come up with a decent idea without basic shapes, you can start bringing them back sparingly when necessary. Chances are high, however, that you might be able to get away without them altogether.
Do Make People Think
Why is it that when we are puzzling our way around a foreign city and a souvenir shop owner is desperately trying to catch our attention on the street and push a sale, we pass by in haste; yet we slowly walk into a beautifully designed souvenir store that is silent and humble just around the corner? Perhaps it’s because we seek authentic, honest, and respectful experiences, and tend to ignore everything that doesn’t fit the bill. In his fantastic book Blink, Malcolm Gladwell outlined an interesting phenomenon related to how humans value their experiences.
According to Gladwell, we tend to be more satisfied with our experiences when we feel valued, listened to, and understood. Doctors who take a disproportionate amount of time listening, asking questions, and taking notes with their patients tend to get significantly better reviews and higher ratings despite the fact that other doctors might be as proficient and knowledgeable. They might jump to correct conclusions faster, yet their efficiency doesn’t elicit trust and connection in their patients. Of course, primarily we want the problem to be solved, but we also love falling in love with a charming personality, wisdom, expertise, and human kindness.
We know by now that we can enable human connections by embedding compassion into our interfaces. However, these connections don’t just happen overnight — they take time. But where does it leave us in the age of instant gratification and invisible interfaces, when it has become the essence of our job to avoid interruptions and distractions, and create a clear path for customers to follow seamlessly? If we aren’t supposed to make people think, how do we even get a chance to establish an emotional connection in the first place?
We do so by slowing down. Deliberately. By making people think. Not much. Just a little bit. Just enough to make them feel valued, or smile, or get curious. We do so by adding friction. A few bumps here and there, enough to offer a chance of being directly confronted with the personality infused in our interfaces. It might even mean confusing the customer every now and again just to enable a speedy recovery from that confusion with a dash of positive emotion in their eyes. That’s how memorable experiences emerge.
Everything is a little bit off on BAO London — the spacing, the color combinations, the form layout, the hierarchy, the buttons, the cursor, the lightboxes, the illustrations. This consistent breaking of predictable patterns makes the website appear interesting and appealing. Breaking things slowly and deliberately, one component at a time. That’s not a regular restaurant website.
Everything is way off on the Hans Brinker Budget Hostel website, and it’s done deliberately as well. The hostel was struggling to sell rooms as the competition was quite tough in Amsterdam. Rather than improving the design, they made it worse to fit well within their story. If you can’t make it better, make it worse. Even if you don’t have a wonderful product to sell, it’s always possible to wrap a story around it and make it more interesting. Pretty much every element on the page actively makes people confused — from color combination to typography to interactions. It worked though — they are expanding to Lisbon now.
Now, of course, not everybody will like it, and some people will find it annoying, confusing, misleading, childish, or just over the top. Very much like we find it difficult to connect to some people, we might experience the same issue with an interface that attempts to show its human side. But isn’t it worth it? Perhaps in times when everything is remarkably similar and doesn’t really stand for anything, it’s worth striving for our product to be genuinely loved by many people for the price of being genuinely disliked by some people, rather than eliciting no feelings at all.
In his “How I Built This” interview on NPR, Mike Krieger, the co-founder and creative mind behind Instagram, mentioned that rather than spending a significant amount of time trying to understand why people abandoned the service, one of the fundamental principles that drives growth is focusing on customers who deeply love your product and stay around for years. By prioritizing existing customers and what they truly love about your product, you might not only attach them to your product, but also boost the word-of-mouth marketing that’s infinitely more effective than traditional landing pages.
It doesn’t mean, though, that we shouldn’t take good care of experiences customers have when abandoning the product, or — even worse — that we should make it harder for them to leave. The humane qualities of the interface should shine consistently through all the touchpoints of the experience — and it holds true for onboarding as much as offboarding. In fact, the latter is often neglected as it isn’t deemed as being that important — after all, at the point when the customer will face it, they have almost abandoned the product.
Just like human relationships sometimes end abruptly and badly, leaving a lasting negative aftermath, so can our relationships with digital products. It’s highly unlikely that a person abandoning a product with a mysteriously long-winded journey through cancellation redirects would praise the product to friends and colleagues. People leave for very different reasons, and sometimes it has literally nothing to do with the service or the experience. They might have moved on, or just want to save money for something more important, or perhaps they just found an alternative that better fits their needs.
What if at the moment of departure we make them feel deeply valued and understood? Admittedly, with Smashing Magazine’s redesign, we didn’t spend too much time designing the offboarding UX, but it was important for us that the experience fitted well within the overall personality of the interface. When our customers cancel their membership subscription, we greet them with a respectful and even encouraging notice, providing a little gift for sticking around with us for so long, and explaining what happens to their personal data.
The result was surprising: we discovered that customers who cancel the subscription and go through the offboarding UX, sometimes tend to be even more eager to recommend us to their friends and total strangers than some loyal members who stick around for a long time. They just admire how respectfully and thoughtfully we deal with their decision, and that we don’t pull all the shady tricks from the trenches to make it difficult for them to leave.
Make Boring Interesting
It’s difficult to introduce playful elements into an experience which is otherwise very much corporate and formal. However, whenever you are designing a particular interaction, be it as simple as hovering a button, or moving from one section to another, or filling in a form, there is always some room to make the experience slightly more interesting.
For example, out of all the wonderful form elements on a given page, what could be less exciting than a “Title” input? Sometimes appearing alongside radio button counterparts or a dropdown, rigorously asking customers for very personal information about their marital status, without any obvious reason whatsoever. And that’s exactly the moment when we can make it shine beautifully. A great way of creating memorable experiences is adding a bit of surprise at the point where it’s most unexpected. Pick the most boring, unnoticeable part of the experience and try to make it interesting. Now, is there a way to make this interaction more interesting?
When creating a new account on Boden, customers are dazzled with a quite unusual selection of options, ranging from Admiral to Squadron Leader and Baroness. Who hasn’t wanted to be a Squadron Leader at some point in their life? This little design decision elicits smiles, and prompts customers to share this gem with their friends and colleagues. By the way, the list of options is quite lengthy.
Austin Beerworks is just one of many local breweries in the US. When customers enter the site, as always they are prompted with an age check that’s supposed to ensure they are over a certain age limit. Most people — honestly or dishonestly — would click on “Yes” and move on, but if the customer chooses to click on “No,” they embark on a “choose-your-own-adventure” trip to be guided to a video that best describes their personality.
Who doesn’t love disliking a pop-up? However, pop-ups can be made interesting too. Volkshotel uses the most annoyingly delightful pop-up out there, beautifully illustrated as a person holding a sign in front of the website. As the visitors hover over it to close it, the pop-up sneakily moves away a little bit, making it just a tad more difficult to close it. Personally, I wish every single website had a pop-up like that.
Tympanus 3D Room Exhibition doesn’t look particularly exceptional until the visitor chooses to interact with it. When moving from one exhibition detail page to another, rather than just loading another page, the user is moved from one room to another within a 3D space. Unexpected and memorable.
What’s a slightly more common interaction on the web? Forms, in all their different flavors and appearances. In fact, chances are high that you have some sort of a login and password input on your site, and, of course, that’s a pretty boring interaction. Adding a character responding to a user’s input might spice things up a little. As a result, people might spend more time interacting with the form before signing in. That’s better engagement at hand. Darin Senneff’s Yeti character does just that.
The strategy is simple: choose one predictable, boring pattern, study user expectations and… break them mercilessly by adding something unexpected and uplifting to it. Please note that it doesn’t mean breaking usability just for the sake of breaking it; rather, it’s about making a handful of boring elements more interesting by adding some unconventional treatments to their design.
Find A Pain Point And Solve It Well
Can you hear restless voices of skepticism whispering from the corner of the room? Not every corporate setting will sustain a funky custom illustration, a quirky animation, or an unconventional interaction. A striking visual identity might not really fit into your digital presence, custom illustrations might not be within the budget, and you might not want to break customer’s expectations anyway. In these cases, you might want to explore a slightly different route. If you can’t convey your personality through unconventional aesthetics or interaction, an alternative is to convey it through superior problem solving. It means you need to uncover painful moments of interaction — when customers are annoyed or disappointed or confused — on similar sites, and sweep through experimental and seemingly far-fetched solutions to try to trump the experience that your competitors provide. Take on a problem, and tackle it meticulously, head on.
Surprisingly, most of the time these pain points aren’t particular features; it’s the perceived complexity of the interaction and the lack of transparency. Too many form fields; too much time investment; too slow an interaction; too many repeated questions; too many unnecessary requirements. The angle is to find a way to make seemingly complex interactions deceptively easy, hence surpassing expectations.
Sidenote: It goes without saying that solving a particular pain point won’t help much if basics aren’t covered properly. Accessibility, performance, proper visual hierarchy, and responsive behavior are the founding pillars of every experience, and have to be considered first.
SBB Mobile is a Swiss trip planner app that allows customers to check the schedule of trains and purchase train tickets. On its own, it’s a trip planner like every single similar app out there, except for one thing. The app provides a “touch timetable”; customers can define their common destinations and arrange them on a grid. To purchase a ticket from Zurich to Lausanne, for example, it’s enough to draw a line on the grid connecting Zurich and Lausanne and then confirm the selection. Booking tickets has never been that fast and easy. That’s a great example of making a conventionally complex interaction straightforward, especially for people who commute frequently. Also, it’s a unique design signature that nobody else has (yet).
What would it take to provide a remarkable video-playing experience? It might sound as simple as designing a track and a thumb with a few ticks on the track for quick jumps. However, if you study common problems users experience frequently, you’ll find one particular issue that stands out. People tend to pause videos and then continue watching later, yet restoring the state of where things were left off is unnecessarily complex in many video player UIs. In fact, you might encounter people writing down the exact time stamp when they paused the video, just to return to it later on another device — but then again, in most UIs it’s impossible to jump precisely to a particular second, and most of the time you have to guess and tap the position of a thumb on the track correctly. In the same way, jumping back and forward by 30 seconds or even by a few minutes can be remarkably challenging, especially on mobile, as most interfaces aren’t designed around that particular case.
Not only does YouTube provide fully accessible controls for navigation, it also contains a keyframes preview with thumbnails appearing on hover, and navigation via keyboard — and it stores the current state of the video, allowing customers to save a particular time stamp with a unique URL to continue watching later. YouTube also contains many lengthy videos, like documentaries or tutorials, so users can slide up the thumb vertically to adjust the scale of the track and hence jump to the point of interest more precisely. Unfortunately, only a few users know of the feature, and the interaction isn’t particularly self-explanatory, but those who do know of it, use it frequently. One pain point, solved well.
Most academic publications contain dozens of endnotes, footnotes, and references, listed in the order of appearance. If a reader is interested in a particular footnote, they have to jump to the end of the article to read it, and then jump back to continue reading the article. This experience might be a bit too tedious for frequent use, yet it’s the default experience we all are accustomed to.
The Harvard Law Review solves this problem in a different way. References are always located right next to the point where they are mentioned. Every side note and footnote either appears on the sides on larger screens, or displayed inline via an accordion. Once a user has tapped on the footnote, it expands in its entirety, while the footnote turns into a “close” button. A simple problem solved well.
Imagine you want to book a wonderful vacation with your family, but you haven’t picked your dates yet. You have an idea of when you’d like to go, and you have some flexibility regarding the dates for your next vacation. DoHop allows its users to choose a flexible date for traveling; for example, particular months of the year, or a particular season, (winter or fall, perhaps). It then suggests dates and a time span with the best price. And if you have a public holiday weekend coming up in a few weeks, and you’d love to make a plan, RoutePerfect suggests a route based on your preferences. That’s a real problem case solved well. Most traveling websites ask for specific dates for inbound and outbound flights.
Good solutions require time and focus. They require us to really understand what pain points users experience first. Users might not be very good at articulating those paint points, so we developed a simple technique that helps us get to the root of the problem.
We ask testers to complete a particular task on a competitor’s website, and record their session on video, along with a webcam, using the device that they are used to. It could be as easy as finding an item in a catalog, or checking out on a retail store, or finding a particular section in the navigation. Of course, we observe their behavior and ask questions if something appears to be unusual, but too often many things that happen during the sessions go unnoticed — they are just too difficult to spot right away. That’s why we rewatch recorded user sessions in slow motion, often slowing down the playback five or six times.
We look for repeated movements and imprecise hits, as well as negative facial expressions and gestures. More specifically, we search for little moments of despair — fleeting moments of confusion when movements or gestures don’t make any sense: circling around a button or a link over and over again; focusing on a particular interactive element for far too long; selecting the same text a few times in a row and then continuing to navigate without acting on it. The playback sessions usually happen right after the test, so we still have an opportunity to ask questions and validate our assumptions with the tester. Even a few recordings usually provide actionable insights — and it doesn’t require many resources or much investment. It’s also a good idea to examine customer support logs, and ask the support team about common complaints.
Once we’ve identified some issues, we explore solutions that would provide more clarity and ease the interaction, sometimes by designing without any particular visual language in mind. The point is to find an interaction pattern that would be way more superior to the experience customers had on the competitor’s sites. We then produce a digital mock-up and invite the same customers to try to solve the same tasks, along with a new group of testers who haven’t seen both interfaces yet. We measure the time needed to complete an interaction and ask them to choose which interaction they find more straightforward and useful, and why. Surprisingly, faster interactions aren’t necessarily perceived as being faster, and slower interactions aren’t necessarily perceived as being slower. Based on that, we iterate and evolve those prototypes. In many ways, those pain points become the heart of our experience that we tackle first and radiate the entire experience out from. That’s why sometimes, instead of running a test on a competitor’s website, we test our own solutions in the same way.
Good solutions trigger an emotional attachment with or without non-conventional aesthetics or interaction. The more pain points you can address well within your interface, the more likely the difference in experience is to be noticed. Only a few websites make it to customers’ browser toolbars, so think about that one pain point and the one solution that would make them do just that.
Exceeding Expectations By Default
Here’s another question for you: of all the hotel experiences you ever had, which ones are the most memorable? Think about it for a moment. Think about what made them so special and why they are so memorable. It might have been an extraordinary natural backdrop, or remarkably attentive personnel, or a lavish breakfast buffet. Or something entirely different. In fact, for many of us it could have been a pretty average dormitory as much as an exquisite 5-star chalet in the Swiss alps. The environment matters, but it’s not the environment alone that matters.
The reason why these experiences are memorable is because they aren’t average.4 In fact, they are the very opposite of average in *some* way, as *something* was exceptional about them. It’s not necessarily the hotel itself — it’s the timing and the people we happen to spend these experiences with. A good hotel provides a setting that enables wonderful experiences, and so does a good website interface. A *memorable* hotel adds a fine detail to the experience that exceeds our expectations, and it does so without telling us up front. And so do memorable websites.
4 According to Daniel Kahneman’s peak-end rule, we tend to judge experiences largely based on how we felt at its peak (that is, its most intense point) and at its end, rather than on the total sum or average of every moment of the experience. The effect occurs whether the experience is pleasant or unpleasant. Other information aside from the peak and end of the experience is not lost, but it is not used. That means we can tap into very negative and very positive parts of the experience, and tweak them to create an emotional connection.
As Brené Brown, a research professor at the University of Houston, so beautifully expressed in her books on empathy, “good design is a function of empathy, while non-empathic design is self-indulgent and self-centered.” The key, then, is to empathize with customers both in their negative and positive experiences, rather than pushing your own agenda. To our customers, that extra fine attention to a few little details can make all the difference in the world. So we could sprinkle a little bit of human kindness here and there, adding extra value silently, without even mentioning it. That fine detail could be as simple as a custom-designed profile illustration, based on the photo the customer has uploaded. It could be a handwritten thank-you note, signed by the entire team and sent via good ol’ snail mail. It could also be an unexpectedly straightforward resolution of a problem after a mistake has been made.
In an eCommerce setting, it could mean the ability to modify or cancel a finished order within five mins after the successful checkout. On the one side, it could help a customer avoid a time-consuming interaction with the support team; and on the other side, just imagine the look on the customer’s face when they realize that the date of the booking was wrong, yet it’s possible to cancel the booking with a click of a button — without any charges applied.
In the same way, an interface could suggest to a signed-in customer to use a saved coupon code, or inform them about a similar — and hence potentially duplicate — booking made a while back. The personality of the brand shines best in those little moments when it helps customers prevent mistakes. By acting on behalf of the experience rather than business every now and again, the interface makes the customer feel genuinely valued, respected, and helped, and that works much better than any ingenious interface copy ever would.
One way of preventing mistakes is by writing adaptive and helpful error messages. That’s one of the most obvious points of frustration for customers, and it’s remarkable how little effort is put into recovery experience, often falling back to generic and abstract messages. Perhaps they don’t cost a sale but they can damage the long-term perception of the brand. People who experience unrecoverable issues during one of the key interactions on a site tend to not use it in the future at all as they expect the issue to creep out in other interactions too.
Overall, error messages deserve slightly more credit than they are usually given. By nature, they appear at the point where the customer’s progress is blocked. That’s also the point where the customers have to slow down and pay full attention to resolve the problem. That’s quite unusual for the entire spectrum of experiences on a site, and we can use the situation to our advantage to infuse a bit of personality into the experience. Every single time our interfaces fail to meet expectations, we should see it as an opportunity to create a memorable impact in the process of speedy recovery. If we manage to turn an annoyance into the feeling of being valued or understood along the way, we might be heading off on the right track.
One of the very first things I started working on when we embarked on the redesign was filling elaborate spreadsheets with alternate wordings for our checkout error messages. It wasn’t done with the intention to A/B test the “best performing” error message, though; it was done primarily to discover better expressions of the personality through the interface. On their own, error messages don’t really make sense, but they fit well within the story being told throughout the site. Obviously, we try to make it as difficult as possible to make mistakes in the first place, but once an error has occurred, we try to use both adaptive and playful copywriting to address the issue while also raise the occasional smile.
Seek critical pain points that customers often experience on the site by looking into customer support logs and user interviews, and design these experiences with extra care and attention. It goes without saying that a quirky personality won’t help much if the customer isn’t able to solve a problem, so take care of the basics first. Ultimately, it doesn’t take that much effort to turn negative experiences into positive ones — it’s just a matter of having it on your to-do list when designing an interface.
The Two Sides Of Personality
As much as we love sharing our experiences and showing our better side to people around us, we can’t stand that one person spending the entire evening talking about themselves. In our interfaces, every time we add yet another parallax transition or a slow bouncy animation to people who have seen it a dozen times already, we are essentially letting the interface highlight its fanciness without helping the user along the way. Eventually, after a few visits, all those whistles and bells that achieve a strong first impact become annoying as they add too much friction.
Nobody loves self-centered characters, and so a website shouldn’t be self-centered either. The design signature should never take the leading role in the user experience as it’s never the main reason why people access the website. It should be humble and remain in the shadows, noticeable but not obstructing the smooth flow frequent visitors have got used to.
In her brilliant talk on designing animations, Val Head, a designer from Pittsburgh, US, suggested using prominent animations very sparingly, as they should be reserved for very special occasions, while subtle micro-animations could accompany the user all along the way. Val suggests using animation only for key compositions of your story, like sending a marketing campaign, or favoriting an item, or seeing a successful purchasing page, while everything else should remain calm and as normal. With this idea in mind we could think of designing our interfaces with two kinds of interactions: the prominent “showroom” ones, used rarely; and subtle “workhorse” ones, used frequently.
Reserve special visual treatments and interactions for special occasions, but also embed subtle treatments used consistently across the entire site. Twitter, for example, uses an elaborate animation when a user “hearts” a tweet. Facebook displays a confetti animation when you congratulate a friend on their birthday or a wedding. In Smashing’s case, we use vibrant colors and cat illustrations as our showroom signature, while tilting, hover-animations, and shadows beneath them make up our workhorse signature.
We are used to the idea of our designs adjusting to the viewport or network conditions, but it might be worth looking into adjusting the design based on the frequency of usage too. The technique is often called progressive reduction, essentially a dynamic simplification of an interface as users become familiar with it. The idea is simple: identify the major features in your interface, and assign levels to these features. Then, track your user’s usage by monitoring the frequency of use within a certain time period and create proficiency profiles for the user. Based on the current level, you could then adjust components of the interface to reduce hand-holding.
As Allan Grinshtein noticed, it’s worth noting at this point that a user’s proficiency in a given product decays over time without usage (also known as experience decay), so if a user’s frequency of use and usage volume have gone down, then their interface should regress a level or two, depending on how far down their numbers have dropped. This automatic regression is necessary to balance progression; without it, you lose the ability to fully respond to dynamic changes in user behavior, adds Dan Birman in his article.
The more often customers visit the site, the less likely they want to be confronted with anything that would slow them down. Therefore, it might be a good idea to slowly fade out showroom signatures with growing frequency of use, perhaps removing parallax-effects or speeding up transitions for returning users. In the end, it’s all about the choreography: don’t be that person at a dinner party filling the room with an extensive story of their life.
The Signature at the Heart of the Design
The design process is a mythical creature. Everybody somehow manages to come up with their own workflow, tooling, and processes, yet it’s very rare that anybody is really satisfied with it. When it comes to infusing personality into the design, when and where would be the right point to include it in the design process?
In one of her talks from 2014, Patty Toland, a senior UX designer from Filament Group in Boston mentioned the hierarchy of priorities the team uses when designing and building responsive experiences. The main goal of the process is to create the “leanest, fastest-loading, most optimized page.” The main foundation is and has always been a fully accessible experience, in which text, images, data, charts, audio, video, forms and so on are all broadly accessible and function fully in their default form. Applied to the context of the design process, it means meaningful markup and properly defined relationships between components.
With accessible components ready to be served, the next step is taking care of the scale of the design. That’s where the decisions about grid, content size, order, and arrangement, as well as breakpoints, come into play. Often the proportions will be defined using content wireframes: low-fidelity mock-ups with gray boxes; the height of each box in proportion to others defines its weight in the layout. Sometimes we add notes about the personality across the content blocks, and then reflect them when it comes to visual design.
With low-fidelity prototypes in place, the next step for the design is to gain style, with logo, brand colors, custom fonts, transitions, and animations added to the mix. Sometimes this hierarchy will be perfectly mapped in the order we write React components and CSS properties with Sass. Even seemingly unrelated tasks, like BEM naming for classes, will happen in that order as well. The prototypes will gain abstract utility classes first, and more elaborate relationships will be reflected through more specific class names throughout the process. The process establishes a clear separation of responsibilities for modules.
This process seems plausible at first, but it raises a very critical question: what pages to design and prototype first? When we start designing, we design the heart of the experience first: the most critical and impactful part of the experience. More specifically, we try to capture the very essence of the experience by exploring key interactions, then break it down into reusable components, and then radiate outwards from that essence. For an online magazine, it would be reading experience and typography first. For a landing page, it would be the pricing plans and a feature comparison first.
For an ecommerce site it means looking into the components that would make up an extraordinary relevant and useful product page first. That means large image thumbnails, concise copywriting, transparent pricing, exposed ratings and testimonials, psychological anchors, and call-to-action buttons. The visual design decisions made there are then translated to other parts of the interface, specifically forms and labels and error messages in the checkout. Only then, eventually, we reach the category pages and the FAQ pages living on the far outer edges of the experience spectrum. Somewhere in between we explore the front page, but usually we design it late rather than early in the process — at the point when we’ve established a strong identity already, so we use the front page to amplify and explore it prominently, potentially with a bold design that would exhibit the main qualities of the personality.
Remember overarching connections mentioned earlier in the chapter? A critical part of the design process is to connect modules, so they don’t appear as standalone solutions when put together in the interface. When we have enough modules to build the first prototype, we jump into the browser and build mobile-first. It’s in this process that we finally decide on the grid and the layout and the structure, and implement the connections between modules. In fact, for us, the signature is that magical bond that ties things together.
That’s why we start thinking about the signature of the design when we start designing the heart of the experience, and sometimes even before that. Spreadsheets exploring error messages, visual experiments around shapes and colors and type, as well as user interviews help us get there. Eventually, decisions made for the first prototype can be reused for other pages, yet sometimes we need to run the process from the start again — as some pages clearly will be one-offs, such as the landing page or a front page. They will still exhibit relationships to everything else because they are designed and built using the personality traits that have been solidified by this point.
It’s these relationships that would then lay the main foundation of a design system, along with components and examples of the interface in use. Too often style guides show a component in isolation, along with Sass class names and a code snippet, without including how that component should appear and behave in relation to other modules on the page. Examples matter both for designers and developers, and they give a good reason to both visit and keep the design system up to date in the long-term.
We often create user journey maps to understand the flow users go through to accomplish their tasks, and with personality traits in mind, we could even complement them with storyboards, adding some personality highlights at different points of user experience. Besides, in the context of design systems, we could explore not only components in isolation, but also how the design language can use components to slow down or speed up the experience, or provide greater or lesser impact, as well as dynamic and static layout compositions — very much like we do with showroom and workhorse interactions.
You could even print them out and put them as magnets on a storyboard, so designers can freely move them around and thus explore ways of combining predictable components in unpredictable ways. That’s what Andrew Clarke does when embedding art direction and storytelling in his designs — very much like comic strip designers arrange the frames according to narrative dynamics and impact when laying out a comic story.
The design signature lies at the very heart of the design. It’s an strand that connects the components in the interface, and it’s what helps designers stay on track when maintaining or evolving a design language. Deciding on the personality traits first helps drive the direction of the design, and can be just a good enough constraint to dissolve initial intentions and goals into tangible, distinguishable attributes that could eventually become the heart of the experience.
As much as we could get seduced by the charm of a website, in the end, the main purpose of it shouldn’t be self-indulgence. Expressions of the personality of the site enable emotional connections with customers and visitors, and because they are human by their nature, they outline a path to authentic, honest, and respectful interfaces. It’s up to us to figure out how to shape that path and the outcome ahead of us.
Now, it might not be for everybody, and perhaps not every site needs a personality in the first place, or perhaps it should be subtle and express itself in little nuances here and there. I hope that in either of these cases, once flipping over the last page of this book, you’ll have a good enough tool belt of ideas and techniques to create unique and humane experiences — experiences people could fall in love with.
I’d like to express sincere gratitude to Jen Simmons, Rachel Andrew, Andrew Clarke, Dan Mall, Espen Brunborg, and Elliot Jay Stocks for inspiring work, contributions, and help in discussing the idea of art direction on the web, and making the web more diverse and experimental. I’d also like to thank Marko Dugonjić, Alberta Soranzo, Sashka Maximova, Lilia Zinchenko, Stefan Bucher, Benoit Henry, Nils Mielke, Thord D. Hedengren, and Bertrand Lirette for reviewing the chapter, as well as our fantastic community, which has shared techniques and lessons learned from its work for everybody to use. You are truly smashing!
The brand new Smashing Book 6 is now available for pre-order. It contains everything you need to know on how to tackle the new adventures web design and development are bringing along. No theory — just things that worked in practice.
Keeping Node.js Fast: Tools, Techniques, And Tips For Making High-Performance Node.js Servers
David Mark Clements
When it comes to performance, what works in the browser doesn’t necessarily suit Node.js. So, how do we make sure a Node.js implementation is fast and fit for purpose? Let’s walk through a hands-on example.
Node is a very versatile platform, but one of the predominant applications is creating networked processes. We’re going to focus on profiling the most common of these: HTTP web servers.
We’ll need a tool that can blast a server with lots of requests while measuring the performance. For example, we can use AutoCannon:
npm install -g autocannon
Other good HTTP benchmarking tools include Apache Bench (ab) and wrk2, but AutoCannon is written in Node, provides similar (or sometimes greater) load pressure, and is very easy to install on Windows, Linux, and Mac OS X.
After we’ve established a baseline performance measurement, if we decide our process could be faster we’ll need some way to diagnose problems with the process. A great tool for diagnosing various performance issues is Node Clinic, which can also be installed with npm:
npm --install -g clinic
This actually installs a suite of tools. We’ll be using Clinic Doctor and Clinic Flame (a wrapper around 0x) as we go.
Note: For this hands-on example we’ll need Node 8.11.2 or higher.
Our example case is a simple REST server with a single resource: a large JSON payload exposed as a GET route at /seed/v1. The server is an app folder which consists of a package.json file (depending on restify 7.1.0), an index.js file and a util.js file.
This server is representative of the common case of serving client-cached dynamic content. This is achieved with the etagger middleware, which calculates an ETag header for the latest state of the content.
The util.js file provides implementation pieces that would commonly be used in such a scenario, a function to fetch the relevant content from a backend, the etag middleware and a timestamp function that supplies timestamps on a minute-by-minute basis:
require('events').defaultMaxListeners = Infinity
const crypto = require('crypto')
module.exports = () =>
const content = crypto.rng(5000).toString('hex')
const ONE_MINUTE = 60000
var last = Date.now()
function timestamp ()
var now = Date.now()
if (now — last >= ONE_MINUTE) last = now
function etagger ()
var cache =
var afterEventAttached = false
function attachAfterEvent (server)
if (attachAfterEvent === true) return
afterEventAttached = true
server.on('after', (req, res) =>
if (res.statusCode !== 200) return
if (!res._body) return
const key = crypto.createHash('sha512')
const etag = crypto.createHash('sha512')
if (cache[key] !== etag) cache[key] = etag
return function (req, res, next)
const key = crypto.createHash('sha512')
if (key in cache) res.set('Etag', cache[key])
res.set('Cache-Control', 'public, max-age=120')
function fetchContent (url, cb)
if (url !== '/seed/v1') cb(Object.assign(Error('Not Found'), statusCode: 404))
else cb(null, content)
return timestamp, etagger, fetchContent
By no means take this code as an example of best practices! There are multiple code smells in this file, but we’ll locate them as we measure and profile the application.
To get the full source for our starting point, the slow server can be found over here.
In order to profile, we need two terminals, one for starting the application, and the other for load testing it.
In one terminal, within the app, folder we can run:
In another terminal we can profile it like so:
autocannon -c100 localhost:3000/seed/v1
This will open 100 concurrent connections and bombard the server with requests for ten seconds.
The results should be something similar to the following (Running 10s test @ http://localhost:3000/seed/v1 — 100 connections):
231 requests in 10s, 2.4 MB read
Results will vary depending on the machine. However, considering that a “Hello World” Node.js server is easily capable of thirty thousand requests per second on that machine that produced these results, 23 requests per second with an average latency exceeding 3 seconds is dismal.
Discovering The Problem Area
We can diagnose the application with a single command, thanks to Clinic Doctor’s –on-port command. Within the app folder we run:
clinic doctor --on-port=’autocannon -c100 localhost:$PORT/seed/v1’ -- node index.js
This will create an HTML file that will automatically open in our browser when profiling is complete.
The results should look something like the following:
The Doctor is telling us that we have probably had an Event Loop issue.
Along with the message near the top of the UI, we can also see that the Event Loop chart is red, and shows a constantly increasing delay. Before we dig deeper into what this means, let’s first understand the effect the diagnosed issue is having on the other metrics.
We see this correlated in the Memory graph. The solid line in the Memory chart is the Heap Used metric. Any time there’s a spike in CPU we see a fall in the Heap Used line, showing that memory is being deallocated.
Active Handles are unaffected by the Event Loop delay. An active handle is an object that represents either I/O (such as a socket or file handle) or a timer (such as a setInterval). We instructed AutoCannon to open 100 connections (-c100). Active handles stay a consistent count of 103. The other three are handles for STDOUT, STDERR, and the handle for the server itself.
If we click the Recommendations panel at the bottom of the screen, we should see something like the following:
Root cause analysis of serious performance issues can take time. In the case of a live deployed project, it’s worth adding overload protection to servers or services. The idea of overload protection is to monitor event loop delay (among other things), and respond with “503 Service Unavailable” if a threshold is passed. This allows a load balancer to fail over to other instances, or in the worst case means users will have to refresh. The overload-protection module can provide this with minimum overhead for Express, Koa, and Restify. The Hapi framework has a load configuration setting which provides the same protection.
Understanding The Problem Area
As the short explanation in Clinic Doctor explains, if the Event Loop is delayed to the level that we’re observing it’s very likely that one or more functions are “blocking” the Event Loop.
This is why a setTimeout cannot be precise.
For instance, try running the following in a browser’s DevTools or the Node REPL:
setTimeout(console.timeEnd, 100, 'timeout')
let n = 1e7
while (n--) Math.random()
The resulting time measurement will never be 100ms. It will likely be in the range of 150ms to 250ms. The setTimeout scheduled an asynchronous operation (console.timeEnd), but the currently executing code has not yet complete; there are two more lines. The currently executing code is known as the current “tick.” For the tick to complete, Math.random has to be called ten million times. If this takes 100ms, then the total time before the timeout resolves will be 200ms (plus however long it takes the setTimeout function to actually queue the timeout beforehand, usually a couple of milliseconds).
In a server-side context, if an operation in the current tick is taking a long time to complete requests cannot be handled, and data fetching cannot occur because asynchronous code will not be executed until the current tick has completed. This means that computationally expensive code will slow down all interactions with the server. So it’s recommended to split out resource intense work into separate processes and call them from the main server, this will avoid cases where on rarely used but expensive route slows down the performance of other frequently used but inexpensive routes.
The example server has some code that is blocking the Event Loop, so the next step is to locate that code.
One way to quickly identify poorly performing code is to create and analyze a flame graph. A flame graph represents function calls as blocks sitting on top of each other — not over time but in aggregate. The reason it’s called a ‘flame graph’ is because it typically uses an orange to red color scheme, where the redder a block is the “hotter” a function is, meaning, the more it’s likely to be blocking the event loop. Capturing data for a flame graph is conducted through sampling the CPU — meaning that a snapshot of the function that is currently being executed and it’s stack is taken. The heat is determined by the percentage of time during profiling that a given function is at the top of the stack (e.g. the function currently being executed) for each sample. If it’s not the last function to ever be called within that stack, then it’s likely to be blocking the event loop.
Let’s use clinic flame to generate a flame graph of the example application:
The result should open in our browser with something like the following:
From the outset, we can infer that the offending code is in the util.js file of the application code.
The slow function is also an event handler: the functions leading up to the function are part of the core events module, and server.on is a fallback name for an anonymous function provided as an event handling function. We can also see that this code isn’t in the same tick as code that actually handles the request. If there were functions in the core, http, net, and stream would be in the stack.
Such core functions can be found by expanding other, much smaller, parts of the flame graph. For instance, try using the search input on the top right of the UI to search for send (the name of both restify and http internal methods). It should be on the right of the graph (functions are alphabetically sorted):
Notice how comparatively small all the actual HTTP handling blocks are.
We can click one of the blocks highlighted in cyan which will expand to show functions like writeHead and write in the http_outgoing.js file (part of Node core http library):
We can click all stacks to return to the main view.
The key point here is that even though the server.on function isn’t in the same tick as the actual request handling code, it’s still affecting the overall server performance by delaying the execution of otherwise performant code.
We know from the flame graph that the problematic function is the event handler passed to server.on in the util.js file.
It’s well known that cryptography tends to be expensive, as does serialization (JSON.stringify) but why don’t they appear in the flame graph? These operations are in the captured samples, but they’re hidden behind the cpp filter. If we press the cpp button we should see something like the following:
Once we start to reason about the code in the etagger function it can quickly become apparent that it’s poorly designed. Why are we taking the server instance from the function context? There’s a lot of hashing going on, is all of that necessary? There’s also no If-None-Match header support in the implementation which would mitigate some of the load in some real-world scenarios because clients would only make a head request to determine freshness.
Let’s ignore all of these points for the moment and validate the finding that the actual work being performed in server.on is indeed the bottleneck. This can be achieved by setting the server.on code to an empty function and generating a new flamegraph.
Alter the etagger function to the following:
function etagger ()
var cache =
var afterEventAttached = false
function attachAfterEvent (server)
if (attachAfterEvent === true) return
afterEventAttached = true
server.on('after', (req, res) => )
return function (req, res, next)
const key = crypto.createHash('sha512')
if (key in cache) res.set('Etag', cache[key])
res.set('Cache-Control', 'public, max-age=120')
The event listener function passed to server.on is now a no-op.
This should produce a flame graph similar to the following:
This looks better, and we should have noticed an increase in request per second. But why is the event emitting code so hot? We would expect at this point for the HTTP processing code to take up the majority of CPU time, there’s nothing executing at all in the server.on event.
This type of bottleneck is caused by a function being executed more than it should be.
The following suspicious code at the top of util.js may be a clue:
require('events').defaultMaxListeners = Infinity
Let’s remove this line and start our process with the --trace-warnings flag:
node --trace-warnings index.js
If we profile with AutoCannon in another terminal, like so:
autocannon -c100 localhost:3000/seed/v1
Our process will output something similar to:
(node:96371) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 after listeners added. Use emitter.setMaxListeners() to increase limit
at _addListener (events.js:280:19)
at Server.addListener (events.js:297:10)
Node is telling us that lots of events are being attached to the server object. This is strange because there’s a boolean that checks if the event has been attached and then returns early essentially making attachAfterEvent a no-op after the first event is attached.
Let’s take a look at the attachAfterEvent function:
var afterEventAttached = false
function attachAfterEvent (server)
if (attachAfterEvent === true) return
afterEventAttached = true
server.on('after', (req, res) => )
The conditional check is wrong! It checks whether attachAfterEvent is true instead of afterEventAttached. This means a new event is being attached to the server instance on every request, and then all prior attached events are being fired after each request. Whoops!
Now that we’ve discovered the problem areas, let’s see if we can make the server faster.
Let’s put the server.on listener code back (instead of an empty function) and use the correct boolean name in the conditional check. Our etagger function looks as follows:
function etagger ()
var cache =
var afterEventAttached = false
function attachAfterEvent (server)
if (afterEventAttached === true) return
afterEventAttached = true
server.on('after', (req, res) =>
if (res.statusCode !== 200) return
if (!res._body) return
const key = crypto.createHash('sha512')
const etag = crypto.createHash('sha512')
if (cache[key] !== etag) cache[key] = etag
return function (req, res, next)
const key = crypto.createHash('sha512')
if (key in cache) res.set('Etag', cache[key])
res.set('Cache-Control', 'public, max-age=120')
Now we check our fix by profiling again. Start the server in one terminal:
Then profile with AutoCannon:
autocannon -c100 localhost:3000/seed/v1
We should see results somewhere in the range of a 200 times improvement (Running 10s test @ http://localhost:3000/seed/v1 — 100 connections):
50k requests in 10s, 519.64 MB read
It’s important to balance potential server cost reductions with development costs. We need to define, in our own situational contexts, how far we need to go in optimizing a project. Otherwise, it can be all too easy to put 80% of the effort into 20% of the speed enhancements. Do the constraints of the project justify this?
In some scenarios, it could be appropriate to achieve a 200 times improvement with a low hanging fruit and call it a day. In others, we may want to make our implementation as fast as it can possibly be. It really depends on project priorities.
One way to control resource spend is to set a goal. For instance, 10 times improvement, or 4000 requests per second. Basing this on business needs makes the most sense. For instance, if server costs are 100% over budget, we can set a goal of 2x improvement.
Taking It Further
If we produce a new flame graph of our server, we should see something similar to the following:
The event listener is still the bottleneck, it’s still taking up one-third of CPU time during profiling (the width is about one third the whole graph).
What additional gains can be made, and are the changes (along with their associated disruption) worth making?
With an optimized implementation, which is nonetheless slightly more constrained, the following performance characteristics can be achieved (Running 10s test @ http://localhost:3000/seed/v1 — 10 connections):
92k requests in 11s, 937.22 MB read
While a 1.6x improvement is significant, it arguable depends on the situation whether the effort, changes, and code disruption necessary to create this improvement are justified. Especially when compared to the 200x improvement on the original implementation with a single bug fix.
To achieve this improvement, the same iterative technique of profile, generate flamegraph, analyze, debug, and optimize was used to arrive at the final optimized server, the code for which can be found here.
These changes are slightly more involved, a little more disruptive to the code base, and leave the etagger middleware a little less flexible because it puts the burden on the route to provide the Etag value. But it achieves an extra 3000 requests per second on the profiling machine.
Let’s take a look at a flame graph for these final improvements:
The hottest part of the flame graph is part of Node core, in the net module. This is ideal.
Preventing Performance Problems
To round off, here are some suggestions on ways to prevent performance issues in before they are deployed.
Using performance tools as informal checkpoints during development can filter out performance bugs before they make it into production. Making AutoCannon and Clinic (or equivalents) part of everyday development tooling is recommended.
When buying into a framework, find out what it’s policy on performance is. If the framework does not prioritize performance, then it’s important to check whether that aligns with infrastructural practices and business goals. For instance, Restify has clearly (since the release of version 7) invested in enhancing the library’s performance. However, if low cost and high speed is an absolute priority, consider Fastify which has been measured as 17% faster by a Restify contributor.
Watch out for other widely impacting library choices — especially consider logging. As developers fix issues, they may decide to add additional log output to help debug related problems in the future. If an unperformant logger is used, this can strangle performance over time after the fashion of the boiling frog fable. The pino logger is the fastest newline delimited JSON logger available for Node.js.
Finally, always remember that the Event Loop is a shared resource. A Node.js server is ultimately constrained by the slowest logic in the hottest path.
Customer acquisition is all about convincing people to buy your products or service. That’s it. But it’s more complicated than you might think. You have to understand your customers’ buyers journeys and how they make the decision to buy (or to not buy). You might have heard that old adage about how much less expensive it is to retain customers than to acquire them. In fact, it’s about five times less expensive. That statistic sounds powerful, but it leaves an important element out of the equation. To retain customers, you first must acquire them. If you already have 10 million…
Conversion rate optimization offers one of the fastest, most effective methodologies for turning your existing web traffic into paying customers. Also known as CRO, conversion rate optimization can involve numerous tools and strategies, but they’re all geared toward the same thing: Converting visitors into leads and leads into customers. There is a lot of conflicting and illuminating information out there about CRO. For instance, one study found that using long-form landing pages increased conversions by 220 percent. However, some companies find that short-form landing pages work better for their audiences. Similarly, about 75 percent of businesses who responded to another…
FAST UX Research: An Easier Way To Engage Stakeholders And Speed Up The Research Process
Today, UX research has earned wide recognition as an essential part of product and service design. However, UX professionals still seem to be facing two big problems when it comes to UX research: A lack of engagement from the team and stakeholders as well as the pressure to constantly reduce the time for research.
In this article, I’ll take a closer look at each of these challenges and propose a new approach known as ‘FAST UX’ in order to solve them. This is a simple but powerful tool that you can use to speed up UX research and turn stakeholders into active champions of the process.
Contrary to what you might think, speeding up the research process (in both the short and long term) requires effective collaboration, rather than you going away and soldiering on by yourself.
The acronym FAST (Focus, Attend, Summarise, Translate) wraps up a number of techniques and ideas that make the UX process more transparent, fun, and collaborative. I also describe a 5-day project with a central UK government department that shows you how the model can be put into practice.
The article is relevant for UX professionals and the people who work with them, including product owners, engineers, business analysts, scrum masters, marketing and sales professionals.
1. Lack Of Engagement Of The Team And Stakeholders
“Stakeholders have the capacity for being your worst nightmare and your best collaborator.”
Anyone who has tried to do this knows that it can be extremely difficult to organize and get stakeholders to participate in research. There are two main reasons for this:
Research is somebody else’s job. In my experience, UX professionals are often hired to “do the UX” for a company or organization. Even though the title of “Lead UX Researcher” sounds great and very important in my head, it often leads to misconceptions during kick-off meetings. Everyone automatically assumes that research is solely MY responsibility. It’s no wonder that stakeholders don’t want to get involved in the project. They assume research is my and nobody else’s job.
UX process frameworks are incomplete. The problem is that even when stakeholders want to engage and participate in UX, they still do not know *how* they should get involved and *what* they should do. We spend a lot of time selling a UX process and research frameworks that are useful but ultimately incomplete — they do not explain how non-researchers can get involved in the research process.
Further, a lot of stakeholders can find words such as ‘design,’ ‘analysis’ or ‘fieldwork’ intimidating or irrelevant to what they do. In fact, “UX is rife with jargon that can be off-putting to people from other fields.” In some situations, terms are familiar but mean something completely different, e.g., research in UX versus marketing research.
2. Pressure To Constantly Reduce The Time For Research
Another issue is that there is a constantly growing pressure to speed up the UX process and reduce the time spent on research. I cannot count the number of times when a project manager asked me to shorten a study even further by skipping the analysis stage or the kick-off sessions.
While previously you could spend weeks on research, a 5-day research cycle is increasingly becoming the norm. In fact, the book Sprint describes how research can dwindle to just a day (from an overall 5-day cycle).
Considering this, there is a LOT of pressure on UX researchers to deliver fast, without compromising the quality of the study. The difficulty increases when there are multiple stakeholders, each with their own opinions, demands, views, assumptions, and priorities.
The Fast UX Approach
Contrary to what you might think, reducing the time it takes to do UX research does not mean that you need to soldier on by yourself. I have done this and it only works in the short term. It does not matter how amazing the findings are — there is not enough PowerPoint slides in the world to convince a team of the urgency to take action if they have not been on the research journey themselves.
In the long term, the more actively engaged your team and stakeholders are in the research, the more empowered they will feel and the more willing they will be to take action. Productive collaboration also means that you can move together at a quicker pace and speed up the whole research process.
The FAST UX Research framework (see Fig. 2 below) is a tool to truly engage team members and stakeholders in a way that turns them into active advocates and champions of the research process. It shows non-researchers when and how they should get involved in UX Research.
In essence, stakeholders take ownership of each of the UX research stages by carrying out the four activities, each corresponding to its research stage.
Working together reduces the time it takes for UX Research. The true benefit of the approach, however, is that, in the long term, it takes less and less time for the business to take action based on research findings as people become true advocates of user-centricity and the research process.
This approach can be applied to any qualitative research method and with any team. For example, you can carry out FAST usability testing, FAST interviews, FAST ethnography, and so on. In order to be effective, you will need to explain this approach to your stakeholders from the start. Talk them through the framework, explaining each stage. Emphasize that this is what EVERYONE does, that it’s their work as much as the UX researcher’s job, and that it’s only successful if everyone is involved throughout the process.
Stage 1: Focus (Define A Common Goal)
There is a uniform consensus within UX that a research project should start by defining its purpose: why is this research done and how will the results be acted upon?
Generally, this is expressed within the research goals, objectives, research questions and/or hypotheses. Most projects start with a kick-off meeting where those are either discussed (based on an available brief) or are defined during the meeting.
The most regular problem with kick-off sessions like these is that stakeholders come up with too many things they want to learn from a study. The way to turn the situation around is to assign a specific task to your immediate team (other UX professionals you work with) and stakeholders (key decision makers): they will help focus the study from the beginning.
The way they will do that is by working together through the following steps:
Identify as a group the current challenges and problems.
Ask someone to take notes on a shared document; alternatively, ask everyone to participate and write on sticky notes which are then displayed on a “project wall” for everyone to see.
Identify the potential objectives and questions for a research study.
Do this the same way you did the previous step. You don’t need to commit to anything yet.
Ask the team to order the objectives and questions, starting with the most important ones.
Reword and rephrase.
Look at the top 3 questions and objectives. Are they too broad or narrow? Could they be reworded so it’s clearer what is the focus of the study? Are they feasible? Do you need to split or merge objectives and questions?
Commit to be flexible.
Agree on the top 1-2 objectives and ensure that you have agreement from everyone that this is what you will focus on.
Here are some questions you can ask to help your stakeholders and team to get to the focus of the study faster:
From the objectives we have recognized, what is most important?
What does success look like?
If we only learn one thing, which one would be the most important one?
Your role during the process is to provide expertise to determine if:
The identified objectives and questions are feasible for a single study;
Help with the wording of objectives and questions;
Design the study (including selecting a methodology) after the focus has been identified.
At first sight, the Focus and Attend (next stages) activities might be familiar as you are already carrying out a kick-off meeting and inviting stakeholders to attend research sessions.
However, adopting a FAST approach means that your stakeholders have as much ownership as you do during the research process because work is shared and co-owned. Reiterate that the process is collaborative and at the end of the session, emphasize that agreeing on clear research objectives is not easy. Remind everybody that having a shared focus is already better than what many teams start with.
Finally, remind the team and your stakeholders what they need to do during the rest of the process.
Stage 2: Attend (Immerse The Team Deeply In The Research Process)
What often happens is that observers join in on the day of the research study and then they spend the time plastered to their laptops and mobile phones. What is worse, some stakeholders often talk to the note-taker and distract the rest of the design team who need to observe the sessions.
This is why it is just as important that you get the team to interact with the research. The following activities allow the team to immerse themselves in the research session. You can ask stakeholders to:
Ask questions during the session through a dedicated live chat (e.g. Slack, Google Hangouts, Skype);
Take notes on sticky notes;
Summarize observations for everyone (see next stage).
Assign one person per session for each of these activities. Have one “live chat manager,” one “note-taker,” and one “observer” who will sum up the session afterwards.
Rotate people for the next session.
Before the session, it’s useful to walk observers through the ‘ground rules’ very briefly. You can have a poster similar to the one GDS developed that will help you do this and remind the team of their role during the study (see Fig. 3 above).
Farrell (2017) provides more detail on effective ways for stakeholders to take notes together. When you have multiple stakeholders and it’s not feasible for them to physically attend a field visit (e.g. on the street, in an office, at the home of the participant), you could stream the session to an observation room.
Stage 3: Summarize (Analysis For Non-Researchers)
I am a strong supporter of the idea that analysis starts the moment fieldwork begins. During the very first research session, you start looking for patterns and interpretation of what the data you have means.
Even after the first session (but typically towards the end of fieldwork) you can carry out collaborative analysis: a fun and productive way that ensures that you have everyone participating in one of the most important stages of research.
The collaborative analysis session is an activity where you provide an opportunity for everyone to be heard and create a shared understanding of the research.
Since you’re including other experts’ perspectives, you’re increasing the chances to identify more objective and relevant insights, and also for stakeholders to act upon the results of the study.
Even though ‘analysis’ is an essential part of any research project, a lot of stakeholders get scared by the word. The activity sounds very academic and complex. This is why at the end of each research session, research day, or the study as a whole, the role of your stakeholders and immediate team is to summarize their observations. Summarizing may sound superfluous but is an important part of the analysis stage; this is essentially what we do during “Downloading” sessions.
Listening to someone’s summary provides you with an opportunity to understand:
What they paid attention to;
What is important for them;
Their interpretation of the event.
Summary At The End Of Each Session
You do this by reminding everyone at the beginning of the session that at the end you will enter the room and ask them to summarize their observations and recommendations.
You then end the session by asking each stakeholder the following:
What were their key observations (see also Fig. 3)?
What happened during the session?
Were there any major difficulties for the participant?
What were the things that worked well?
Was there anything that surprised them?
This will make the team more attentive during the session, as they know that they will need to sum it up at the end. It will also help them to internalize the observations (and later, transition more easily to findings).
This is also the time to consistently share with your team what you think stands out from the study so far. Avoid the temptation to do a ‘big reveal’ at the end. It’s better if outcomes are told to stakeholders many times.
On multiple occasions, research has given me great outcomes. Instead of sharing them regularly, I keep them to myself until the final report. It doesn’t work well. A big reveal at the end leads to bewildered stakeholders who often cannot jump from observations to insights as quickly. As a result, there is either stubborn pushback or indifferent shrugs.
Summary At The End Of The Day
A summary of the event or the day can then naturally transition into a collaborative analysis session. Your job is to moderate the session.
The job of your stakeholders is to summarize the events of the day and the final results. Ask a volunteer to talk the group through what happened during the day. Other stakeholders can then add to these observations.
Summary At The End Of The Study
After the analysis is done, ask one or two stakeholders to summarize the study. Make sure they cover why we did research, what happened during the study and what are the primary findings. They can also do this by walking through the project wall (if you have one).
It’s very difficult not to talk about your research and leave someone else to do it. But it’s worth it. No matter how much you’re itching to do this yourself — don’t! It’s a great opportunity for people to internalize research and become comfortable with the process. This is one of the key moments to turn stakeholders into active advocates of user research.
At the end of this stage, you should have 5-7 findings that capture the study.
Stage 4: Translate (Make Stakeholders Active Champions Of The Solution)
“Research doesn’t have a value unless it results in decisions and actions.”
—Lang and Howell (2017).
Even when you agree with the findings, stakeholders might still disagree about what the research means or lack commitment to take further action. This is why after summarizing, ask your stakeholders to work with you and identify the “Now what?” or what it all means for the organization, product, service, team and/or individually for each one of them.
Traditionally, it was the UX researchers’ job to write clear, precise, descriptive findings, and actionable recommendations. However, if the team and stakeholders are not part of identifying actionable recommendations, they might be resistant towards change in future.
To prevent later pushback, ask stakeholders to identify the “Now what?” (also referred to as ‘actionable recommendations’). Together, you’ll be able to identify how the insights and findings will:
Affect the business and what needs to be done now;
Affect the product/service and what changes do we need to make;
Affect people individually and the actions they need to take;
Lead to potential problems and challenges and their solutions;
Help solve problems or identify potential solutions.
Stakeholders and the team can translate the findings at the end of a collaborative analysis session.
If you decide to separate the activities and conduct a meeting in which the only focus is on actionable recommendations, then consider the following format:
Briefly talk through the 5-7 main findings from the study (as a refresher if this stage is done separately from the analysis session or with other stakeholders).
Split the group into teams and ask them to work on one finding/problem at a time.
Ask them to list as many ways they see the finding affecting them.
Ask one person from each group to present the findings back to the team.
Ask one/two final stakeholders to summarize the whole study, together with the methods, findings, and recommendations.
Later, you can have multiple similar workshops; this is how you get to engage different departments from the organization.
Fast UX In Practice
An excellent example of a FAST UX Research approach in practice is a project I was hired to carry out for a central UK government department. The ultimate goal of the project was to identify user requirements for a very complex internal system.
At first sight, this was a very challenging project because:
There was no time to get to know the department or the client.
Usually, I would have at least a week or two to get to know the client, their needs, opinions, internal pressures, and challenges. For this project, I had to start work on Monday with a team I had never met; in a building I had never worked, in a domain I knew little about, and finish on Friday the same week.
The system was very complex and required intense research.
The internal system and the nature of work were very complex; this required gathering data with at least a few research methods (for triangulation).
This was the first time the team had worked with a UX Researcher.
The stakeholders were primarily IT specialists. However, I was lucky that they were very keen and enthusiastic to be involved in the project and get their hands dirty.
As is the case on many other projects, all stakeholders were extremely busy as they had their own work on top of the project. Nonetheless, we made it work, even if it meant meeting over lunch, or for a 15-minute wrap up before we went home.
There were internal pressures and challenges.
As with any department and huge organization, there were a number of internal pressures and challenges. Some of them I expected (e.g. legacy systems, slow pace of change) but some I had no clue about when I started.
We had to coordinate work with external teams.
An additional challenge was the need to work with and coordinate efforts with external teams at another UK department.
Despite all of these challenges, this was one of the most enjoyable projects I have worked on because of the tight collaboration initiated by the FAST approach.
The project consisted of:
1 day of kick-off sessions and getting to know the team
2,5 days of contextual inquiries and shadowing of internal team members,
Half a day for a co-creation workshop, and
1 day for analysis and results reporting.
In the process, I gathered data from 20+ employees, had 16+ hours of observations, 300+ photos and about 100 pages of notes. Here is a great example of cramming in 3 weeks’ worth of work into a mere 5-day research cycle. More importantly, people in the department were really excited about the process.
Here is how we did it using a FAST UX Research approach:
Focus At the beginning of the project, the two key stakeholders identified what the focus of research would be while my role was mainly to help with prioritizing the objectives, tweak the research questions and check for feasibility. In this sense, I listened and mainly asked questions, interjecting occasionally with examples from previous projects or options that helped to adjust our approach.
While I wrote the main discussion guide for the contextual inquiries and shadowing sessions, we sat together with the primary team to discuss and design the co-creation workshop with internal users of the system.
Attend During the workshop one of the stakeholders moderated half of the session, while the other took notes and observed closely the participants. It was a huge success internally, as stakeholders felt there was better visibility for their efforts to modernize the department, while employees felt listened to and involved in the research.
Summarize Immediately after the workshop, we sat together with the stakeholders for a 30-minute meeting where I had them summarize their observations.
As a result of the shadowing, contextual inquiries and co-creation workshop, we were able to identify 60+ issues and problems with the internal system (with regards to integration, functionality, and usability), all captured in six high-level findings.
Translate Later, we discussed with the team how each of the six major findings translated to a change or implication for the department, the internal system, as well as collaboration with other departments.
We were so perfectly aligned with the team that when we had to talk about our work in front of another UK government department, I could let the stakeholders talk about the process and our progress.
My final task (over two additional days) was to document all of the findings in a research report. This was necessary as a knowledge repository because I had to move onto other projects.
With a more traditional approach, the project could have easily spanned 3 weeks. More importantly, quickly understanding individual and team pressures and challenges were the keys to the success of the new system. This could not have happened within the allocated time without a collaborative approach.
A FAST UX approach resulted in tight collaboration, strong co-ownership and a shared sense of progress; all of those allowed to shorten the time of the project, but also to instill a feeling of excitement about the UX research process.
Have You Tried It Out Already?
While UX research becomes ever more popular, gone are the days when we could soldier on by ourselves and only consult stakeholders at the end.
Mastering our craft as UX researchers means engaging others within the process and being articulate, clear, and transparent about our work. The FAST approach is a simple model that shows how to engage non-researchers with the research process. Reducing the time it takes to do research, both in the short (i.e. the study itself) and long term (i.e. using the research results), is a strategic advantage for the researcher, team, and the business as a whole.
Would you like to improve your efficiency and turn stakeholders into user research advocates? Go and try it out. You can then share your stories and advice here.
I would love to hear your comments, suggestion and any feedback you care to share! If you have tried it out already, do you have success stories you want to share? Be as open as you can — what worked well, and what didn’t? As with all other things UX, it’s most fun if we learn together as a team.
How To Improve Your Design Process With Data-Based Personas
Most design and product teams have some type of persona document. Theoretically, personas help us better understand our users and meet their needs. The idea is that codifying what we’ve learned about distinct groups of users helps us make better design decisions. Referring to these documents ourselves and sharing them with non-design team members and external stakeholders should ultimately lead to a user experience more closely aligned with what real users actually need.
In reality, personas rarely prove equal to these expectations. On many teams, persona documents sit abandoned on hard drives, collecting digital dust while designers continue to create products based primarily on whim and intuition.
In contrast, well-researched personas serve as a proxy for the user. They help us check our work and ensure that we’re building things users really need.
In fact, the best personas don’t just describe users; they actually help designers predict their behavior. In her article on persona creation, Laura Klein describes it perfectly:
“If you can create a predictive persona, it means you truly know not just what your users are like, but the exact factors that make it likely that a person will become and remain a happy customer.”
In other words, useful personas actually help design teams make better decisions because they can predict with some accuracy how users will respond to potential product changes.
Obviously, for personas to facilitate these types of predictions, they need to be based on more than intuition and anecdotes. They need to be data-driven.
So, what do data-driven personas look like, and how do you make one?
Start With What You Think You Know
The first step in creating data-driven personas is similar to the typical persona creation process. Write down your team’s hypotheses about what the key user groups are and what’s important to each group.
If your team is like most, some members will disagree with others about which groups are important, the particular makeup and qualities of each persona, and so on. This type of disagreement is healthy, but unlike the usual persona creation process you may be used to, you’re not going to get bogged down here.
Instead of debating the merits of each persona (and the various facets and permutations thereof), the important thing is to be specific about the different hypotheses you and your team have and write them down. You’re going to validate these hypotheses later, so it’s okay if your team disagrees at this stage. You may choose to focus on a few particular personas, but make sure to keep a backlog of other ideas as well.
I recommend aiming for a short, 1–2 sentence description of each hypothetical persona that details who they are, what root problem they hope to solve by using your product, and any other pertinent details.
You can use the traditional user stories framework for this. If you were creating hypothetical personas for Craigslist, one of these statements might read:
“As a recent college grad, I want to find cheap furniture so I can furnish my new apartment.”
Another might say:
“As a homeowner with an extra bedroom, I want to find a responsible tenant to rent this space to so I can earn some extra income.”
If you have existing data — things like user feedback emails, NPS scores, user interview notes, or analytics data — be sure to go over them and include relevant data points in your notes along with your user stories.
Validate And Refine
The next step is to validate and refine these hypotheses with user interviews. For each of your hypothetical personas, you’ll want to start by interviewing 5 to 10 people who fit that group.
You have three key goals for these interviews. For each group, you need to:
Understand the context in which they need to solve the problem.
Confirm that members of the persona group agree that the problem you recorded is an urgent and painful one that they struggle to solve now.
Identify key predictors of whether a member of this persona is likely to become and remain an active user.
The approach you take to these interviews may vary, but I recommend a hybrid approach between a traditional user interview, which is very non-leading, and a Lean Problem interview, which is deliberately leading.
“Tell me about the last time you purchased furniture. What did you buy? Where did you buy it?”
These types of questions are great for establishing whether the interviewee recently experienced the problem in question, how they solved it, and whether they’re dissatisfied with their current solution.
Once you’ve finished asking these types of questions, move on to the Lean Problem portion of the interview. In this section, you want to tell a story about a time when you experienced the problem — establishing the various issues you struggled with and why it was frustrating — and see how they respond.
You might say something like this:
“When I graduated college, I had to get new furniture because I wasn’t living in the dorm anymore. I spent forever looking at furniture stores, but they were all either ridiculously expensive or big-box stores with super-cheap furniture I knew would break in a few weeks. I really wanted to find good furniture at a reasonable price, but I couldn’t find anything and I eventually just bought the cheap stuff. It inevitably broke, and I had to spend even more money, which I couldn’t really afford. Does any of that resonate with you?”
What you’re looking for here is emphatic agreement. If your interviewee says “yes, that resonates” but doesn’t get much more excited than they were during the rest of the interview, the problem probably wasn’t that painful for them.
On the other hand, if they get excited, empathize with your story, or give their own anecdote about the problem, you know you’ve found a problem they really care about and need to be solved.
Finally, make sure to ask any demographic questions you didn’t cover earlier, especially those around key attributes you think might be significant predictors of whether somebody will become and remain a user. For example, you might think that recent college grads who get high-paying jobs aren’t likely to become users because they can afford to buy furniture at retail; if so, be sure to ask about income.
You’re looking for predictable patterns. If you bring in 5 members of your persona and 4 of them have the problem you’re trying to solve and desperately want a solution, you’ve probably identified a key persona.
On the other hand, if you’re getting inconsistent results, you likely need to refine your hypothetical persona and repeat this process, using what you learn in your interviews to form new hypotheses to test. If you can’t consistently find users who have the problem you want to solve, it’s going to be nearly impossible to get millions of them to use your product. So don’t skimp on this step.
Create Your Personas
The penultimate step in this process is creating the actual personas themselves. This is where things get interesting. Unlike traditional personas, which are typically static, your data-driven personas will be living, breathing documents.
The goal here is to combine the lessons you learned in the previous step — about who the user is and what they need — with data that shows how well the latest iteration of your product is serving their needs.
At my company Swish, each one of our personas includes two sections with the following data:
Predictive User Data
Product Performance Data
Description of the user including predictive demographics.
The percentage of our current user base the persona represents.
It may take some time for your team to produce all this information, but it’s okay to start with what you have and improve the personas over time. Your personas won’t be sitting on a shelf. Every time you release a new feature or change an existing one, you should measure the results and update your personas accordingly.
Integrate Your Personas Into Your Workflow
Now that you’ve created your personas, it’s time to actually use them in your day-to-day design process. Here are 4 opportunities to use your new data-driven personas:
At Standups At Swish, our standups are a bit different. We start these meetings by reviewing the activation, retention, and referral metrics for each persona. This ensures that — as we discuss yesterday’s progress and today’s obstacles — we remain focused on what really matters: how well we’re serving our users.
During Prioritization Your data-driven personas are a great way to keep team members honest as you discuss new features and changes. When you know how much of your user base the persona represents and how well you’re serving them, it quickly becomes obvious whether a potential feature could actually make a difference. Suddenly deciding what to work on won’t require hours of debate or horse-trading.
At Design Reviews Your data-driven personas are a great way to keep team members honest as you discuss new designs. When team members can creditably represent users with actual quotes from user interviews, their feedback quickly becomes less subjective and more useful.
When Onboarding New Team Members New hires inevitably bring a host of implicit biases and assumptions about the user with them when they start. By including your data-driven personas in their onboarding documents, you can get new team members up to speed much more quickly and ensure they understand the hard-earned lessons your team learned along the way.
Keeping Your Personas Up To Date
It’s vitally important to keep your personas up-to-date so your team members can continue to rely on them to guide their design thinking.
As your product improves, it’s simple to update NPS scores and performance data. I recommend doing this monthly at a minimum; if you’re working on an early-stage, rapidly-changing product, you’ll get better mileage by updating these stats weekly instead.
It’s also important to check in with members of your personas periodically to make sure your predictive data stays relevant. As your product evolves and the competitive landscape changes, your users’ views about their problems will change as well. If your growth starts to plateau, another round of interviews may help to unlock insights you didn’t find the first time. Even if everything is going well, try to check in with members of your personas — both current users of your product and some non-users — every 6 to 12 months.
Building data-driven personas is a challenging project that takes time and dedication. You won’t uncover the insights you need or build the conviction necessary to unify your team with a week-long throwaway project.
But if you put in the time and effort necessary, the results will speak for themselves. Having the type of clarity that data-driven personas provide makes it far easier to iterate quickly, improve your user experience, and build a product your users love.
If you’re interested in learning more, I highly recommend checking out the linked articles above, as well as the following resources: