Iconography In Design Systems: Easy Troubleshooting And Maintenance

We all have an inherent tendency to like aesthetic and approachable things. That’s why any designer strives to deliver an intuitive and comprehensive design. And any designer knows it’s a pain in the neck, particularly when it comes to complex projects with lots of pages of design, components, and prototypes. As someone who has already traveled that road and learned quite a few valuable lessons, I have some wisdom to share with you.

Granted, tons of articles have been written about design systems, their complexity, and all the ways they can benefit a project. So, I’m not going to waste too many words on the matter. Instead, in this article, I want to dig deeper into iconography as part of a design system. Besides, I’ll share with you doable tips that will turn icon creation and maintenance into an enjoyable — or at least bearable — process. Shall we?

Design Systems: From Chaos To Order

Design Systems 101

Before we actually dive into the alluring and frightening world of iconography, I want to take some time to introduce you to the concept of a design system, as well as share my thoughts and rules that I follow while working with them.

If I were to call a design the way your interface speaks with your user, then — building on the metaphor — it would be fair to view a design system as a language.

Simply put, a design system is a functional set of defined technical standards, best user behavior practices, and navigational patterns that are used to build a pixel-perfect digital product.

It is a powerful designer tool that helps you make sure that you will end up with a coherent product and not a pathetic mess.

It seems that nowadays, designers are obliged to try their hand at creating or at least adopting a design system. So what exactly makes it an all-around beneficial thing for the designer lot? Let’s have a look:

  • The design system makes for the only source of truth since all the components are under one roof and are easily referable.
  • It hosts all the guidelines on how to implement existing components. And following the very same guidelines, designers can easily create new ones that match the former.
  • In the case of a two- (or more) designer team, a design system allows for visual consistency (which is crucial if your project is major and fast-evolving).
  • You can either use ready-made design components or alter them swiftly and in accordance with the guideline if any need arises.
  • You have access to a library of surefire design patterns, which greatly reduces the strain of coming up with new solutions.

That sounds like a treat, right? Still, creating a design system is generally viewed as an exceptionally time- and effort-consuming endeavor. If you do want to develop a design system, there is a way to make the process a bit easier. Enter the atomic design approach.

Atomic Design Approach

It’s been over six years since I first introduced the atomic approach into my workflow, and let me tell you, it was a game-changer for me as a designer. This methodology is a blessing if you work on a big project with a team of fellow designers.

If you know the pain of trying to track the changes in components throughout the projects, especially if these components are minor, then you’ll see why I’m so enthusiastic about the atomic approach. It allows for smooth and well-coordinated teamwork where every designer is aware of what component they are creating and how to make it consistent with the rest of the system.

The atomic design approach was pioneered by Brad Frost (a chemist of all occupations). It implies building your system brick-by-brick, starting with the smallest items and going all the way up while sustaining hierarchy. There are five stages to the process.

  • Atoms
    In a nutshell, these are basic HTML elements.

  • Molecules
    They are single-pattern components that do one thing.

  • Organisms
    They are composed of groups of molecules, or/and atoms, or/and other organisms.

  • Templates
    They provide a context for using molecules and organisms and focus on the page’s underlying content structure. In other words, templates are the guidelines.

  • Pages
    They show what a UI looks like with proper content.

What exactly makes this approach a thing designers gravitate towards? Here are my two cents on the matter:

  • Creating a design system resembles playing with a construction set. You begin with the smallest components and progress in size, which means you are eating the elephant a bite at a time and don’t get overwhelmed.
  • Altering a component in one place will cause updates wherever a certain atom, molecule, or organism is applied. This eliminates any need for manual tweaking of components.
  • This approach provides designers with design patterns, meaning that you no longer need to create new ones and worry about their consistency.

That’s clearly not all the advantages of this methodology, so if you are interested, go ahead and read more about it in Brad Frost’s book.

What I’m really willing to focus on is our job as designers in creating and maintaining those fabled design systems, both atomic and regular. More specifically, on iconography. And even more specifically, on the pitfalls we have a nasty habit of falling into when dealing with icons as the atoms of our systems. Off we go.

Iconography In Design Systems: Maladies and Remedies

Common Problems

Since I’m relying on my own experience when it comes to design systems, it would only be fair if I shared the biggest issues that I personally have with iconography in the context of design systems and how I solve them. I’ll share with you surefire tips on how to keep your iconography consistent and ensure its smooth integration into design environments.

If we regard a single icon from the atomic design standpoint, we would consider it an atom — the smallest but essential element, just like the color palette or typography. If we continue with our language analogy, I will take the liberty of calling icons a design’s vocabulary. So, it’s fairly clear that icons are the actual core of your design.

As any designer knows, users heavily rely on icons as an interactional element of an interface. Despite being the smallest of components, icons might prove to be a major pain in the neck in terms of creation. This is the lesson I have learned during my tenure as a UX designer.

Tip 1: Since an atom is not just an autonomous element, you have to think beforehand about how it will behave as part of a larger component, like a molecule, an organism, or a template.

These are the variables you have to keep in mind when developing an icon:

  • Is your icon scalable?
  • Does it have color variations?
  • Do you classify your icon according to meaning, group, style, or location?
  • Is there an option to change the icon’s meaning or style?
  • How can you easily introduce a new icon into an existing roster?
  • How should you navigate a situation when different designers develop icons separately?
  • How can you make locating a certain icon within your design system easier?

Here are some challenges that I personally face while developing iconography for a design system:

  • How should I keep track of icon updates and maintain their consistency?
  • How should I develop icon creation guidelines?
  • What should I do if current icons happen to be inconsistent?
  • How should I inform my design team of any changes?

It might be hard to wrap your head around so many questions, but worry not. I’ll try my best to cover all these issues as we go on.

Rules Of Thumb

An icon isn’t just a little pictogram with a certain meaning behind it. An icon is a symbol of action, an interactive element of a digital interface that helps users navigate through the system.

In other words, it is a tool, and the process of building a tool implies following rules. I found out firsthand that if you master the basic icon rules, then you’ll be able to build both stand-alone icons and those that are part of a larger environment with equal efficiency. Besides, you’ll enhance your ability to create icon sets and various icon types within a single project, all while maintaining their readability and accessibility.

Tip 2: Keep consistency by establishing the basic icon rules before building your icon library.

The following are the rules that I abide by:

Grid

I use the classic 24px grid for standard icons and a 44px grid for larger icons. Each grid consists of the padding area (marked in red, 2 px) and the live area (marked in blue, 20 px). The live area is the space that your icon content stays inside. Its shape depends on the icon’s body and could be circular, square, vertical-rectangular, or horizontal-rectangular.

Before you sit down to draw your icon, decide how much space your icon’s body will occupy in order to come up with the proper shape.

Size

Each icon within a design system has to have a primary size, which is the size that up to 90% of all icons share. I consider the 24px icon size suggested by Google’s Material Design to be the golden standard. This size works well both for desktop and mobile devices.

Still, there is room for exceptions in this rule when an icon needs to be smaller or larger. In this case, I employ a 4-pixel step rule. I increase or decrease the icon’s size by 4 pixels at a time (e.g., I go from 24 to 20, then 16, then 12 px, or 28, 32 px, and so on). I would still personally prefer the golden standard of 24 pixels since I find smaller sizes less readable or larger sizes too visually domineering.

Weight

Another key property to consider is the outline weight of your icon if you opt for this type. If you are building an icon library from scratch, it would be wise to test several outline weight values before you make a decision. This is especially crucial for icons that contain fine details.

Granted, you can assign different weight values to different types of icons, but you might struggle to write clear guidelines for your fellow designers. I usually make a conscious decision to go with a unified outline weight for all the icons, namely, 2 points.

Fill

A solid icon variant might considerably enhance the accessibility and readability of an interface icon. It’s really handy to have both solid and outline icon types. But not all your icons should have two options. If you choose to draw a solid option, determine what parts of your icon you want to make solid.

Design principles

As I’ve mentioned before, an icon is an essential interface element. This means that an icon should be simplistic, bold, and — what’s even more important in the context of design systems — created according to the unified rules.

I have a little trick I use to see how well a new icon fits the standard. I simply integrate the new icon into the interface populated by already existing elements. This helps determine if the new icon matches the rest.

Anatomy

Such aspects as corner, counterstroke, and stroke terminal provide the much-desired visual consistency. Obviously, all these elements should be unified for all the icons within a design system. A comprehensive guide to icon anatomy is available at Material Design.

Icon Consistency: Surefire Tips

Before I actually share my tips on how to deal with icons within a design system efficiently, here’s a little backstory to how I came up with them. It all started when I joined a project that already had an established host of icons. There were over a hundred of them. And the number grew because the project was a fast-evolving thing. So, the design system, like any other, was like a living being, constantly in a state of change.

The icon library was a mishmash of different icon types, creating quite a noise. The majority of icons differed in style, size, and application. Another problem I had was the fact that most of the icons did not have the source file. So, there was no way to quickly tweak an icon to match the rest.

The first and most important thing I did was to establish the basic rules for icon creation (that’s something we’ve already covered). This step was supposed to keep the design team from creating inconsistent icons.

Tip 3: Put all your icons on one layout. This way, you’ll get a full visual understanding of your icons and determine repetitive design patterns.

Now, here comes the juicy stuff. Here is my guide on how to sustain iconography in the context of a design system.

  • Divide your icons into subcategories.
    This rule works wonders when you have an array of inconsistent icons on your hands. There is no rule on what subcategories there should be. It all depends on your design system and the number of existing icons.
    In my case, I established three groups divided by size and icon style, which resulted in three subcategories: regular icons, detailed icons, and illustrations. Once you divide your icons in the same manner, it’ll be easier to apply the same rules to each group. Besides, this approach allows for a more structured storage of these icons within your design system.

  • Determine guidelines for each icon type.
    The next step is as wise as it is hard to pull off. You need to assign certain icon creation rules for each of the icon types (provided you have more than one). This is the basis upon which all your other attempts at achieving visual consistency will be built. To tame all the mismatched icons, I used the basic icon rules we’ve covered above. To keep track, I created a page in Figma for each of the icon types and used the basic size as the file name.

  • Group your icons wisely.
    When naming icons, I opt for the semantic section approach. Generally, you can divide all your icons into groups based on their meaning or application in the interface. Look at the example below; we have three distinct semantic sections: Transport, Services, and Warnings. Depending on their meaning, icons should be assigned to the corresponding sections. Then, those sections are, in turn, divided into subsections. For instance, the Transport section has Ground Transport and Air Transport. The main idea you should stick to is to keep your icons in separate sections.

  • Stick to clear names and descriptions.
    I have to admit that dividing icons into semantic sections does have a massive disadvantage: this division could be quite subjective. This is why it is crucial to add a detailed description to each of the icons. This will simplify icon search within a design system and will give a clear understanding of an icon’s application. This is how I create a description:
    • Tags: reference words that facilitate searching for an icon within the system.
    • Usage: a brief description of an icon’s application.
    • Group Name: the name of the group an icon belongs to. This helps with locating an icon right within the library.
    • Designs: an incredibly nifty tool that allows you to insert a link to the design and documentation that features the icon in question. This way, you’ll know the context in which the icon is applied.

  • Use color coding and symbols while updating icon design.
    This trick works best when you are not yet done with the icon library, but you need to communicate to your team which icons are ready to use and which still need a bit of enhancement. For instance, I mark the names of finished icons with a green symbol. An orange symbol marks those icons that need to be improved. And in case I need an icon deleted or drawn anew, I use a red cross.

  • Keep non-rasterised versions of icons.
    It can be handy to have a non-rasterised version of an icon at arm’s length. There’ve been cases when I was asked to create a similar icon or an icon that could use the same graphic forms as the existing ones. Should this happen again, I can simply take the original file and easily draw an icon. I store all the non-rasterised icons on a separate page in the file following the defined hierarchy.

  • Rasterise the icon vector.
    Be sure to apply the Outline Stroke feature before you create the icon component. This will allow for easy color change (more on this in the next tip) and scaling.

  • Mind the colors of your icons.
    I suggest keeping icons in the primary, most commonly used color by default. Another worthwhile thing to do is to name all icon colors according to their intended use and the interactions they perform. In order to do that, you need to equip your color library with a separate set of colors for all icon states, like primary, hover, and disabled. Make sure to name each set properly.

  • Assign a designer to maintain icons in the system.
    This is a seemingly trivial tip that, however, will save you trouble maintaining style and categorization consistency. I’ve personally had edge cases when the established rules failed. Having a designated designer who knew their way around the system helped to find a quick solution.

Real Example Of Guidelines Applied

To wrap up this whole lecture and actually see all these rules in action, take a look at the following template file.

Final Thoughts: Is It Worth It?

No matter how sick you might be dealing with unending visual inconsistency, design systems are still challenging. They can scare any designer regardless of their experience. Still, if you want to bring order to chaos, introducing a design system into your workflow is worth the trouble, especially when it comes to maintaining iconography.

After all, iconography is the most volatile part of a design system in terms of visual variety. That’s why iconography was the biggest challenge I had to face in my tenure as a designer. And that’s exactly why I am genuinely proud that I’ve tamed that beast and can now share my hacks with you.

Resources

Public design systems:

Design systems resources:

Icons resources:

16 User Experience Feedback Questions to Ask Website Visitors

Are you looking for some user experience feedback questions to ask your visitors?

By asking user experience feedback questions, you can better understand your users’ needs and expectations, identify areas that need improvement, and measure overall customer satisfaction. This can help you gain a competitive advantage over other websites.

In this article, we will share some of the best user experience feedback questions to ask website visitors and show you how to survey users in WordPress.

User Experience Feedback Questions to Ask Website Visitors

Why Ask User Experience Feedback Questions in WordPress?

If you have a WordPress website, then asking users for feedback will help you gather insights into their needs, preferences, and dislikes. This is essential for improving your website’s design, content, and functionality to align with user expectations.

Feedback can even reveal website areas that can be optimized to increase conversions, like improving the checkout process. You can then implement these suggestions to generate more leads and make more sales.

User experience feedback preview

Additionally, asking for user experience feedback can also boost user engagement by showing visitors that their feedback is valued and you are actively working to improve your content.

Having said that, let’s take a look at some of the best user experience feedback questions to ask your website visitors.

User Experience Feedback Questions to Ask Website Visitors

Here are some general questions that you can ask your visitors to learn more about the UX of your website.

1. How would you rate the overall usability of our website?

If you have a WordPress blog, then asking users to rate the overall usability of your website can help you quickly and easily see if your website is doing well or if it has areas that need improvement.

It can also help you track your website’s progress over time as you make changes to improve the overall user experience.

Once you ask this question, you can also add a follow-up question that asks for the user’s reason for the rating that they gave. This will help identify patterns in usability issues and make it easy to troubleshoot those problems.

2. How would you rate the overall speed and responsiveness of our website?

A website’s speed is one of its most important factors because fast-loading page times can improve the user experience, increase pageviews, and boost your WordPress SEO.

You can gauge user satisfaction and engagement by asking users to rate your website speed. For example, if your visitors are giving you low ratings, then it means that your loading times are too long, and people are leaving your site frustrated.

If this is the case, then you can use different tips to speed up your WordPress site and improve the user experience.

3. What suggestions do you have for improving our website?

By asking users to provide suggestions for improving your website, you can identify usability issues that may have been overlooked by your developers.

For example, a call to action (CTA) on your website may not work, which has caused a lot of users to leave your site frustrated.

MonsterInsights CTA

We recommend asking this question in a feedback form after users have provided a rating for the overall website usability. This question can help you find out about this issue and also show users that you care about their opinions and experiences.

4. What is your first impression of our website’s homepage?

The homepage is the introduction to your website and is usually the first page that visitors interact with. This page should create positive emotions in users and encourage them to explore your site.

By asking users about their first impression of your website’s homepage, you can assess if the page is effectively communicating your website’s purpose. It can help gain insights into the user’s impression of your branding and overall homepage look.

If you need to make improvements, then you can check out our guide on how to create a custom home page in WordPress.

5. What did you dislike most about our website?

Asking users what they dislike about your website can uncover specific issues that are causing frustration and dissatisfaction among your visitors and customers.

For example, you might discover that users are annoyed by the number of ads on your site or intrusive popups.

Once you have identified these issues, you can fix them to prevent users from abandoning your website. This can lead to better user loyalty, improve the user experience, and even help increase conversions.

6. What changes can we make to our website design?

By asking for user suggestions, you can gain more ideas for design elements and aesthetics that were overlooked when you were creating your pages.

Visitors can also provide suggestions that will ultimately help improve the user experience. For example, some people may find it difficult to use your navigation menu. This can give you the idea to make your navigation menu more visible and easier to navigate.

An example of an eCommerce mega menu

Additionally, this user feedback can help you stay up-to-date with the current website design trends and update your pages to match them.

User Experience Feedback Questions to Ask WooCommerce Store Customers

If you have a WooCommerce store, then asking these questions can help improve the user experience in your online store.

1. How was your shopping experience today?

Asking users this question immediately after purchasing can help you gather feedback about the customer’s experience.

It will also help you better understand the overall customer journey, from browsing through your products to completing checkout. This question will reveal patterns, trends, and any errors that are repeatedly being faced by your customers that need to be fixed or improved.

2. What can we do to make our product(s) better?

Asking users for suggestions to improve your products allows you to gain insights into your customers’ unmet needs. This lets you understand the type of solutions that your users are looking for and potentially come up with new features for your products.

This can help you gain a competitive advantage over other online stores by letting you tailor your products to meet users’ needs and expectations.

3. Did you find the information you were looking for on our product page?

This question improves the user experience by helping you identify information gaps. It determines whether your product page effectively communicates the necessary information to help users make informed decisions.

This allows you to understand the type of information that the users want to see for a product and change your pages accordingly.

Product page preview

For more details, see our guide on how to customize your WooCommerce product pages.

4. Were you looking for anything today that you couldn’t find?

Asking visitors if they were looking for something they couldn’t find allows you to broaden your store’s scope by taking user ideas into account and adding those products to your inventory.

For example, if you sell clothes online, and users on your website answered that they wanted to find matching accessories with their clothing items, then you could expand into jewelry as well.

5. Was there anything that made you cancel your order?

Customers cancel their orders for several reasons, like high shipping costs, delayed shipping, unexpected charges, or issues during the checkout process.

By asking this question, you can identify the main reason for users canceling their orders in your online store.

For example, if many customers are canceling their orders due to shipping delays, then you can improve the shipping process to reduce delays and improve customer satisfaction.

6. What is the one part of our checkout process that we should improve?

Your store’s checkout process should be seamless to provide a top-notch customer experience. By asking users this question, you can gain a variety of perspectives and identify common issues in the checkout section.

For example, if your checkout is too long and complicated, then you might switch to an express checkout.

An example of an express checkout form, created using FunnelKit Funnel Builder

Alternatively, see the tips in our guide on how to customize the WooCommerce checkout page.

7. What was your main concern or fear before purchasing this product?

By asking users this question, you can find out the potential barriers to purchase and take steps to address those issues on your site.

For instance, you can improve your product messaging and positioning to encourage more users to complete their purchases.

It is also a good idea to create a personalized user experience by setting up personalized recommendations, addressing customer concerns proactively, and offering customer support to boost engagement and satisfaction.

User Experience Feedback Questions to Ask Website Visitors on Mobile

The majority of your users will access your website using mobile devices. These are the user experience feedback questions you can ask visitors to improve your website on mobile.

1. Was our website easy to navigate on mobile?

Over 55% of your website traffic will come from mobile devices. However, your website will look different on mobile due to a smaller screen size and a touch-based interface.

View mobile screen preview

Asking users how easy it is to navigate your site on a mobile device can help identify any design issues that are causing people to leave your site unsatisfied. For instance, you may need to use a responsive WordPress theme and other responsive design elements.

This will help you optimize your site for mobile navigation and can ultimately lead to more conversions.

2. Were any parts of the page not visible or hard to see?

A mobile device’s small screen size can limit the amount of information displayed on a page and make your site look crowded.

By asking users this question, you can identify areas that need to be optimized for mobile viewing. You can also check this information yourself by following our guide on how to view the mobile version of WordPress sites from desktop.

3. Did you find the website’s blog posts easy to read on your mobile device?

Blog posts can look different on mobile devices because the text is smaller and the images are more compressed, giving the page a cramped look.

By asking users if they could easily read your posts on mobile devices, you can identify parts of your content that may be difficult to read.

You can then change the font size, break up paragraphs, and use an uncluttered layout to make your blog posts more readable. For more details, just see our guide on how to improve readability in WordPress.

How to Add a User Experience Feedback Prompt in WordPress

You can easily add a quick user experience survey on your WordPress website with UserFeedback. It is the best WordPress feedback plugin on the market that comes with 25+ premade survey templates and lets you ask unlimited questions.

Plus, the plugin offers different types of questions that you can ask, including multiple-choice questions, an NPS survey, a quick rating question, radio buttons, email captures, or an open-ended question for feedback.

First, you need to install and activate the UserFeedback plugin. For detailed instructions, see our beginner’s guide on how to install a WordPress plugin.

Note: UserFeeback also has a free plan. However, we will be using the premium plan to unlock more features.

Upon activation, visit the UserFeedback » Surveys page from the WordPress admin sidebar and click the ‘Create New’ button.

Click Create New button on Surveys page

This will direct you to the ‘Select a Template’ page, where you can choose any of the premade templates.

Since you want to ask for user experience feedback, you can select the ‘Website Experience’ template.

Choose the website experience feedback template

This will take you to another screen where you can start creating a user experience feedback survey.

By default, the website experience template asks users to rate their experience on your website. If you want, you can change the question from the text field and then choose a question type from the dropdown menu.

You can add checkboxes, radio buttons, star ratings, text fields, and more.

Once you do that, click the ‘Add Question’ button to add another question to the user experience feedback survey.

Choose a question type

This will expand another prompt on the screen where you can add another question.

For example, if you asked users to rate the website user experience in the first question, then you can ask users about everything they think needs to be improved on your site.

After that, you can select ‘Long Answer’ as the question type so that users can answer without any word count restrictions.

Add a question asking for suggestions to improve user experience

You can then switch to the ‘Preview’ link at the top to customize your user experience feedback prompt.

Here, you can change the color scheme, button color, widget color, and text color for the prompt. Once you do that, just click the ‘Next Step: Settings’ button.

Customize the user experience feedback prompt

You will now be taken to the ‘Settings’ page, where you can start by scrolling down to the ‘Targeting’ section.

Here, you can choose the device type where the survey will be displayed. For example, if you created this survey to gather insights into your performance on mobile devices, then you can select the ‘Mobile’ option. The survey will then only be displayed to the visitors browsing your site on their mobile phones.

After that, you can select the ‘All Pages’ option if you want to display the survey on all the pages and posts on your website.

Configure targeting settings

However, if you want to display the survey on a specific post or page, then you can select the ‘Advanced’ option.

Then, you can specify the conditions for the survey display from the dropdown menu.

For instance, if you want to display the survey on a single page, then you can select the ‘Page URL is’ option from the dropdown menu on the right and then add a page URL into the field on the left.

Add conditional logic for prompt display

Next, scroll down to the ‘Behaviour’ section to configure the display timing of your user experience feedback survey.

Here, you can decide when the survey will appear on your page, how often it will be displayed, and how long it will run on your website.

Once you have done that, simply click the ‘Next Step: Notifications’ button.

Configure behaviour settings

On the new page, you must toggle on the ‘Send Email’ switch and then enter the email address where you want to receive notifications every time a website visitor completes your feedback survey.

After that, click the ‘Next Step: Publish’ button.

Toggle send email switch

Now that you are on the ‘Publish’ page, simply toggle the ‘Survey Status’ switch to ‘Publish’ to activate your survey.

If you want to schedule your survey for a later date, then you can do that by toggling the ‘Schedule for Later’ switch and adding a specific date and time.

Publish user experience feedback survey

Finally, don’t forget to click the ‘Save and Publish’ or ‘Save and Schedule’ button to store your settings.

You can now visit your WordPress site to view the user experience feedback survey in action.

User experience feedback prompt preview

Once the survey is published, you can easily view its results by visiting the UserFeedback » Results page from the WordPress dashboard.

You will now be able to check the number of responses, impressions, and all the answers provided by your visitors. This can help you improve the overall user experience of your website.

View feedback results

Bonus: How to Do a UX Audit of Your WordPress Site

Apart from gathering feedback to improve the user experience, it is also important to do a UX audit of your website. This means testing your site to see if there are any usability issues that you can fix.

This is a crucial step to ensure that your site is efficient and provides a high-quality experience.

To do a UX audit, you should first be able to recognize your target audience and understand their needs and preferences. Then, you can move on to finding pages on your website with poor user experience.

To do this, you can use MonsterInsights, which is the best Google Analytics plugin on the market. It lets you see where your users are coming from and how they interact with your website. MonsterInsights also allows you to see pages on your site where you get conversions.

The MonsterInsights Google Analytics plugin

Upon installing and activating the MonsterInsights plugin, all you have to do is visit the Insights » Addons page from your WordPress admin sidebar to install and activate the ‘eCommerce’ addon.

After that, go to the Insights » Reports page and switch to the ‘eCommerce’ tab. You will now be able to overview your top-performing products and conversion sources. This will also help you identify the pages and products where you don’t get many conversions.

Viewing eCommerce reports

Additionally, your UX audit may involve optimizing your website’s speed and performance, making your navigation menu simpler, testing conversion elements, and more.

For detailed instructions, you can see our beginner’s guide on how to do a UX audit of your WordPress site.

We hope this article helped you learn some user experience feedback questions to ask your website visitors. You may also want to see our tutorial on how to track user engagement in WordPress with Google Analytics and our top picks for the best WordPress survey plugins.

If you liked this article, then please subscribe to our YouTube Channel for WordPress video tutorials. You can also find us on Twitter and Facebook.

The post 16 User Experience Feedback Questions to Ask Website Visitors first appeared on WPBeginner.

Creating And Maintaining A Voice Of Customer Program

For those involved in digital and physical product development or leadership, consider a Voice of Customer (VoC) program. A VoC program systematically gathers and analyzes customer insights, channeling user opinions into actionable intelligence. VoC programs use surveys, analytics, interviews, and more to capture a broad range of customer sentiment. When implemented effectively, a VoC program transforms raw feedback into a roadmap for strategic decisions, product refinement, and service enhancements.

By proactively identifying issues, optimizing offerings for user satisfaction, and tailoring products to real-time demand, VoC programs keep companies ahead. Moreover, in a world of fleeting consumer loyalty, such programs build trust and enhance the overall brand experience. VoC has been a standard CX practice that UX and product teams can utilize to their advantage. We’ll focus on VoC for digital products for this article. However, the methods and lessons learned are equally applicable to those working with physical products.

Successful product teams and User Experience (UX) practitioners understand that customer feedback is invaluable. It guides decisions and fosters innovation for products and services. Whether it’s e-commerce platforms refining user interfaces based on shopper insights or social media giants adjusting algorithms in response to user sentiments, customer feedback is pivotal for digital success. Listening, understanding, and adapting to the customer’s voice are key to sustainable growth.

The role of UX research in capturing the Voice of the Customer

UX research serves as the bridge that spans the chasm between a company’s offerings and its customers’ perspectives. UX research plays a pivotal role in capturing the multifaceted VoC. Trained UX researchers transform raw feedback into actionable recommendations, guiding product development and design in a direction that resonates authentically with users.

Ultimately, UX research is the translator that converts the diverse, nuanced VoC into a coherent and actionable strategy for digital companies.

Setting Up A Voice Of Customer Program

Overview Of Steps

We’ve identified six key steps needed to establish a VoC program. At a high level, these steps are the following:

  1. Establishing program objectives and goals.
  2. Identifying the target audience and customer segments.
  3. Selecting the right research methods and tools.
  4. Developing a data collection framework.
  5. Analyzing and interpreting customer feedback.
  6. Communicating insights to stakeholders effectively.

We’ll discuss each of these steps in more detail below.

Establishing Program Objectives And Goals

Before establishing a VoC program, it’s crucial to define clear objectives and goals. Are you aiming to enhance product usability, gather insights for new feature development, or address customer service challenges? By outlining these goals, you create a roadmap that guides the entire program. You will also avoid taking on too much and maintain a focus on what is critical when you state your specific goals and objectives. Specific objectives help shape research questions, select appropriate methodologies, and ensure that the insights collected align with the strategic priorities of the company.

You should involve a diverse group of stakeholders in establishing your goals. You might have members of your product teams and leadership respond to a survey to help quantify what your team and company hope to get out of a VoC. You might also hold workshops to help gain insight into what your stakeholders consider critical for the success of your VoC. Workshops can help you identify how stakeholders might be able to assist in establishing and maintaining the VoC and create greater buy-in for the VoC from your stakeholders. People like to participate when it comes to having a say in how data will be collected and used to inform decisions. If you come up with a long list of goals that seem overwhelming, you can engage key stakeholders in a prioritization exercise to help determine which goals should be the VoC focus.

Identifying The Target Audience And Customer Segments

Once you create clear objectives and goals, defining the target audience and customer segments will be important. For example, you decide your objective is to understand conversion rates between your various customer segments. Your goal is to increase sign-up conversion. You would want to determine if your target audience should be people who have purchased within a certain time frame, people who have never made a purchase, people who have abandoned carts, or a mix of all three.

Analytics can be critical to help create shortcuts at this point. You might start by looking at analytical data collected on the sign-up page to identify age gaps to set the target audience to understand why that specific age gap(s) are not signing up, whether there is evidence certain segments are more likely to abandon carts, and which segments are less likely to visit your site at all. Then, based on these clear objectives and goals, as well as identifying a target audience and customer segment, you could select the right research method and tools to collect data from the audience segment(s) you’ve identified as critical to collect feedback from.

Selecting The Right Research Methods And Tools

The success of a VoC program hinges on the selection of appropriate research methods and tools. Depending on your objectives, you might employ a mix of quantitative methods like surveys and analytics to capture broad trends, along with qualitative methods like user interviews and usability testing to unearth nuanced insights. Utilizing digital tools and platforms can streamline data collection, aggregation, and analysis. These tools, ranging from survey platforms to sentiment analysis software, enhance efficiency and provide in-depth insights.

The key is to choose methods and tools that align with the program’s goals and allow for a holistic understanding of the customer’s voice.

Your UX researcher will be critical in helping to identify the correct methods and tools for collecting data.

For example, a company could be interested in measuring satisfaction with its current digital experience. If there are currently no metrics being captured by the company, then a mixed method approach could be used to try to understand customers’ current attitudes towards the digital experience at a large scale and then dive deeper at a smaller scale after analyzing the survey. The quantitative survey could contain traditional metrics to measure people’s feelings like Net Promoter Score (NPS), which attempts to measure customer loyalty using a single item and/or System Usability Scale (SUS), which attempts to measure system usability using a brief questionnaire, and then based on the data collected, would drive the types of questions asked in a qualitative interview.

To collect the survey information, an online survey tool could be used that can draft and calculate metric questions for you. Many tools have integrated analysis that allows users to do statistical analysis of quantitative data collected and light semantic reviews on qualitative data. You can share the survey data easily with your stakeholder groups and then shape an interview protocol that will allow you to reach out to a smaller group of users to get deeper insight into the findings from the survey.

Table 1: Commonly used UX research methods to consider as part of a VOC Program
UX Research Method Situations in which to use Type of data collected
User interviews
  • Gaining an in-depth understanding of user needs, motivations, and behaviors.
  • Uncovering hidden pain points and frustrations.
  • Generating new ideas and solutions.
Qualitative data (e.g., quotes, stories, opinions)
Surveys
  • Gathering quantitative data from a large number of users.
  • Measuring user satisfaction and attitudes.
  • Identifying trends and patterns.
Quantitative data (e.g., ratings, rankings, frequencies)
Focus groups
  • Generating a wide range of perspectives on a topic.
  • Exploring controversial or sensitive issues.
  • Gathering feedback on design concepts or prototypes.
Qualitative data (e.g., group discussions, consensus statements)
Usability testing
  • Identifying usability problems with a product or service.
  • Evaluating the effectiveness of design solutions.
  • Gathering feedback on user flows and task completion.
Qualitative and quantitative data (e.g., task completion rates, error rates, user feedback)
Analytics
  • Tracking user behavior on a website or app.
  • Identifying trends and patterns in user engagement.
  • Measuring the effectiveness of marketing campaigns.
Quantitative data (e.g., page views, time on site, conversion rates)

Developing A Data Collection Framework

Collecting feedback requires a structured approach to ensure consistency and reliability. Developing a data collection framework involves creating standardized surveys, questionnaires, and interview protocols that gather relevant information systematically. A well-designed framework ensures you capture essential data points while minimizing biases or leading questions. This framework becomes the backbone of data collection efforts, enabling robust analysis and comparison of feedback across various touchpoints and customer segments.

Your data collection framework should include the following:

  • Objectives and research questions.
  • Data sources, whether it’s surveys, user interviews, website analytics, or any other relevant means.
  • Data collection methods with an emphasis on reliability and validity.
  • A robust data management plan. This includes organizing data in a structured format, setting up appropriate storage systems, and ensuring data security and privacy compliance, especially if dealing with sensitive information.
  • Timing and frequency of data collection, as well as the duration of your study. A well-thought-out schedule ensures you gather data when it’s most relevant and over a suitable time frame.
  • A detailed data analysis plan that outlines how you will process, analyze, and draw insights from the collected data.

Analyzing And Interpreting Customer Feedback

Collecting data is only half the journey; the real value lies in analyzing and interpreting the data collected. This involves processing both quantitative data (such as survey responses) and qualitative data (such as open-ended comments). Data analysis techniques like sentiment analysis, thematic coding, and pattern recognition help distill valuable insights.

These insights unveil customer preferences, emerging trends, and pain points that might require attention. Your UX researcher(s) can take the lead, with assistance from other team members, in helping to analyze your data and interpret your findings. The interpretation phase transforms raw data into actionable recommendations, guiding decision-making for product improvements and strategic initiatives.

Communicating Insights To Stakeholders Effectively

The insights derived from a VoC program hold significance across various levels of the organization. Effectively communicating these insights to stakeholders is critical for driving change and garnering support. Presenting findings through clear, visually engaging reports and presentations helps stakeholders grasp the significance of customer feedback. Additionally, highlighting actionable recommendations and illustrating how they tie back to strategic objectives empowers decision-makers to make informed choices. Regularly updating stakeholders on progress, outcomes, and improvements reinforces the ongoing value of the VoC program and fosters a culture of customer-centricity within the organization.

Key Components Of A Successful Voice Of Customer Program

Building A Culture Of Feedback Within The Organization

A successful VoC program is rooted in an organizational culture that prioritizes feedback at all levels. This culture begins with leadership setting the example by actively seeking and valuing customer opinions. When employees perceive that feedback is not only encouraged but also acted upon, it fosters an environment of collaboration and innovation. This culture should extend across departments, from marketing to development to customer service, ensuring that every team member understands the role they play in delivering exceptional experiences. By integrating customer insights into the company’s DNA, a feedback culture reinforces the notion that everyone has a stake in the customer’s journey.

Start small and incorporate research activities into product development to start harnessing a user-centric approach. Develop reports that showcase the business purpose, findings, and recommendations that can be presented to the product development team and stakeholders, but also to other departments to show the value of VoC research. Lastly, provide opportunities to collaborate with other departments to help them incorporate VoC into their daily activities. As a result, a culture of incorporating a VoC program becomes reinforced.

There are many ways you can go about building this culture. Some specific examples we’ve used include facilitating cross-product or cross-discipline meetings to plan research and review findings, workshops bringing together stakeholders from various lines of business or roles to help shape the research agenda, and perhaps most importantly, identifying and utilizing a champion of insights to promote findings throughout the organization. Ideally, your champion would hold a position that allows them to have exposure horizontally across your business and vertically up to various key stakeholders and members of leadership. Your champion can help identify who should be attending meetings, and they can also be utilized to present findings or have one-off conversations with leadership to promote buy-in for your culture of feedback.

Implementing User-friendly Feedback Mechanisms

For a VoC program to thrive, feedback mechanisms must be accessible, intuitive, and seamless for customers. Whether it’s a user-friendly feedback form embedded within an app, a chatbot for instant assistance, or social media channels for open conversations, the channels for providing feedback should reflect the digital preferences of your audience. These mechanisms should accommodate both quantitative and qualitative inputs, enabling customers to share their experiences in a manner that suits them best. A key element here is the simplicity of the process; if users find it cumbersome or time-consuming to provide feedback, the program’s effectiveness can be compromised.

Encouraging Customer Participation And Engagement

Engaging customers is essential for gathering diverse perspectives. Incentivizing participation through rewards, gamification, or exclusive offers can increase engagement rates. Moreover, companies can foster a sense of ownership among customers by involving them in shaping future offerings. Beta testing, user panels, and co-creation sessions invite customers to actively contribute to product development, reinforcing the idea that their opinions are not only valued but directly influence the company’s direction. By making customers feel like valued collaborators, a VoC program becomes a mutually beneficial relationship.

Integrating Feedback Into The Decision-making Process

Customer feedback should not remain isolated; it needs to permeate the decision-making process across all departments. This integration demands that insights gathered through the VoC program are systematically channeled to relevant teams. Product teams can use these insights to refine features, marketers can tailor campaigns based on customer preferences, and support teams can address recurring pain points promptly. Creating feedback loops ensures that customer opinions are not only heard but also translated into tangible actions, demonstrating the organization’s commitment to iterative improvement driven by user insights.

Continuous Improvement And Iteration Of The VoC Program

A VoC program is a journey, not a destination. It requires a commitment to continuous improvement and adaptation. As customer behaviors and preferences evolve, the program must evolve in tandem. Regularly reviewing the program’s effectiveness, incorporating new data sources, and updating methodologies keep the program relevant. This also includes analyzing the program’s impact on KPIs such as customer satisfaction scores, retention rates, and revenue growth. By iterating the program itself, businesses ensure that it remains aligned with changing business goals and the ever-evolving needs of their customers.

Best Practices And Tips For An Effective VoC Program

Creating Clear And Concise Surveys And Questionnaires

The success of a VoC program often hinges on the quality of the surveys and questionnaires used to collect feedback. To ensure meaningful responses, it’s essential to design clear and concise questions that avoid ambiguity. Keep the surveys focused on specific topics to prevent respondent fatigue and make sure that the language used is easily understandable by your target audience. Utilize a mix of closed-ended (quantitative) and open-ended (qualitative) questions to capture both statistical data and rich, contextual insights. Prioritize brevity and relevance to encourage higher response rates and more accurate feedback.

Monitoring Feedback Across Multiple Channels

Customer feedback is shared through diverse channels: social media, email, app reviews, support tickets, and more. Monitoring feedback across these channels is essential for capturing a holistic view of customer sentiment. Centralize these feedback streams to ensure that no valuable insights slip through the cracks. By aggregating feedback from various sources, you can identify recurring themes and uncover emerging issues, allowing for proactive responses and continuous improvement. Note we have focused on digital products. However, if there is a physical component of your experience, such as a brick-and-mortar store, you should be collecting similar feedback from those customers in those settings.

Incorporating User Testing And Usability Studies

Incorporating user testing and usability studies is important to help evaluate an experience with users. While upfront activities like in-depth user interviews can articulate users’ desires and needs for an experience, they do not help evaluate the updated experience. Findings and recommendations from user testing and usability studies should be incorporated into development sprints or backlogs. This will ensure that the experience consistently considers and reflects the VoC.

Ensuring Privacy And Data Security In The VoC Program

As you talk to users and develop your VoC program, you will constantly be collecting data. The data that is shared in reports should always be anonymous. Additionally, creating documentation on how to collect consent and data policies will be very important. If data is not stored properly, you could face penalties and lose the trust of participants for future VoC activities.

Challenges Of Starting A Voice Of Customer Program

If you are committed to starting a VoC program from scratch and then maintaining that program, you are likely to encounter many challenges. Gaining buy-in and commitment from stakeholders is a challenge for anyone looking to establish a VoC program. You’ll need to commit to a concerted effort across various departments within an organization. Securing buy-in and commitment from key stakeholders, such as executives, managers, and employees, is crucial for its success. Without their support, the program may struggle to gain traction and achieve its goals.

Resources are always an issue, so you’ll need to work on securing adequate funding for the program. Establishing and maintaining a VoC program can be a costly endeavor. This includes the cost of software, training, and staff time. Organizations must be prepared to allocate the necessary resources to ensure the success of the program.

Allocating sufficient time and resources to collect, analyze, and act on feedback: collecting, analyzing, and acting on customer feedback can be a time-consuming process. Organizations must ensure that they have the necessary staff and resources in place to dedicate to the VoC program.

Case Study: Successful Implementation Of A VoC Program

We worked with a large US insurance company that was trying to transform its customers’ digital experience around purchasing and maintaining policies. At the start of the engagement, the client did not have a VoC program and had little experience with research. As a result, we spent a lot of time initially explaining to key stakeholders the importance and value of research and using the findings to make changes to their product as they started their digital transformation journey.

We created a slide deck and presentation outlining the key components of a VoC program, how a VoC program can be used to impact a product, methods of UX research, what type of data the methods would provide, and when to use certain methods. We also shared our recommendations based on decades of experience with similar companies. We socialized this deck through a series of group and individual meetings with key stakeholders. We had the benefit of an internal champion at the company who was able to identify and schedule time with key stakeholders. We also provided a copy of the material we’d created to socialize with people who were unable to attend our meetings or who wanted to take more time digesting information offline.

After our meetings, we fielded many questions about the process, including who would be involved, the resources required, timelines for capturing data and making recommendations, and the potential limitations of certain methods. We should have accounted for these types of questions in our initial presentation.

VoC Activity Purpose Involvement
In-Depth User Interviews One-on-one interviews that focused on identified customer’s current usages, desires, and pain points related to the current experience. Additionally, later in the product development cycle, understanding customer’s feelings towards the new product and features that should be prioritized/enhanced in future product releases. Product, sales, and marketing teams
Concept Testing One-on-one concept testing with customers to gather feedback on the high-level design concepts. Product, sales, and marketing teams
Unmoderated Concept Testing Unmoderated concept testing with customers to gather feedback on the materials provided by the business to customers. The goal was to be able to reach out to more people to increase the feedback. Product, sales, and marketing teams
Usability Testing One-on-one usability testing sessions with customers to identify behaviors, usability, uses, and challenges of the new product. Product, sales, and marketing teams
Kano Model Survey This survey is to gather customer input on features from the product backlog to help the business prioritize them for future development. Product Team
Benchmarking Survey This survey is to help understand users’ attitudes toward the digital experience that can be used to compare customers’ attitudes as enhancements are made to it. Metrics that were used include Net Promoter Score, Systematic Suability Scale, and Semantic Differential. Product, sales, and marketing teams

One large component of enhancing the customer’s digital experience was implementing a service portal. To help better understand the needs and desires of users for this service portal, we started with executing in-depth user interviews. This first VoC activity helped to show the value of VoC research to the business and how it can be used to develop a product with a user-centric approach.

Our biggest challenge during this first activity was recruiting participants. We were unable to use a third-party service to help recruit participants. As a result, we had to collect a pool of potential participants through the sales division. As mentioned before, the company didn’t have much exposure to VoC work, so while trying to execute our VoC research and implement a VoC program, any time we worked with a division in the company that hadn’t heard of VoC, we spent additional time walking through what VoC is and what we were doing. Once we explained to the sales team what we were doing, they helped with providing a list of participants for recruitment for this activity and future ones.

After we received a list of potential participants, we crafted an email with a link to a scheduling tool where potential participants could sign up for interview slots. The email would be sent through a genetic email address to over 50+ potential participants. Even though we sent multiple reminder emails to this potential list of participants, we could only gather 5–8 participants for each VoC activity.

As we conducted more VoC activities and presented our findings to larger audiences throughout the company, more divisions became interested in participating in the VoC program. For example, we conducted unmoderated concept testing for a division that was looking to redesign some PDFs. Their goal was to understand customers’ needs and preferences to drive the redesign process. Additionally, we also helped a vendor conduct usability testing for the company to understand how user-friendly an application system was. This was one way to help grow the VoC program within the company as well as their relationship with the vendor.

We needed to do more than foster a culture of gathering customer feedback. As we began to execute the VoC program more extensively within the company, we utilized methods that went beyond simply implementing feedback. These methods allowed the VoC program to continue growing autonomously.

We introduced a benchmarking survey for the new portal. This survey’s purpose was to gauge the customer experience with the new portal over time, starting even before the portal’s release. This not only served as a means to measure the customer experience as it evolved but also provided insights into the maturation of the VoC program itself.

The underlying assumption was that if the VoC program were maturing effectively, the data gathered from the customer experience benchmarking survey would indicate that customers were enjoying an improved digital experience due to changes and decisions influenced more by VoC.

Next, we focused on transferring our knowledge to the company so the VoC program could continue to mature over time without us there. From the beginning, we were transparent about our processes and the creation of material for a VoC activity. We wanted to create a collaborative environment to make sure we understand the company’s needs and questions, but also so the company could understand the process for executing a VoC activity. We accomplished this in part by involving our internal champion at the company in all of the various studies we conducted and conversations we were having with various business units.

We’d typically start with a request or hypothesis by a division of the company. For example, once the portal is launched, what are people’s opinions on the new portal, and what functionality should the business focus on? Then, we would craft draft materials of the approach and questions. In this case, we decided to execute in-depth user interviews to be able to dive deep into users’ needs, challenges, and desires.

Next, we would conduct a series of working sessions to align the questions and ensure that they still align with the company’s goals for the activity. Once we had all the materials finalized, we had them reviewed by the legal team and began to schedule and recruit participants. Lastly, we would conduct the VoC activity, synthesize the data, and create a report to present to different divisions within the company.

We started the transfer of knowledge and responsibilities to the company by slowly giving them some of these tasks related to executing a VoC activity. With each additional new task the company was in charge of, we set additional time aside to debrief and provide details on what was done well and what could be improved upon. The goal was for the individuals at the company to learn by doing and giving them incremental new tasks as they felt more comfortable. Lastly, we provided documentation to leave behind, including a help guide they could refer to when continuing to execute VoC activities.

We concluded our role managing the VoC program by handing over duties and maintenance to the internal champion who had worked with us from the beginning. We stayed engaged, offering a few hours of consulting time each month; however, we were no longer managing the program. Months later, the program is still running, with a focus on collecting feedback on updates being made to products in line with their respective roadmaps. The client has used many of the lessons we learned to continue overcoming challenges with recruiting and to effectively socialize the findings across the various teams impacted by VoC findings.

Overall, while helping to build this VoC program, we learned a lot. One of our biggest pain points was participant recruitment. The process of locating users and asking them to participate in studies was new for the company. We quickly learned that their customers didn’t have a lot of free time, and unmoderated VoC activities or surveys were ideal for the customers as they could complete them on their own time. As a result, when possible, we opted to execute a mixed-methods approach with the hope we could get more responses.

Another pain point was technology. Some of the tools we’d hoped to use were blocked by the company’s firewall, which made scheduling interviews a little more difficult. Additionally, some divisions had access to certain quantitative tools, but the licenses couldn’t easily be used across divisions, so workarounds had to be created to implement some surveys. As a result, being creative and willing to think about short-term workarounds was important when developing the VoC program.

Conclusion

Building a successful VoC program is an ongoing effort. It requires a commitment to continuously collecting, analyzing and acting on customer feedback. This can be difficult to sustain over time, as other priorities may take precedence. However, a successful VoC program is essential for any organization that is serious about improving the customer experience.

We’ve covered the importance of VoC programs for companies with digital products or services. We recommend you take the approach that makes the most sense for your team and company. We’ve provided details of starting and maintaining a VoC program, including the upfront work needed to define objectives and goals, targeting the right audience, choosing the right methods, putting this all in a framework, collecting data, data analysis, and communicating your findings effectively.

We suggest you start small and have fun growing your program. When done right, you will soon find yourself overwhelmed with requests from other stakeholders to expand your VoC to include their products or business units. Keep in mind that your ultimate goal is to create a product that resonates with users and meets their needs. A VoC program ensures you are constantly collecting relevant data and taking actionable steps to use the data to inform your product or business’s future. You can refine your VoC as you see what works well for your situation.

Additional Voice of Customer Resources

Everything I Know About UX Research I First Learned From Lt. Columbo

If you don’t know Lieutenant Columbo, I envy you. I wish I could erase my memory and watch this TV masterpiece for the first time again. Columbo, a Los Angeles homicide detective, has become a cult character in American crime drama in the 1970s. Each episode of this show reveals the murderer from the first minute, and the main mystery is how Columbo proves their guilt and distinguishes between lies and the truth.

When I reflect back on this series, it becomes apparent that the UX area has so much in common with crime scene investigation: the truth is unknown, people tend to disguise their real needs, and you have to discover missing facts as soon as possible to build and launch something useful. I’ve never specialized in UX research, but it has been part of my job as a designer for years. When I started, we rarely had the luxury of a dedicated researcher on a team.

So, let’s see what we can learn from a classical fictional character and apply it in the UX area.

Lesson 1: Understate Your Role To Users

It’s not a secret that people behave differently in the vicinity of police, state officials, or management. Columbo understood that if a suspect or witness realized who he was, they would try to disguise or tweak facts (either consciously or subconsciously). That’s why our hero preferred to blend in and keep his position out of sight as long as possible.

For instance, in the episode “By Dawn’s Early Light” (S4E3), the commandant of a military academy murders the chairman of the board. So, Columbo stayed in the barracks for several days and talked with cadets informally until he exposed the killer.

Sometimes, such an approach has caused funny situations. In the episode “Negative Reaction” (S4E2), Columbo was mistaken for a hobo at St. Matthew’s Mission. Lieutenant patiently accepted the nun’s caring and ate a bowl of stew, and only when she suggested a new raincoat instead of Columbo’s beloved old one, he revealed his purpose.

UX research is no less challenging because we explore human behavior but inevitably influence the findings since we are humans, too. Designers often run the risk of receiving twisted information when they forget to tackle users’ fears and insecurity, for example:

  • Interviewees believe their boss sent you to assess their skills;
  • Users think you created this design, and now they try not to offend you;
  • Customers worry that you’ll judge their computer literacy.

Understating your official role gives you precious moments to talk with people more sincerely. In contrast, here is a perfect intro to annihilate research accuracy: “Hello! I’m a Senior UX Designer and Product Manager. Today, I’ll conduct a usability testing session and jobs-to-be-done interview to identify UX gaps in our design…” After hearing that, people would probably flood you with socially expected answers.

Instead, designers should keep their fancy titles to themselves. Try to start a usability testing session humbly, “My name is <…>, and I was asked to check whether this website is useful and clear to you.” Don’t make people think you designed it (even if you did).

And here is an intro phrase I recommend using for a user interview, “I’m a researcher, and today I’d like to ask you a couple of questions about <…>.” Give a simple description without redundant details that may scare people and increase tension.

Depending on the situation, you can even say, “I didn’t design this, so I won’t be offended if you criticize it; please be honest with your feedback!” But it’s on the thin edge between ensuring less biased research and lying.

Lesson 2: “You Don’t Know My Boss…”

Lieutenant Columbo usually dealt with wealthy and mighty criminals who were sure they would go unpunished. So, he played the role of a “little man” and wasn’t ashamed of it. He realized that exposing his authority would only make people stay within their own shells. Not only did he hide his intellect, but he also encouraged others to feel superior towards him so that people behaved more freely and revealed their true motives.

Columbo looked messy — in a creased beige raincoat, with a cigar, driving an old Peugeot — and concealed his shrewd mind behind this slack appearance and sloppy communication manner. He often told naive stories about his wife and appeared henpecked:

Columbo: I’m a worrier. I mean, little insignificant details, I lose my appetite, I can’t eat. My wife, she says to me, “You know, you can really be a pain.”

Another quote is about the “strict” boss, although it’s apparent from the series that the Lieutenant was a self-organized expert:

Columbo: You’re a celebrity. Because of you, my boss, he won’t let me close up this case until I have covered everything. Every loose end gotta be tied up.

As a newbie designer, I was indoctrinated about the value of presentation skills, making a positive first impression, and the necessity of defending design decisions. However, later, these conventions played a cruel joke on me.

In UX research, a common misconception is that you should look confident and competent in front of users. Let me get this straight: conducting research is not the same as presenting designs to top management. During any research, the goal is to make people feel relaxed so that they tell you the truth. However, at a presentation, the main task is to assure everyone that your decision is well-informed and your input helps steer the business in the right direction.

Research is not meant to show off. You see a user for the first and probably the last time in your life; they won’t influence your career; they aren’t here to be impressed. Behave humbly while staying in control of the session. Yes, you may come across as an ordinary person, but it’ll pay off and bring more insights compared to “boss-subordinate” or “expert-noob” paradigms. I’m not saying one should literally look messy like Columbo. The idea is to blend in, for instance:

  • Match interviewees’ dress code (within reason, of course).
    Try not to appear much more official or extravagant than a person in front of you, and you’d better keep that creative “Helvetica” T-shirt and “You ≠ user” pin for a UX meetup.
  • Avoid design jargon or terminology you have to explain.
    However, a reasonable dose of your interviewees’ professional lingo will boost communication if you work on a specialized topic.
  • Behave neutrally but naturally.
    It means balancing impartiality and separation from the subject with normal human behavior and empathy (simply saying, not being a robot).
Lesson 3: Deep-dive Into A New Topic

We call this approach “user safari” nowadays, but Lieutenant Columbo had been practicing it long before it became designers’ mainstream. If you want to understand your suspects (in our case, users), observe their behavior in a “natural habitat,” and don’t miss a chance to try users’ occupations. It’s better to see once than to hear a thousand times, right?

For example, in the episode “Any Old Port in a Storm” (S3E2), a wine connoisseur kills his brother to prevent him from selling the family winery. Columbo had to turn into a sommelier enthusiast for a while to investigate this crime and recognize unusual evidence, which would have been overlooked without specialized knowledge.

The episode “Negative Reaction” (S4E2) features a talented photographer and Pulitzer Prize winner who kills his wife and blames her death on a failed kidnapping. Columbo gets a camera and learns the basic principles of photography to convict the criminal. The detective had absolutely no proof, but owing to the newly gained knowledge, he set a cunning trap so that the murderer gave himself away.

Now, UX research. Of course, we shouldn’t literally follow the TV series and get expensive equipment just to step into users’ shoes. Fortunately, one can empathize much more easily nowadays. I mean observation studies and contextual inquiries when you can access users or documentaries, YouTube blogs, and professional communities if you want to prepare to face real users and avoid surface-level questions.

For example, several years ago, I was preparing for interviews with drilling engineers — future users of a new app suite for drilling planning. So, I watched “Deepwater Horizon,” a U.S. movie about a historical oil spill disaster in the Gulf of Mexico. This movie was recommended by a subject matter expert from the client’s side; he told me it realistically showed a drilling rig in action. As a result, I understood the technical jargon and used interviews with engineers to figure out really unobvious facts, not Wikipedia-level basics.

Another vivid example is a project I heard about from my former colleagues, who conducted product discovery for a Middle East logistics company several years ago. So, during an on-site, the discovery team observed the actual work of delivery crews and eventually witnessed a problem that couriers didn’t dare to report to their superiors. The app was designed for European address conventions and didn’t consider Middle-Eastern reality. Couriers only simulated using the navigation feature because the app required it to proceed to the next step. Frankly, I don’t believe this could’ve been learned from interviewing users or workshops with the client’s management.

Lesson 4: “Uhh… Just One More Thing!”

I guess Columbo used this catchphrase in each of the 69 episodes. In some cases, Lieutenant sounded like a narrow-minded, forgetful cop; sometimes, the question that followed “just one more thing” made a suspect worry. But does it have anything to do with UX research?

If we translate this phrase into modern language, we are talking about the skill of asking follow-up questions and improvising in pursuit of UX insights. Of course, our task in tech is way simpler than Columbo’s: we don’t have to provoke criminals to obtain irrefutable evidence for trial. But what detectives and UX folks share is the sense of valuable information and information buzz. This feeling pushes us to step aside from protocols and scripts and dig deeper.

“I have always found that plans are useless, but planning is indispensable.”
— Dwight Eisenhower

Even the best script for an interview, usability testing, or workshop won’t take into account all nuances.

In qualitative research, you cannot just read prepared questions out loud and call it a day; otherwise, it would’ve been already outsourced to robots.

I learned that what you want to know doesn’t equal the questions you ask.

  • Research questions are something you want to learn to make better design decisions. You keep them secret from respondents; they are only for your team’s internal use. For example, Will they buy this app? What is their top problem? Why are we worse than our competitors? In Columbo’s terms, they are equivalent to “Who is the murderer?”
  • Interview questions are what you actually ask. They are formulated in a certain way because not every answer can be retrieved directly. For example, Please tell me about the last time you ordered grocery delivery. How often do you buy non-fiction books online? They resemble Columbo’s “What did you do after 10 PM last Friday?”

While research questions are agreed upon with the team in advance, interview questions are left to the researcher’s discretion. For example, in one case, you ask a single “Tell me about the last time…” question and get tons of data from a talkative and relaxed person. But another respondent will give you a tiny piece of a puzzle at a time, and you’ll need to ask more granular questions, “What did you order? How did you choose? What payment did you choose? Why this option?” and so on.

Lesson 5: Don’t Take Words At Face Value

Why is “Columbo” so fun to watch? Because the Lieutenant always allows his suspects to justify themselves and compose plausible explanations in a naive attempt to ward off suspicion. I think the suspects should’ve kept silent instead of trying to divert Columbo’s investigation.

The iconic dialog between Columbo and Paul Gerard shows how early one can recognize lies. The episode “Murder Under Glass” (S7E2) tells about a food critic who extorted money from restaurant owners in exchange for positive reviews and poisoned one of them for fear of exposure.

Paul Gerard: When did you first suspect me?
Columbo: As it happens, sir… about two minutes after I met you.
Paul Gerard: That can’t be possible.
Columbo: Oh, you made it perfectly clear, sir, the very first night when you decided to come to the restaurant directly after you were informed that Vittorio was poisoned.
Paul Gerard: I was instructed to come here by the police.
Columbo: And you came, sir.
Paul Gerard: Yes.
Columbo: After eating dinner with a man that had been poisoned. You didn’t go to a doctor. You came because the police instructed you. You didn’t go to a hospital. You didn’t even ask to have your stomach pumped. Mr. Gerard, that’s the damnedest example of good citizenship I’ve ever seen.

Surprisingly, this strongly relates to UX.

All people lie. Influential stakeholders try to push forward their ideas. Some people desire to appear more knowledgeable than they are. Others are afraid to share opinions if they don’t know how they’ll be used. You can also find yourself in the center of office politics when officially declared messages contradict actual goals.

Due to classical UX doctrines, designers are called “user advocates” and broadcasters of the “user’s voice,” but it doesn’t mean we should listen to people indiscriminately.

If a person craves a feature but has zero examples of how something similar has helped them in the past, it might be an exaggeration. If a business owner says an app is successful but has only feedback from her colleagues, it may be overly optimistic. And so on. When we notice information discrepancies, the best choice is to continue asking questions, and then, maybe, your interlocutor will start to doubt their own words. For example,

Product owner: Hey, Ann! We need to have an export feature so that users can download nice-looking PDF reports.
Designer: Just for my understanding. Can you please explain the context of this feature idea?
Product owner: Well, I think it’s pretty clear. Export is a standard thing for engineering applications. Probably, there should be a button or icon above the dashboard; a user clicks, and then a PDF with our logo…
Designer: Jack, sorry for interrupting. I’m asking this not out of curiosity but because I want to get it right. If you remember the user interviews last month, engineers usually copy-paste data from the dashboard into a PowerPoint template with their company’s branding…
Product owner: That’s a very good question. I need to double-check it.

So, Columbo teaches us to trust but verify. Carefully listen to what you’re told, don’t show skepticism or suspicion, and continue asking questions until you reach the root cause of a problem.

Summary

Of course, the lessons I deduced from TV series aren’t even close to being comparable with mature research methodologies and UX culture. Unlike the time when I started my design career, today, I see more and more dedicated researchers who take care of insights that steer businesses in the right direction. So, I hope this article entertains you with unusual parallels between UX and fictional crime investigation.

If Lieutenant Columbo were a UX guru like Don Norman or Jacob Nielsen, he would probably give us the following advice:

  1. Don’t flash your fancy UX title without necessity.
  2. Don’t show off in front of users; this is not a job interview or top management presentation.
  3. Strive to observe users in context, in their “natural habitat.”
  4. Have plenty of contextual and follow-up questions up your sleeve.
  5. All people lie (often unintentionally). Double-check their words.

Further Reading

Using Friction As A Feature In Machine Learning Algorithms

A common assumption in user experience design is less friction makes apps more delightful. But in practice, the happy path isn’t always the smoothest. The term “friction” in the digital sense usually refers to anything that makes experiences cumbersome. It’s an analogy to the physical resistance that occurs when objects interact. Digital friction comes in many forms, from frustrating flows to confusing copy. But plenty of scenarios actually benefit with a bit of resistance. Its killer feature is mitigating unintended consequences, such as an accidental Alexa shopping spree.

You’ve likely already encountered intentional friction many times. Most apps leverage it for destructive actions, account security, and error handling, as recommended by experts from Norman Nielsen Group to the magazine you’re currently reading.

Yet friction has found a new calling in the age of artificial intelligence. When implemented correctly, it can improve the efficiency of AI systems such as machine learning algorithms. These algorithms are often used to personalize experiences through predictive recommendations. Some applications incorporating these algorithms realize that adding a bit of friction to their interface can turn each user interaction into an opportunity to improve algorithmic quality.

While less friction makes an app smoother, a bit more may make it even smarter.

Friction As A Feature

Before venturing down the AI rabbit hole, let’s explore some simple examples showcasing the basic benefits of friction in UX. These are a helpful foundation to build off as we ascend into more complex applications for machine learning algorithms. Regardless of your familiarity, this will ground the following lessons in first principles.

Preventing Unintended Consequences

A common use for friction is error prevention, the fifth entry in Jakob Nielsen’s list of usability heuristics. In scenarios with the potential for high-cost errors, such as irreversible deletion, apps often request confirmation before executing requests. Confirmations often display in a modal, locking the rest of the screen to increase focus on copy explaining an action’s implications. This extra step provides some extra time to consider these ramifications.

“By forcing us to slow down and think at this exact moment, we’re kept from making potentially disastrous decisions by accident.”

— Archana Madhavan in Amplitude’s “Onboarding With The IKEA Effect: How To Use UX Friction To Build Retention

Sometimes more resistance is present when the consequences can be catastrophic. For instance, a confirmation may involve cognitive work such as typing “DELETE” to submit a deletion request. This level of resistance makes sense when considering the humbling fact of life from Steve Krug’s classic UX book Don’t Make Me Think, which states, “We don’t read pages. We scan them.” This makes it easy to imagine how a streamlined design can make it too easy to overlook the consequences of a click.

While these tactics may look comically cumbersome, they mitigate devastating downsides. This use of friction is like a train’s brakes screeching to a halt right in time to avoid a collision — everyone breathes a sigh of relief, crisis averted. This also outlines the basic framework for understanding when to add friction. It boils down to a cost-benefit analysis: do the rewards of streamlining outweigh the risk? If not, slow it down. Now let’s move on from a black & white example to venture into a grayer area.

Nudging Toward Healthy Behavior

Some problems aren’t classifiable as errors but still aren’t in anyone’s best interest. Trying to solve them becomes wicked because there is no right or wrong solution. Yet that doesn’t make failing to address them any less of an existential risk. Consider social media’s medley of knee-jerk, tribalistic behavior. It has led many to question the value of these apps altogether, which isn’t good for business, or society at large. In an attempt to encourage more thoughtful discourse, these platforms turn to friction.

Twitter explored adding an extra step that asks people to read articles before retweeting them. This nudge aims to craft a more trustworthy experience for everyone by slowing the spread of misinformation. According to their reporting, people shown the prompt opened articles 40% more often, and some decided not to retweet it after all. They built on this success by showing a warning before users post messages which include harmful language.

Instagram also implemented a similar feature in its fight against online bullying. Adam Mosseri, the Head of Instagram, published a blog post stating that this “intervention gives people a chance to reflect.” Although specific data isn’t provided, they suggest it had promising results in cultivating a more humane experience for their communities.

These examples show how faster is not always better. Sometimes we need restraint from saying things we don’t mean or sharing things that we don’t understand. Friction helps algorithms in a similar manner. Sometimes they also need more information about us so they don’t recommend things we won’t appreciate.

Understanding Preferences & Objectives

Let’s shift focus to AI with a simple example of how friction plays a role in machine learning algorithms. You’ve probably signed up for an app that begins by asking you a bunch of questions about your interests. Behind the scenes, an algorithm uses these answers to personalize your experience. These onboarding flows have become so common over the past decade that you may have forgotten a time before apps were smart enough to get to know you.

You may have never even questioned why you must go through a preference capture flow before getting to explore content. The value is obvious because no one wants the quickest path to something irrelevant. Many apps are simply in the business of making relevant connections, and these personalization tactics have been one of the best ways to do so. A McKinsey report illuminates this further by reporting that “35 percent of what consumers purchase on Amazon and 75 percent of what they watch on Netflix come from product recommendations based on such algorithms.”

“The top two reasons that customers churn are 1) they don’t understand your product, and 2) they don’t obtain any value from it. Customer onboarding can solve both of these issues.”

— Christina Perricone in HubSpot’s “The Ultimate Guide to Customer Onboarding

Perhaps these onboarding flows are so familiar that they don’t feel like friction. They may seem like necessary steps to unlock an app’s value. However, that perspective quickly changes for anyone designing one of these flows. The inherent tension lies in attempting to balance the diametrically opposite needs of two parties. On the one hand, an algorithm provides better output relative to its input (although asymptotes exist). Success is a function of maximizing data collection touchpoints, but this tends to result in more steps with more complex questions.

In short, the quicker an app makes a recommendation, the more likely it will be wrong. On the other hand, an extremely long onboarding flow is unlikely to make an amazing first impression on new users. I had the pleasure of walking this tightrope when designing the onboarding flow at Headliner. Each new step we added always felt like it would be the straw that broke the camel’s back. We nervously monitored our activation reports for signs we went too far but surprisingly saw no meaningful dropoff. Yet, even a slight decrease would easily be worth the improved retention that personalization yielded.

This is thanks to some clever interface innovations. TikTok’s design turns user engagement into clear signals they use to tweak their algorithms. Content recommendation quality is a direct function of this, which some refer to as an algorithm’s vision.

Optimizing an app’s key interactions to understand implicit signals makes an explicit means of capturing preferences unnecessary.

Engagement Signals

Every interaction is an opportunity to improve understanding through bidirectional feedback. An interface should provide system feedback to the user engaging with it while also reporting to the system how performance meets user expectations. Everything from button taps to the absence of action can become a signal. Interfaces that successfully incorporate this are referred to as algorithm-friendly.

A study by Apple’s Machine Learning Research Department details their success in leveraging engagement signals, which they believe “provide strong indications of a user’s true intent,” to efficiently train a machine learning model through a process called Reinforcement Learning from Human Feedback. Their results documented “significant accuracy gains in a production deep learning system,” meaning that an interface designed well enough to analyze naturally occurring user behavior is all that is needed to create personalization that feels like mind reading.

Instagram actually employs this strategy as well, although its approach is a bit less cohesive since they seem to be in a perpetual state of transition.

TikTokification

But what exactly makes an interface algorithm-friendly? In TikTok’s case, it was the design decision to only show one video at a time. That’s right, friction! By decreasing the information density in the viewport at any given time, they increased their understanding of a user’s focus. This localizes interactions (or lack thereof) to specific content as quality measures.

Gustav Söderström, the Co-President, CPO & CTO at Spotify has referred to this approach as “giving the algorithm glasses.” Compare this to the medley of distractions in other feeds, and it’s easy to imagine which one is better at collecting data.

Using friction as a tool allows designers to craft an interface that separates engagement signals from noise.

Algorithmic visibility comparison of TikTok & Instagram’s home feeds. (Source: Maximillian Piras) (Large preview)

As we return to my aforementioned framework for evaluating when to add friction, we can understand how it makes sense in this scenario. While each interaction may take slightly longer, relevant content can be found quicker. The trade-off makes sense since relevance sits atop a user’s hierarchy of needs.

Additionally, if you were to measure friction over a longer time horizon, you likely would find an experience with better personalization feels more frictionless. This is because the efficiency in helping users find what they’re looking for would consistently compound (although, again, asymptotes exist). So each subsequent visit theoretically requires less work on the user’s part, which makes the alternate approach look like the cumbersome one.

“The secret of why some of these products are so good at recommendations is not actually that they have better algorithms. It’s the same algorithms with a more efficient user interface.”

— Gustav Söderström in The Verge’s “Why Spotify wants to look like TikTok

While TikTok popularized this interface, anybody who was single in the last decade may notice a similarity to dating apps. Using directional gestures as engagement signals dates back to the swipeable card paradigm Tinder introduced in 2012. They, too, limited the viewport to one result at a time and used actions to inform subsequent recommendations. But TikTok took it mainstream since not everyone needs a dating app, and those who do will churn once they’ve met someone.

The results of using this paradigm in everyday entertainment led many platforms to copy it in hopes of the same algorithmic gains. The latest to embark on this journey is Spotify, much to the chagrin of their users. In fact, this decision even landed it on Mashable’s list of worst app updates in 2023. But Söderström says they don’t have a choice, and he believes in the long run, the signal clarity will make up for any interim backlash because of how much quicker it can learn user preferences. Critics fail to realize how important these changes are for Spotify’s future.

In the machine learning age, apps with inefficient interfaces for signal analysis risk becoming uncompetitive.

Algorithmic visibility comparison of Spotify’s old & new home feeds. (Source: Maximillian Piras) (Large preview)

Making Lemonade

The reason this approach is so powerful is due to the compounding nature of good data. Optimizing signals for any individual user creates a data network effect that benefits everyone else. It even turns negatives into positives! An individual bad experience can mitigate others from encountering the same, making the system antifragile.

This approach dates back to 2003 with the introduction of Amazon’s item-to-item collaborative filtering. You may know it as “customers who viewed this also viewed this.”

This type of filtering produces high-quality recommendations with limited user data. It does so by building relationships between items to proxy user preferences. With only two to three data points, an algorithm can draw connections across the entire dataset. It effectively piggybacks off previous patterns that are similar enough.

This means an app like TikTok only needs a few swipes before it can make high-probability assumptions about your preferences. That’s why friction is so useful in algorithm-friendly interfaces. If the initial interactions send clean signals, then an algorithm can graph a user’s interests almost immediately.

Friction In The Future

We began in the past by reviewing how friction found its way into UX toolkits through error prevention and healthy nudges. Then we moved on to its ability to help algorithms learn user preferences and objectives. While explicit onboarding flows are still in vogue, TikTok is popularizing an interface that makes them unnecessary by using implicit engagement signals leading to significant algorithmic gains. Yet the machine learning age is just beginning, and friction is only accelerating its evolution.

Inverting The Pareto Principle

We’ve focused on algorithms that recommend content, but more diverse uses of personalization may emerge due to the newfound capabilities of Large Language Models. These models unlock the ability to manipulate unstructured data at scale. This allows engagement patterns of greater complexity to be analyzed and productized. The result is algorithms can recommend much more than media and metadata.

Perhaps they can craft completely personalized feature sets based on our preferences and objectives. Imagine selecting effects in Photoshop and seeing suggestions such as “Creators who used this effect also used this one.” These capabilities could increase the usage of buried features that only power users tend to find.

Microsoft is exploring this by adding Copilot to its products. They claim the “average person uses less than 10% of what PowerPoint can do,” but AI will unlock all that latent value.

Microsoft Copilot uses LLMs in an attempt to unlock the 90% of features that most users don’t know exist. (Source: Microsoft Design) (Large preview)

Using LLMs to create feature recommendation engines is a fascinating idea. It would allow developers to stop relying on the Pareto Principle for prioritization. Especially because Joel Spolsky claims the 80/20 rule is actually a myth.

“A lot of software developers are seduced by the old “80/20” rule. It seems to make a lot of sense: 80% of the people use 20% of the features… Unfortunately, it’s never the same 20%. Everybody uses a different set of features.”

— Joel Spolsky in “Strategy Letter IV: Bloatware and the 80/20 Myth

It would be nice if irreducible simplicity in interface design were only a power law away, but feature creep is hard to combat when different people find value in different options. It’s unrealistic to believe that there is some golden 20% of features driving 80% of value. If there was, then why isn’t the Pareto Principle ever applied to content?

I can’t imagine a team at YouTube suggesting that removing 80% of videos would improve the service. Instead, it’s viewed as a routing problem: find the right piece of content for the right person. If machine learning algorithms can recommend features, I hope the value of friction goes without saying at this point. The efficiency gains unlocked by algorithm-friendly interfaces absolutely apply.

Hallucinations Or Creations

The recent inflection point in the capability of LLMs unlocks an entirely new computing paradigm. The legendary UX researcher Jakob Nielsen believes it introduces the first new UI paradigm in 60 years, which he calls Intent-Based Outcome Specification. Instead of telling computers what to do, we now explain an outcome so they can determine how to achieve it.

Using machine learning algorithms to recommend features is one example. Another fairly new example that you’re likely familiar with is chatbots like ChatGPT. Hundreds of millions of people already use it, which is a testament to how out of this world the experience is. Yet therein lies a problem: sometimes its responses literally aren’t grounded in reality because it has a tendency to make them up! This isn’t obvious to those unfamiliar with the technology’s inner workings since there aren’t many safeguards. As a result, some people become dangerously overreliant on its unverified output.

In one case, a lawyer based legal arguments on research from ChatGPT only to find out in court that multiple cited sources turned out to be completely nonexistent. The lawyer’s defense was that he was “unaware of the possibility that its content could be false.” Examples like this reinforce the importance of friction in preventing unintended consequences. While ChatGPT’s empty state mentions its limitations, they obviously aren’t stated explicitly enough for everyone.

Extra steps and prompts, such as those mentioned earlier, could better educate users about what is referred to as a “hallucination.” It’s a phenomenon of chatbots confidently outputting responses that don’t align with their training data. Similar to telling a lie when you don’t have a correct answer, although that characterization overly anthropomorphizes the software.

Yet some see hallucinations as more of a feature than a bug. Marc Andreessen, the co-founder of Netscape, states during an interview that “another term for hallucination is just simply creativity.” He views it as a significant evolution from the hyperliteral systems of the past because they can now brainstorm and improvise.

The problem is that chatbot interfaces tend to be simplistic by attempting to be one size fits all. More controls or modes would educate users about available output types so they can specify which they expect. Sometimes we may want an imaginative response from a creative partner. Other times we want the hyper-accuracy of a deterministic calculator, such as ChatGPT’s Wolfram plugin.

Perhaps a creativity slider or persona selector similar to Maggie Appleton’s exploration will better align the system to user needs. However it’s implemented, a bit of friction can maximize benefits while minimizing risks.

Finding Your Friction

We’ve covered using friction for simple error prevention to complex algorithm optimizations. Let’s end with a few tips that make implementing it as smooth as possible.

Peak-End Rule

When adding resistance to an experience, the Peak-End Rule is a useful psychological heuristic to leverage. It’s rooted in studies by Daniel Kahneman & Amos Tversky, where they found that perception of painful experiences doesn’t tend to correlate with duration. It’s the peak & end of the experience that subjects recall.

In practice, experts suggest that delight is a function of positive emotional peaks and rewarding emotional payoffs. Optimizing for the peak & end provides room to shift focus from time spent and steps taken as performance indicators; long and complex experiences can still be delightful if designed correctly.

Maps Aren’t Territories

People experience friction emotionally, but developers see it as a value on a chart. In the same way that a map is not a territory, this ratio is only an approximation of the actual experience. It’s something to consider when evaluating any strategies for adding or removing friction. Since applications are complex ecosystems, any measurements should consider a holistic view. Every step has second-order effects, which makes one-dimensional measurements prone to blind spots.

For example, when a wrong file is deleted, the data can’t report people cursing at their computer screen. Nor is it likely to include the context of them opening a new file just to recreate their old file from scratch. The same subjectivity applies to all instances of friction. For instance, are your reports equipped to measure the trade-off of an action that takes longer but results in better data collection? It might increase algorithmic efficiency, which compounds across a neural network.

As we’ve discussed, better recommendations tend to yield better retention, which tends to yield more revenue if a business model aligns with usage. Myopic measurements will miss these types of gains, so make sure to analyze friction in a way that really matters.

Keep Pushing

As software is eating the world, AI is eating software. If it’s a paradigm shift as big as social, mobile, or even the web, then applications must adapt or die. If you want to remain competitive in the machine learning age, then don’t fear friction.

Further Reading on Smashing Magazine

How To Create A Rapid Research Program To Support Insights At Scale

While the User Experience practice has been expanding and will continue to balloon in the coming years, so have its sub-disciplines such as content strategy, operations, and user research. As the practice of UX Research matures, scalability will continue to be important in order to meet the rapid needs of iterative product development.

While there are several effective ways to scale user research, such as increasing researcher-to-designer ratios, leveraging big data and real-time analytics, or research democratization, one of the most effective methods is developing a Rapid Research program. In a Rapid Research program, teams are provided quick insight into key problems at an unprecedented operational speed.

Rapid Research-type support has been around for a while and has taken different shapes across different organizations. What remains true, however, is the goal to provide actionable insights from end-users at a quick pace that fits within product sprints and maintains pace with agile development practices.

In this article, I’m going to unpack what a Rapid Research program is, how to build one in your organization, and underscore the unique benefits that a program like this can provide to your team. Given that there is no singular ‘right way’ to scale insights or mature a user research practice, this outline is intended to provide building blocks and considerations that you may take in the context of the culture, opportunities, and challenges of your organization.

What Is Rapid Research?

Rapid research is a relatively recent program where typical user research practices and operations are standardized and templatized to provide a consistent, repeatable cadence of insights. As the name suggests, a core requirement of a rapid research program is that it delivers quicker-than-average insights. In many teams, this means delivering research on a weekly cadence where a confluence of guardrails, templates, and requirements work to ensure a smooth and consistent process.

Programs like Rapid Research may be created out of a necessity to keep up with the pace of development while freeing the bandwidth of expert researchers’ time for more complex discovery work that often takes longer. A rapid research program can be a crucial component of any team’s insight ecosystem, balanced against solving different business problems with flexible levels of support.

Scope

Research Methods

In order to make research more rapid, teams may consider some research methodologies out of the question in their Rapid Research program. Methods such as longitudinal diary studies, surveys, or long-form interviews might suffer from lower quality if done too quickly. When determining the scope of your rapid research program, ask yourself what methods you can easily templatize and, most importantly, which best support the needs of your experience teams.

For example, if your experience teams work on 2-week sprints and need insights in that time, then you will need to consider which research methods can reliably be conducted in 1–2 week increments.

Sample Size And Research Duration

Methods alone won’t ensure a successful implementation of a rapid research program. You will also need to consider sample size and session duration. Even if you decide usability tests are a reasonable methodology for your rapid research framework, you may be introducing too much complexity to run them with 15+ users within 60-min sessions and analyze all that data efficiently. This may require you to narrow your focus to fewer sessions with shorter duration.

Participant Recruitment

While there may be fewer and shorter sessions for each study, you also need to consider your participant pool. Recruitment is one of the most difficult aspects of conducting any user research, and this effort must be considered when determining the scope of the program. Recruitment can jeopardize the pace of your program if you source highly specific participants or if they are harder to reach due to internal bureaucracy or compliance constraints.

In order to simplify recruitment, consider what types of participants are both the easiest to reach and who account for the most use cases or products you expect to be researching. Be careful with this, though, as you don’t want to broaden your customer profiles too much for fear of not getting the helpful feedback you need, as UserZoom says:

“Why is sourcing participants such a challenge? Well, you could probably find as many users as you like by spreading the net as wide as possible and offering generous incentives, but you won’t necessarily find the ‘right’ participants.”

— UserZoom, “Four top challenges UX teams face in 2020 and how to solve them

Timing

Why Timing Matters

Coupled tightly with scope, the timing of your rapid research end-to-end process will be paramount to the program’s success. Even if you have narrowed the scope to only a handful of research methods with limited sessions at shorter durations and with specific participant profiles, it won’t be ‘rapid’ if your end-to-end project timeline is as long as your average traditional study. Care must be taken to ensure that the project timelines of your rapid research studies are notably quicker than your average studies so that this program feels differentiating and adds value on top of the work your team is already doing.

Reconsidering scope

If your timelines are about the same, or your rapid cadence is less than 50% more efficient than your average study, consider whether or not you’re being judicious enough in your scope above. Always monitor your timelines and identify where you can speed things up or limit the scope in order to reach a quick turnaround, which is acceptable. One way to support shorter project timelines is through compartmentalization.

Compartmentalization

About Compartmentalization

One way to balance scope, timing, and consistency is by breaking up pieces of your average study process into smaller, separate efforts. Consider what your program would look like if you separated project intake from the study kick-off or if discussion guides were not dependent on recruitment or participant types. Splitting out your workflow into separate parts and templating them may eliminate typical dependencies and streamline your processes.

Ways To Compartmentalize

Once you’ve determined the set of research methods and ideal participants to include in your program, you may:

  • Templatize the discussion guides to provide a quick starting point for researchers and cut down on upfront preparation time.
  • Create a consistent recruitment schedule independent of the study method to start before study intake or kick-off to save upfront time.
  • Pre-schedule recurring kick-off and readout sessions to set expectations for all studies while limiting timeline risk when at the mercy of others’ calendars.

There is a myriad of opportunities to do things differently than your typical research study when you reconsider the relationships and interdependencies in the process.

Consistency

Expectability

While a quality rapid research program takes into consideration scope, timing, and compartmentalization, it also needs to consider consistency. It would be difficult to discern whether or not the program was ‘rapid’ if, on one week, a study takes one week, and on another week, a study takes 2.5 weeks. Both may be below your current study average. However, project stakeholders may blur the lines between the differences in your rapid studies and your typical studies due to the variability in approach. In addition, it may be difficult to operationalize compartmentalization or rapid recruitment without some form of expected cadence.

More Agility

As you and your team get used to operating within your rapid cadence, you may identify additional opportunities to templatize, compartmentalize or focus scope. If the program is inconsistent from study to study, it may be more difficult to notice these opportunities for increased agility, hindering your program from becoming even more rapid over time.

A Rapid Research Case Study

While working at one of the largest telecommunications companies in the US, I had the privilege of witnessing the growth of the UX Research team from just four practitioners to over 25 by the time I left. During this time, the company had matured its user experience practice, including the standards, processes, and discipline of user research.

Identifying The Need

As we grew, human insight became a central part of the product development process, which meant an exponential increase in its demand. While this was a great thing and allowed our team to grow, the work we were doing was not sustainable — we were constantly trying to keep pace with product teams who brought us in too late in the process simply to validate their ideas. Not only did we always feel rushed, but we were stuck doing only evaluative work, which not only stifled innovation but also did not satisfy our more senior researchers who wished to do more generative research.

How It Fits In

Once diagnosing this issue, our leadership initiated several new processes to build a more well-rounded research portfolio that supported iterative research while enabling generative research. This included a democratization program, quarterly planning, and my initiative: Rapid Research. We determined that we needed a program that would allow us to take on mid-sized projects at the pace of product development while providing a new opportunity to hire junior researchers who would be a great talent pool for our team and provide a meaningful way for those new to the field to grow their skills.

Getting Started

In order to build the rapid research program, I audited the previous year’s worth of research to determine our average timelines, the most common methodologies used for iterative and mid-sized projects, and to identify our primary customer who we do research with most often. My findings would be the bedrock of the program:

  • Most iterative research was lite interviews and brief usability tests.
  • Many objectives could be covered in 30-minute sessions.
  • Mid-sized projects were often with just a handful of current customers.
  • Our average study time was 2–3 weeks, so we’d need to cut this down.
  • Given the above constraints, study goals should be highly focused.

Building The Program

At first, we did not have the budget for hiring new junior researchers to staff the program team. What we did have, however, was a contract with a research vendor who we’ve worked with for years, so we decided to partner with researchers from their team to run our rapid research program.

  • We created specific templates for ‘rapid’ usability tests and interviews.
  • Studies were capped at two objectives and only a handful of questions in order to fit into 30-min sessions.
  • Study intake was governed via a simple intake form, required to be filled out by EOD every Wednesday.
  • We scheduled standing kick-off and readout sessions every Friday and shared these invites with product teams for visibility.
  • To further establish our senior researchers as Portfolio Research Leads and to protect against scope creep, we required teams to formally request ‘rapid’ studies through them first.
  • We started our rapid cadence at two weeks and were able to cut it down to just one week after piloting the program for a month.

Strong Results

We saw the incredible value and strong results from building our rapid research program, especially alongside the other processes our team was standing up to support varying insights needs.

  • Speed
    We were able to eventually run three research studies simultaneously, enabling us to deliver more research at twice the pace of a traditional study.
  • Scale
    Through this enablement of speed, consistent recruitment, and templatized process, we ran over 100 studies & 650+ moderated interviews.
  • Impact
    Because we outsourced rapid research to a vendor, our team was freed up to deliver foundational research, which doubled our work capacity.
  • Growth
    Eventually, we hired junior researchers and transitioned the program from the vendor, increasing subject matter expertise & operational efficiency.
How To Build A Rapid Research Program

The following steps outline a process for getting started with building your own rapid research program in your organization. Exactly which steps you choose to follow, or if you decide to add more or less to your process, will be entirely up to you and the unique needs of your team. Follow the proceeding steps while considering the above guidelines regarding scope, timing, compartmentalization, and consistency.

Determine If You Even Need A Rapid Research Program

While seemingly counter-intuitive, the first step in building a rapid research program is considering whether you even need one in the first place. Every new initiative or tactic intended to mature user research practice should consider the available talent and capabilities of the team and the needs or opportunities of the organization it sits within. It would be unfortunate to invest time to build a robust, rapid research program only to find that nobody uses or needs it.

Reflection On Current Needs

Start by documenting the needs of your experience teams or the organization you support by the different types of requests you receive.

  • Are you often asked to deliver research faster?
  • What are the types of research which are most often requested?
  • Does your team have the capability or operational rigor required to deliver at a faster pace?
  • Are you staffed enough to support a more rapid pace, even if you could deliver one?
  • Is delivering faster, rigidly-scoped research in service to your long-term goals as a research team, or might it sacrifice them?

Gather More Information

Answering these questions should be your first step before any meaningful work is done to build a rapid research program. In addition, you might consider the following information-gathering activities:

  • Audit previous research you or your team have done to determine their average scope, timeline, and method.
  • Conduct a series of internal stakeholder interviews to identify what potential value a rapid research program might hold.
  • Look for signals for where the organization is going. If leadership is hiring or training teams on agile methods or demanding teams to take a step back to focus on discovery can help you decide when and where to invest your time.

These additional inputs will either help you refine your approach to building a program or to steer away from doing so.

Limitations Of Rapid Research

Finally, when considering if you should build a rapid research program in the first place, you should consider what the program cannot do.

  • What a rapid research program might save on time, it cannot necessarily save on effort. You will still need researchers to deliver this work, which means you may need to restructure your team or hire more people.
  • If you decide to make your rapid research program self-service, you likely will still need ResOps support for recruitment and managing the intake process effectively.
  • It is also possible to hire a research vendor partner to lead this program, though that will require a budget that not every team may have.
  • As mentioned above, a good rapid research program is tight and focused in its scope, which limits the type of projects it can accommodate.

Identify Your Starting Scope, Timing & Cadence

Once you’ve decided to pursue a rapid research program, you’ll need to understand what form your program should take in order to deliver the highest value to your team and those you support. As mentioned above, a right-sized scope should consider the research methods, requirements, session quantity & duration, and participant profiles, which you can confidently accommodate. And you will need to determine the end-to-end timing and program cadence that differentiates from current work while providing just enough time to still deliver sustainable quality.

Determine Participant Profiles

Start building your scope backwards from the needs gaps you’re filling within your team based on the answers to the discovery questions above. You’ll want to identify the primary type(s) of end-users this program will research.

  1. Audit the past 6–12 months of research you or your team has done, looking at the most common customer type with whom you do research.
  2. Then, couple that with any knowledge you may have of where the business or your experience teams will be focused for the following 6–12 months.

For example, if your audit revealed that your team had focused most frequently on current customers over the past year, and you also know that your business will soon focus on the acquisition of new customers, consider including both current customers and prospective customers in your rapid research scope.

Remember the important note about consistency above? Once you’ve identified potential participant profiles, make sure you can consistently recruit them. For example, if you use a research panel to source participants for research studies, test the incidence of your participant profiles. If you find they don’t have many panelists with the attributes you need, you might spend too much time in recruitment and jeopardize the speed of the program.

A balance should be struck between participant profiles that are specific enough to be useful for most projects and those broad enough to reach easily.

Determine Research Methods

You can conduct the same audit and rough forecasting when determining the research methods your program ought to support but with two additional considerations:

  1. Team strategy,
  2. Individual career development.

User researchers tend to focus their work further upstream, where they’re driving product roadmaps or influencing business strategy. This can bode well for your rapid research program if it is focused on evaluative research projects, which are often quicker and cheaper to conduct.

The ultimate goal is for the rapid research program to be a complement to what your team provides or as an enabler for freeing up their bandwidth so that they can focus on the type of work they want to do more of.

Right-size Research Methods

Once you’ve determined which research methods you want to include in your rapid research program, consider the level of rigor you need to balance effort and complexity.

Determining Timelines

Project timelines within a rapid research cadence are directly affected by the above scope decisions for participant profiles and research methodology. Timelines can also compound in highly regulated industries such as healthcare or banking, where you may be required to gather legal & compliance approval on every moderation guide. In order to call this a rapid research program, the end-to-end project timelines need to be shorter than a typical project of a similar scope, or at least feel that way.

  1. Scope current minimum effort
    Start by jotting down the minimum amount of time it takes a researcher on your team to do each sub-step in your current non-rapid research process. Do this for the same participant profiles and methods you want to include in your rapid research program.
  2. Dependencies
    Now, identify which sub-steps are dependent on others and think of ways to program them in order to build efficiency. For example, if you need legal approval on every moderation guide before data collection, which takes 2–3 days, see if Legal will commit to a change to a 24-hour SLA for rapid research-specific projects. Another example is if you typically give stakeholders a few days to provide feedback on moderation guides, change this for rapid research projects to cut down dependency time.
  3. Identify compartmentalization
    In addition to programming project dependencies, consider the above guidance for compartmentalizing some of the programs in order to remove dependencies entirely, such as with recruitment. Identify what parts of the process don’t have the same dependencies in your rapid research program and can be started earlier. By removing dependencies entirely, you may be able to do several things simultaneously to speed up project timelines.

Once you’ve documented your current research process (steps, dependencies, timing) and the changes you need to make to build efficiencies or remove dependencies, document what ‘must be true’ in order to consistently deliver identified changes. Create a table to document all of these details, then sum up the total timelines to compare your typical end-to-end research project timeline with your potential new ‘rapid’ timeline.

Ask yourself if this seems ‘rapid’ when stacked against your average study duration.

  • If not, look back at the guidance above. Ask yourself if there are other customer types that may be easier to get in front of that you haven’t considered. Consider whether you need to create a new process, expedite existing processes, or create new relationships in order to make your timelines even more rapid.
  • If so, congratulations! You might have just landed on the right scope for your rapid research program. Consider whether this new rapid timeline is something that you can deliver consistently and reliably over time and whether or not you have enough access to participants, and enough budget, to carry out this cadence long-term.

Build Infrastructure, Standards & Rules

It’s time to set the foundation. Return back to the tables you made above and create an action plan with the following steps and a timeline to build the infrastructure required to bring your program to life. As part of this, you’ll need to establish the rules and standards for communicating with partners. You might consider a playbook and formal scope document to inform others of the ins/outs of the program.

Gather Buy-in

Prioritize any work that requires buy-in, generating understanding, or acquiring budget first before spending your time and energy building templates or documentation. You wouldn’t want to create a 20-page scope document outlining the bandwidth for two researchers, a limit to 1 round of stakeholder feedback, and a 24hr SLA for legal approval, only to find out others cannot commit to that.

Create Templates

You’ll need plenty of templates, tools, and processes specific to the scope of your program.

  • If you’re limiting moderation guides to a maximum of 10 questions, then create a specific discussion guide template reflecting that.
  • If your data analysis will be sped up by using structured note-taking templates, create those.
  • If you’ve determined that all rapid research projects only require an executive summary one-pager, make that too.

Staffing

As mentioned above, even a drastically reduced version of your typical research processes still requires effort to support. You’ll need to determine, based on the expected scope and cadence of each rapid research project, how many researchers and/or research operations coordinators you’ll need to support the program. While all rapid research programs will require dedicated effort, there are creative ways of staffing the program, such as:

  • A dedicated team of 1–2 researchers and 1–2 Ops coordinators to deliver projects with the greatest efficiency and quality.
  • A dedicated team of 1–2 researchers who also handle the operations of running the program itself.
  • A self-service program, with 1–2 Ops coordinators for supporting anyone doing the research work.
  • Outsourcing the entire program to a vendor.

Work with your leadership, HR, and TA professionals on securing approval for any team restructure, needed headcount budget, or to onboard a new vendor. Then, take the appropriate steps to hire your next researcher or secure the staffing help you need to support your program.

Coaching And Guidance

Consider training, coaching, and check-in meetings as part of your infrastructure.

  • If you are staffing new researchers to this rapid research program, make sure they understand the expectations and have what they need to succeed.
  • If you’re implementing a self-service model, provide brown-bag sessions to partners to explain the program do’s and don’ts.
  • Schedule quarterly check-ins with partners and leadership to discuss the program accomplishments and any needed adjustments to ensure it stays relevant.

Pilot, Get Feedback, And Iterate Over Time

No matter how much preparation you do or how much time and effort you spend building the alliances, infrastructure, training, and support required to run your rapid research program effectively, you will learn that there are improvements you should make once you put it into practice.

There are many benefits to piloting a new program in an organization. One benefit is that it can mitigate risks and allow teams to learn quickly and early enough to make positive enhancements.

“Piloting offers a realistic preview experience for users at the earliest stages of development. It allows the organization and design team to gather real-time insights that can be used to shape and refine the product and prepare it for commercialization.”

— Entrepreneur, “Tasting As You Go: The 5 Benefits of ‘Piloting’

This means setting expectations early. Consider your first few projects as pilots and expect them to be rocky and imperfect. Use this to your advantage by asking stakeholders you’re closest with to be your trial projects and let them know how important their honest feedback is throughout the process. Ensure that you have clear mechanisms to gather feedback at each project milestone so that you can track progress. It is especially important to capture what might be slowing you down along the way or putting your ‘rapid’ timelines at risk.

Program Evolutions, Impacts & Considerations

Potential Evolutions & Variations

While I’ve outlined a process for getting started, there are many ways in which your rapid research program may evolve over time to meet the needs of your organization better.

  • After a few periods, you might identify volume isn’t as high as you anticipated, so you extend the 1-week timeline to every two weeks.
  • After a few months, your business might launch a new product line, requiring you to consider a new set of customer profiles in recruitment.
  • You may decide to leverage your rapid cadence for individual segments of a longitudinal diary study to accommodate new methods.
  • You might use rapid research projects to exclusively evaluate in-market products while others on the team focus on in-progress / new products.
  • Rapid research projects could be a stage-gate for larger projects — proving a customer need before larger time investments are made.

However your rapid research program takes shape, revisit its goals, scope, and operations often in relation to your organizational needs and context so that it remains relevant and delivers the highest impact.

Solid Impacts From Rapid Research

Building a rapid research program can have a big impact and can contribute positively toward your team’s long-term strategy. One impact of instituting a rapid research program could be that now your team is freed up to focus on more generative research, which unlocks your ability to deliver deep customer insights that pave the way for innovation or strategy. And due to your new rapid pace, you may be able to keep pace with agile development and conduct end-to-end research within 2-week sprints. Another impact is that you may catch more usability issues further upstream, saving you over 100x in overhead business cost. A final impact of a rapid research program is that it can double your team’s throughput, allowing your team to deliver more research, more frequently, to accommodate more organizational needs.

Be sure to track these impacts over time so that you not only get credit for the hard work you put into building the program but so that you can sustain and grow the program over time.

Considerations When Building A Rapid Research Program

As mentioned in this article, there are many benefits to building a rapid research program. That being said, there are limitations to rapid research in regard to its pros and cons when it should be used, and if you have the available time to stand up a program yourself.

Pros And Cons

As with building any new program, one should consider both its benefits as well as drawbacks. Here are a few for rapid research programs:

Pros:

  • Can free time for foundational work;
  • Rapid studies may keep a better pace with development cycles;
  • Can create meaningful opportunities for junior staff;
  • Can double project throughput, increasing output volume.

Cons:

  • Still requires work and dedicated bandwidth;
  • Another thing to diligently track and manage;
  • Not great for all types of research studies;
  • May cost more money or resources you don’t have.

Guidance For Using The Program

Rapid Research programs are best for specific types of research which do not take a long time to complete or require rigorous expertise. You may want to educate your partners on when they should expect to use a rapid research program and when they should not.

  • Use rapid research when:
    • Agility or quick turnaround is needed;
    • You need simple iterative research;
    • Stakeholder groups are easier to rally;
    • Participants are easy to reach.
  • Do not use rapid research when:
    • The study method cannot be done quickly without risking quality;
    • A highly complex or mixed-methods study is needed;
    • A project requires high visibility or stakeholder alignment;
    • You have specific, hard-to-reach participants.

Ramp Up Time

While the exact timeline of building a rapid research program varies from team to team, it does take time to do it right. Make sure to plan out enough time to do the upfront work of identifying the appropriate scope, timing, and cadence, as well as gathering consensus from leadership and appropriate stakeholder groups. Standing up a Rapid Research program can take anywhere from 3 months to 1 year, depending on the following:

  • Legal and compliance limitations or requirements.
  • The number of stakeholder groups you need buy-in from.
  • Approval of budget for outside vendors or for hiring an in-house team.
  • Time it takes to build templates, guidelines, and materials.
  • Onboarding, training, and iteration when starting out.
Conclusion

A rapid research program can be a fundamental part of your team’s UX Research strategy, enabling your team to take on new insight challenges and deliver efficient research at an unprecedented pace. Building a rapid research program with high intention by determining the goals, appropriate scope, and necessary infrastructure will set your team up for success and enable you to deliver more value for your organization as you scale your user research practice.

Don’t be afraid to try a rapid research program today!

Further Reading On SmashingMag

Conducting UX Surveys: A Practical Guide

UX surveys can be pivotal tools for designers seeking to understand user preferences, opinions, and behaviors. They foster alignment between design strategies and user expectations and can improve product or service usability. Our overview unravels the process of conducting UX surveys, highlighting how both quantitative and qualitative approaches can yield essential user insights.

The UX Designer Toolbox

Unlimited Downloads: 500,000+ Wireframe & UX Templates, UI Kits & Design Assets Starting at only $16.50 per month!

Conducting UX Surveys: Their Role and Execution

UX surveys serve as channels to collect insights directly from users about a product or service. They come in various forms, from online questionnaires to in-person discussions. These surveys aim to acquire both qualitative and quantitative data about user satisfaction, ease of use, and areas of potential improvement.

Conducting UX surveys follows a structured process. You begin by setting clear goals, and deciding what you aim to learn from the users. Then, you design a set of questions that invite insightful and actionable responses. Following the data collection, the task of data interpretation begins, leading to design changes that respond to the user’s needs.

Quantitative vs Qualitative: A Balancing Act

Quantitative surveys are useful when your goal is to collect numerical data. These types of surveys are great for tracking metrics such as usage frequency, user demographics, or user preferences. They offer the advantage of capturing data from a large audience, which can then be statistically analyzed to discern broader patterns and trends.

However, qualitative surveys offer something different. They are used when you want to dive deeper into the user’s thoughts, emotions, and experiences. Crucially, open-ended questions are the cornerstone of qualitative surveys, encouraging users to express their opinions freely. Although they might not yield broad statistical data, qualitative surveys provide detailed, nuanced information that can be invaluable for your design process.

Effective UX Survey: The Practical Steps

A well-designed UX survey is a careful process, requiring both strategic thinking and an empathetic understanding of your users. We’ll observe some of the indispensable steps that can guide your survey creation.

Objective Setting

Every UX survey must start with clear objectives. Whether you’re seeking to understand user behavior, assess user satisfaction, or gather feedback on a new feature, defining these goals will steer the development of your survey. It influences the kind of questions you will ask, the selection of respondents, and even the choice of the survey method. Clear goals ensure the collected data is genuinely useful and purpose-driven for your design strategy.

Drafting and Revision

The initial draft of your survey questions serves as a blueprint that should ideally be subjected to a review process. Don’t hesitate to involve your team, respected peers, or mentors in refining the questions. Their feedback will help eliminate ambiguities, prevent biased questions, and ensure the questionnaire resonates with your target audience.

Choosing the Right Platform

Selecting the most suitable platform for your UX survey significantly affects response rates and data quality. The nature of your survey – whether it’s a quick poll, an in-depth questionnaire, or an interactive survey – plays a huge role in this decision. Other factors to consider include the complexity of your survey, the technical competency of your target demographic, the platform’s user-friendliness on various devices, its visual appeal, and cost-effectiveness.

Question Design

The construction of your questions can be vital for the insights you gather. Close-ended questions, such as multiple-choice or Likert scale items, provide structured responses that are easier to analyze and compare. Meanwhile, open-ended questions encourage users to express their thoughts freely, providing deeper context and insight into their experiences. The key is to strike a balance: ask specific, direct questions to capture hard data, and open-ended ones to allow space for unexpected but valuable feedback.

Strategic Question Ordering

The placement of questions in your survey requires careful thought. Given the reality that some respondents will not complete the entire survey, it’s practical to position the most critical questions at the beginning. With this, you can somewhat secure the most valuable data, regardless of whether the user completes the entire questionnaire. Still, ensure a natural flow that doesn’t feel abrupt to the participant.

Testing the Waters

Prior to a full-scale launch of the survey, it’s beneficial to conduct a pilot test with a smaller, yet representative, sample of your user base. This approach allows for the identification and rectification of any potential issues – from ambiguous questions and technical glitches to unexpectedly long completion times. Moreover, pilot testing provides an opportunity to assess the survey’s ease and relevance, ensuring that the final version is as refined as possible before it reaches all users.

Wrapping Up

UX surveys can yield valuable user perspectives, but they should be seen as guides rather than definitive decision-makers in design choices.

Additionally, remember that a survey is a time commitment for your users. Avoid deterring completion or introducing response bias by overloading it with questions. Aim for a concise, engaging survey with a balance of question types.

Instead of duplicating data from analytics, use surveys to uncover user motivations, thoughts, and feelings that analytics can’t capture.

Lastly, consider both the user experience and your analysis capabilities when formatting questions. Open-ended questions offer rich insights but can overwhelm users and complicate analysis. Pilot-test these questions and refine them based on feedback. Some may work better as closed-ended questions for easier response and analysis.

For additional insights on managing broader yet valuable UX aspects, such as minimizing decision fatigue, feel free to check out this article.

How to Optimize UX Design for Screen Readers

Creating a user experience that is accessible and inclusive to all visitors, including those who rely on assistive technologies like screen readers, is a priority for any modern website. This article provides an outline on adapting UX design for screen readers, an important step in shaping an inclusive digital ecosystem.

Screen Readers: Vital Tools for Accessible Experiences

Screen readers interpret digital content for visually impaired users by converting visual information into speech or Braille. A tailored UX design for screen readers requires understanding this linear, sequential content interpretation and its influence on web navigation.

Strategies for Adapting UX Design for Screen Readers

The following approaches offer a basis for creating a more accessible UX design for screen readers. They call for deliberate implementation, meticulous attention to detail, and ongoing refinement:

Standardized Layouts

Visually impaired users appreciate predictability and consistency. Consistent layouts across your website allow users to predict element locations, facilitating smoother navigation.

Contextual Labels

Links and buttons should offer insight into their function upon activation. For example, a button labeled “Download Accessibility Guide” provides clearer information than a simple “Click Here.”

Image Alt Text

Detailed alt text for images helps screen readers convey the content and context of the image, enhancing users’ understanding of the overall content.

Accessible Forms

Screen readers should be able to interpret form controls accurately. Adequate labeling of each form field can significantly improve the user interaction experience.

Logical Content Structure

Content should be sequenced logically, given that screen readers interpret information top-to-bottom. The narrative should be coherent when read in this manner, with key messages strategically placed.

A study by the Nielsen Norman Group provides valuable insights into the unique challenges of using screen readers on mobile devices. It underlines the importance of thoughtful, native accessibility improvements as opposed to reliance on third-party solutions.

Wrapping Up: The Way Forward in UX Design for Screen Readers

The outlined strategies serve as an introduction to the ongoing pursuit of accessible UX design for screen readers. This journey entails consistent fine-tuning of your design based on user feedback and changing accessibility standards.

Building a genuinely inclusive digital platform requires understanding and empathizing with your users’ experiences. By making your website more accessible, you don’t just contribute to a more inclusive digital world—you potentially expand your user base and increase your business growth.

Remember, inclusivity is more than a best practice; it’s an ethical responsibility and a potential competitive advantage. It’s a process of striving towards a digitally accessible future, recognizing the challenges, and continuing to learn and improve.

Testing Sites And Apps With Blind Users: A Cheat Sheet

This article focuses on the users of screen readers — special software that converts the source code of a site or app into speech. Usually, these are people with low vision and blindness but not only. They’ll help you discover most accessibility issues. Of course, the topic is too vast for a single article, but this might help to get started.

Table Of Contents Part 1. What Is Accessibility Testing?

1.1. Testing vs. Audit

There are many ways of evaluating the accessibility of a digital product, but let’s start with distinguishing two major approaches.

Auditing is an element-by-element comparison of a site or app against a list of accessibility requirements, be it a universal standard (WCAG) or a country-specific law (like ADA in the U.S. or AODA in Ontario, Canada). There are two ways to do an audit:

  1. Automated audit
    Checking accessibility by means of web apps, plugins for design and coding software, or browser extensions (for example, axe DevTools, ARC Toolkit, WAVE, Stark, and others). These tools generate a report with issues and recommendations.
  2. Expert audit
    Evaluation of web accessibility by a professional who knows the requirements. This person can employ assistive technology and have a disability, but this is anyway an expert with advanced knowledge, not a “common user.” As a result, you get a report too, but it’s more contextual and sensible.

Testing, unlike auditing, cannot be done by one person. It involves users of assistive technologies and comprises a set of one-on-one sessions facilitated by a designer, UX researcher, or another professional.

Today we’ll focus on testing as an undervalued yet powerful method.

1.2. Usability vs. Accessibility Testing

You might have already heard about usability testing or even tried it. No wonder it’s the top research method among designers. So how is it different from its accessibility counterpart?

Common features:

  • Script
    In both cases, a facilitator prepares a full written script with an introduction, questions, and tasks based on a realistic scenario (for example, buying a ticket or ordering a taxi). By the way, here are handy testing script templates.
  • Insights gathering
    Despite accessibility testing’s main focus, it also reveals lots of usability issues, simply said, whether a site or app is easy to use. In both cases, a facilitator should ask follow-up questions to get an insight into people’s way of thinking, pain points, and needs.
  • Format
    Both testing types can be organized online or offline. Usually, one session takes from 30 minutes to 1 hour.

Key differences:

  • Participants selection
    People for usability testing are recruited mainly by demographic characteristics: job title, gender, country, professional experience, etc. When you test accessibility, you take into account the senses and assistive technologies involved in using a product.
  • What you can test
    In usability testing, you can test a live product, an interactive prototype (made in Figma, Protopie, Framer, etc.), or even a static mockup. Accessibility testing, in most cases, requires a live product; prototyping tools cannot deliver a source code compatible with assistive technology. Figma attempted to make prototypes accessible, but it’s still far from perfect.
  • Giving hints
    When participants get stuck in the flow, you help them find the way out. But when you involve people with disabilities, you have to understand how their assistive gear works. Just to give you an example, a phrase like “Click on the red cross icon in the corner” will sound silly to a blind user.

1.3. Why Opt For Testing?

Now that you know the difference between an audit and testing and the distinction between usability and accessibility testing, let’s clarify why testing is so powerful. There are two reasons:

  1. Get valuable insights.
    The idea of testing is to learn how you can improve the product. While you won’t check all interface elements and edge cases, such sessions show if the whole flow works and if people can reach the goal. Unlike even the most comprehensive audits, testing is much closer to reality and based on the usage of real assistive technology by a person with a disability.
  2. Build empathy through storytelling.
    A good story is more compelling than bare numbers. Besides, it can serve as a helpful addition to such popular pro-accessibility arguments as legal risks, winning new customers, or brand impact. Even 1–2 thorough sessions can give you enough material for a vivid story to excite the team about accessibility. An audit report alone may not be as thrilling to read.

Testing gives you more realistic insights into common scenarios. Laws and standards aren’t perfect, and formal compliance might not cover all the user challenges. Sometimes people take not the “designed” path to the goal but the one that seems safer or more intuitive, and testing reveals it.

Of course, auditing is still a powerful method; however, its combination with testing will show much more accurate results. Now, let’s talk about accessibility testing in detail.

Part 2. Recruiting Users

There are many types of disabilities and, consequently, various assistive technologies that help people browse the web. Without a deep dive into theory, let’s just recap the variety of disabilities:

  • Depending on the senses involved or the affected area of life: visual (blindness, color deficiency, low vision), physical (cerebral palsy, amputation, arthritis), cognitive (dyslexia, Down syndrome, autism), auditory (deafness, hearing loss), and so on.
  • By severity: permanent (for example, an amputated leg or some innate condition), temporary (a broken arm or, let’s say, blurred vision right after using eye drops), and situational (for instance, a noisy room or carrying a child).

Note: You can find more information on various types of disabilities on the Microsoft Inclusive Design hub.

For the sake of simplicity, we’ll focus on the case applicable to most digital products: when a site or app mostly relies on vision. In this case, visual assistive technologies offer users an alternative way to work with content online. The most common technologies are:

  • Screen readers: software that converts text into speech and has numerous handy shortcuts to navigate efficiently. (We’ll talk about it in detail in the next chapters.)
  • Refreshable Braille displays: devices able to show a line of tactile Braile-script text. Round-tipped pins are raised through holes in a surface and refresh as a user moves their cursor on the screen. Such displays are vital for blind-deaf people.
  • Virtual assistants (Amazon Alexa, Apple Siri, Google Assistant, and others): an excellent example of universal design that serves the needs of both people with disabilities and non-disabled people. Assistants interpret human speech and respond via synthesized voices.
  • High-contrast displays or special modes: for people with low vision. Some users combine a high-contrast mode with a screen reader.

2.1. Who To Involve

Debates around an optimal number of testing participants are never-ending. But we are talking here about a particular case — organizing accessibility testing for the first time, hence the recommendation is the following:

  • Invite 3–6 users with blindness and low vision who either browse the web by means of screen readers or use a special mode (for example, extra zoom or increased contrast).
  • If your product has rich data visualization (charts, graphs, dashboards, or maps), involve several people with color blindness.

In any case, it’s better to conduct even one or two high-quality sessions than a dozen of poorly prepared ones.

2.2. Where To Find People

It is not as hard to find people for testing as it seems at first glance. If you are working on a mass product for thousands of users, participants won’t need any special knowledge apart from proficiency with their assistive technology. Here are three sources we recommend checking:

  • Specialized platforms for recruiting users according to your parameters (for example, Access Works or UserTesting). This method is the fastest but not the cheapest one because platforms take their commission on top of user compensation.
  • Social media communities of people with disabilities. Try searching by the keywords like “people with disabilities,” “PWD,” “support group,” “visually impaired,” “partially sighted,” or “blind people.” Ask the admin’s permission to post your research announcement, and it won’t be rejected.
  • Social enterprises and non-profits that work in the area of inclusion, employment, and support for people with disabilities (for example, Inclusive IT in Ukraine or The Federation of the Blind and Partially Sighted in Germany). Drop them an email with your request.

We noticed that the last two points might sound like getting participants for free, but not everyone has an opportunity to volunteer.

When we organized accessibility testing sessions last year, three persons agreed to take part pro bono because it was a university course, and we didn’t get any profits. Otherwise, be ready to compensate for the participant’s time (in my experience, around €15–30). It can be an Amazon gift card or coupon for something useful in a particular country (only ensure it’s accessible).

Digital product companies that test accessibility regularly hire people with disabilities so that they have access to in-progress software and can check it iteratively before the official launch.

Part 3. Preparing For The Session

Now that you’ve recruited participants, it’s time to discuss things to prepare before the sessions. And the first question is:

3.1. Online Or offline?

There are basically two ways to conduct testing sessions: remotely or face-to-face. While we usually prefer the first one, both techniques have pros and cons, so let’s talk about them.

Benefits of online:

  • Native environment.
    Participants can use familiar home equipment, like a desktop computer or laptop, with nicely tuned assistive technology (plugins, modes, settings).
  • Cost and time efficiency.
    No need to reimburse expenses for traveling to your office. It might be quite costly if a participant arrives with an accompanying person or needs special accessible transport.
  • Easier recruitment.
    It’s more likely you’ll find a participant that meets your criteria around the world instead of searching in your city (and again, zero travel expenses).

Benefits of offline:

  • Testing products in development.
    If you have a product that isn’t public yet, participants won’t be able to easily install it or open it in a browser. So, you’ll have to invite participants to your office, but they should probably bring the portable version of their assistive technology (for example, on a USB drive).
  • Testing mobile apps.
    If a person brings a personal phone, you’ll see not only the interaction with your product but also how the device is set up and what gestures and shortcuts a person uses.
  • Helping inexperienced users.
    Using assistive technology is a skill, and you may involve someone who is not yet proficient with it. So, the offline setting is more convenient when participants get stuck and you help them find the way out.

As you can see, online testing has more universal advantages, whereas the offline format rather suits niche cases.

3.2. Communication Tools

Once you decide to test online, a logical question is what tool to choose for the session. Basically, there are two options:

Specialized testing tools (for instance, UserTesting, Lookback, UserZoom, Hotjar, Useberry):

  • Apart from basic conferencing functionality, they support advanced note-taking, automatic transcription, click heatmaps, dashboards with testing results, and other features.
  • They are quite costly. Besides, trial versions may be too limited for even a single real session.
  • Participants may get stuck with an unfamiliar tool that they’ve never used before.

Popular video conferencing tools (for example, Google Meet, Zoom, Microsoft Teams, Skype, Webex):

  • Support all the minimally required functionality, such as video calls, screen-sharing, and call recording.
  • They are usually free.
  • There is a high chance that participants know how to use them. (Note: even in this case, people may still experience trouble launching screen-sharing).

Since we are talking about your first accessibility testing, it’s much safer and easier to utilize an old good video conferencing tool, namely the one that your participants have experience with. For example, when we organized educational testing sessions for the Ukrainian Catholic University, we used Skype, and at the HTW University in Berlin, we chose Zoom.

Regardless of the tool choice, learn in advance how screen-sharing works in it. You’ll likely need to explain it to some of the participants using suitable (non-visual) language. As a result, the intro to accessibility testing sessions may take longer compared to usability testing.

3.3. Tasks

As we figured out before, accessibility testing requires a working piece of software (let’s say, an alpha or beta version); it’s harder to build, but it opens vast research opportunities. Instead of asking a participant to imagine something, you can actually observe them ordering a pizza, booking a ticket, or filling in a web form.

Recommendations for accessibility testing tasks aren’t much different from the ones in usability testing. Tasks should be real-life and formulated in a way people naturally think. Instead of referring to an interface (what button a person is supposed to click), you should describe a situation that could happen in reality.

Start a session with a mini-interview to learn about participants’ relevant experiences. For example, if you are going to test an air travel service, ask people if they travel frequently and what their desired destinations are. Based on these details, customize the tasks — booking a ticket to the place of the participant’s choice, not a generic location suggested by you.

Examples of realistic, broad tasks:

  • Testing a consumer product: bicycle online store.
    You want to buy a gift card for your colleague George who enjoys bikepacking. Choose the card value, customize other preferences, and select how George will receive the gift. (This task implies that you learned about a real George who likes cycling during a mini-interview.)
  • Testing a professional product: customer support tool.
    Your manager asked you to take a look at several critical issues that haven’t been answered for a week. Find those tickets and find out how to react to them. (This task implies that you invited a participant who worked as a customer support agent or in a similar role.)

Examples of leading UI-based tasks:

  • Consumer product
    “Open the main menu and find the ‘Other’ category. Choose a €50 gift card. In the ‘For whom’ input field enter ‘John Doe’… Select ‘Visa/Mastercard’ as a paying method…”
  • Professional product
    “Navigate to the dashboard. Choose the ‘Last week’ option in the ‘Status’ filter and look at the list of tickets. Apply the filter ‘Sort by date’ and tell me what the top-most item is…”

A testing session is 50% preparation and 50% human conversation. It’s not enough to give even a well-formulated task and silently wait.

An initial task reveals which of the ways to accomplish a task a participant will choose as the most intuitive one. When a person gets stuck, you can give hints, but they shouldn’t sound like “click XYZ button”; instead, let them explore further. Something like the following:

— No worries. So, the search doesn’t give the expected result. What else can you do here?
— Hmm, I don’t know. Maybe filtering it somehow…
— OK, please try that.

3.4. Wording

Your communication style impacts participants’ way of thinking and the level of bias. Even a huge article won’t cover all the nitty-gritty, but here are several frequent mistakes.

Beware of the following:

  • Leading tasks: “Go to the ‘Dashboard’ section and find the frequency chart” or “Scroll to the bottom to see advanced options.”
    Such hints totally ruin the session, and you will never know how a person would act in reality.
  • Selling language: “Check our purchase in one click” or “Try the ‘Smart filtering’ feature.”
    It makes people feel as if they have to praise your product, not share what they really think.
  • Humorous tasks: “Create a profile for Johnny Cash” or, for example, “Request Christmas tree delivery to Lapland.”
    Jokes distract participants and decrease session realism.
  • IT terminology: “On the dashboard, find toggle switch” or “Go to the block with dropdowns and radio buttons.”
    It’s bad for two reasons: you may confuse people with words they don’t understand; it can be a sign that you give leading tasks and excessive UI hints.

Here is recommended further reading by Nielsen Norman Group:

Part 4. Session Facilitation

As agreed before, your first accessibility testing session will probably involve a blind person or a person with low vision who uses a screen reader to browse the web. So, let’s cover the two main aspects you have to know before starting a session.

4.1. Screen Readers

A screen reader is an assistive software that transforms visual information (text and images) into speech. When a visually impaired person navigates through a site or app using a keyboard or touchscreen, the software “reads” the text and other elements out loud.

Screen readers rely on the source code but interpret it in a special way. They skip code accountable for visual effects (like colors or fonts) and take into account meaningful parts, such as heading tags, text descriptions for pictures, and labels of interactive elements (whether it’s a button, input field, or checkbox). The better a code is written, the easier it will be for users to comprehend the content.

Now that you know how screen readers function, it’s time to experience them firsthand. Depending on the operating system, you’ll have a standard embedded screen reader already available on your device:

  • VoiceOver: Mac and iOS;
  • Narrator: Windows;
  • TalkBack: Android.

During one of our training courses, we learned from blind users that the screen reader on iPhone is more comfortable and flexible than the Android one. Interestingly, people don’t like standard desktop screen readers either on Mac or on Windows and usually install one of the advanced third-party readers, for instance:

  • JAWS (Job Access With Speech): Windows, paid, the most popular screen reader worldwide;
  • NVDA (Non-Visual Desktop Access): Windows, free of charge.

4.2. Navigation

Visually impaired people usually navigate apps and sites using a keyboard or touchscreen. And while sighted people scan a page and jump from one part to another, screen reader users can keep only one element in focus at a time, be it a paragraph of text or, let’s say, an input field.

Participants of your accessibility testing will likely run into an unpassable obstacle at some point in the session, and you’ll give them hints on how to find the way out and proceed with the next task. In this case, you’ll need a special non-visual language that makes sense.

Not helpful hints:

  • “Click the cross icon in the upper right corner.”
  • “Scroll to the bottom of the modal window and find the button there.”
  • “Look at the table in the center of the page.”

Helpful hints:

  • “Please, navigate to the next/previous item.”
  • “Go to the second element in the list.”
  • “Select the last heading/link/button.”

Note: UI hints above are suggested for cases when a user is completely stuck in the flow and cannot proceed, for example, when an element is not navigable via a keyboard or, let’s say, an interactive element doesn’t have a proper label or name.

Summary

Once all the testing sessions have been completed, you can analyze the collected feedback, determine priorities, and develop an action plan. This process could be the subject of a separate guideline, but let’s cover the three key principles right away:

  • Catching information
    Testing produces tons of data, so you should be prepared to capture it; otherwise, it will be lost or obscured by your imperfect human memory. Don’t rely on a recording. Make notes in the process or ask an assistant to do that. Notes are easier to analyze and find repeating observations across sessions. Besides, they ensure you’ll have data if the recording fails.
  • Raw datainsights
    Not everything you observe in testing sessions should be perceived as a call to action. Raw data shows what happened, while insights explain reasons, motivations, and ways of thinking. For example, you see that people use search instead of filters, but the insight may be that typing a search request needs less effort than going through the filter menu.
  • Criticality and impact
    Not all observations are significant. If five users struggle to proceed because the shopping cart isn’t keyboard-navigable, it’s a major barrier both for them and the business. But if one out of five participants didn’t like the button name, it isn’t critical. Take into account the following:
    • How many participants encountered a problem;
    • How much a problem impacts reaching the goal: booking a ticket, ordering pizza, or sending a document.

Once the information has been collected and processed, it is essential to share it with the team: designers, engineers, product managers, quality assurance folks, and so on. The more interactive it will be, the better. Let people participate in the discussion, ask questions, and see what it means for their area of responsibility.

As you gain more experience in conducting testing sessions, invite team members to watch the live stream (for instance, via Google Meet) or broadcast the session to a meeting room with observers, but make sure they stay silent and don’t intrude.

Further Reading

Exploring Universal And Cognitive-Friendly UX Design Through Pivot Tables And Grids

Tables are one of the most popular ways to visualize data. Presenting data in tables is so ubiquitous — and core to the web itself — that I doubt many of you reading this have any trouble with the basics of the <table> element in HTML. But building a good complex table isn’t an easy task.

Though, I’d even go so far as to say that tables are an integral part of our daily life.

That’s why we need to start thinking about making tables more inclusive. The web is supposed to be designed for everybody. That includes those with impairments that may prevent access to the information in the tables we make and rely on assistive technology to “read” them.

For the last several months, I’ve been working on this scientific project around inclusive design for people with cognitive disorders for my university degree. I’ve mostly focused on developing guidelines to help educational platforms adapt to such users.

I also work for a company that has developed a JavaScript library for creating pivot tables used for business analysis and data visualizations. At one point in my research, I found that tables are a type of popular data representation that can simultaneously be a lifesaver and a troublemaker, yes, for people with learning and cognitive problems, but for everyone else as well. Remember, we are all temporarily “abled” and prone to lose abilities like eyesight and hearing over time.

Plus, a well-executed inclusive table design is a pathway to improving everyone’s productivity and overall experience, regardless of impairment.

Table Of Contents What We Mean By Cognitive Disorders

Cognitive disorders are defined as any kind of disorder that significantly impairs an individual’s conscious intellectual activity, such as thinking, reasoning, or remembering.

ADHD is one example that prevents a person from remaining focused or paying attention. There’s also dyslexia , which makes it tough to recognize and comprehend written words. Dyscalculia is specific to working with numbers and arithmetic.

For those without this condition, it is difficult to understand what exactly can be wrong with the perception of written information. But based on the descriptions of people with the relevant deviations, simulators were created that imitate what people with dyslexia see.

Currently, you can even install a special browser extension to estimate how difficult your site will be to perceive by people with this deviation. It is much more difficult to understand the condition of people with ADHD, but certain videos with ADHD simulations do exist, which can also allow you to evaluate the level of difficulty in the perception of any information by such people.

These are all things that can make it difficult for people to use tables on the web. Tables are capable of containing lots of information that requires a high level of cognitive work.

  • The first stage toward helping users with such deviations is to understand their condition and feel its details on themselves — in other words, practicing empathy.
  • The second stage is to systematize the details and identify specific usability problems to solve.

Please indulge me as we dive a bit into some psychological theory that is important to understand when designing web pages.

Cognitive Load

Cognitive load relates to the amount of information that working memory can hold at one time. Our memory has a limited capacity, and instructional methods should avoid overloading it with unnecessary activities and information that competes with what the individual needs to complete their task.

UX professionals often say complex tasks that require the use of external resources may result in an increased cognitive load. But the amount of the load can be affected by any additional information, unusual design, or wrong type of data visualization. When a person is accustomed to a particular representation of certain types of data — like preferred date format or where form input labels are positioned — even a seemingly minor change increases the processing time of our brain.

Here’s an example: If a particular student is from a region where content is presented in a right-to-left direction and the software they are provided by their university only supports a left-to-right direction, the amount of mental work it takes to comprehend the information will be greater compared to other students.

If you still want another example, Anne Gibson explains this exceptionally well in a blog post that uses ducks to illustrate the idea.

Cognitive Biases

I also want to call special attention to cognitive biases, which are systematic errors in thinking that become patterns of deviation from rationality in judgment. When people are processing and interpreting information around them, it often can influence the decisions a person makes without even noticing.

For example, the peak-end rule says that people judge an experience by its "peak” and last interactions. It’s easy to prove. Try to reflect on a game you used to play as a kid, whether it’s from an arcade, a computer console, or something you played online. What do you remember about it? Probably the level that was hardest for you and the ending. That’s the“peak” of your experience and the last, most “fresh” one, and they create your overall opinion of the game. For more examples, there is a fantastic resource that outlines 106 different types of cognitive biases and how they affect UX.

Signal-to-noise Ratio

Last but not least, I’d like to touch on the concept of a signal-to-noise ratio briefly. It is similar to the engineering term but relates to the concept that most of the information we encounter is noise that has nothing to do with a user’s task.

  • Relevant and necessary information is a signal.
  • The ratio is the proportion of relevant information to irrelevant information.

A designer’s goal is to achieve a high signal-to-noise ratio because it increases the efficiency of how information is transmitted. The information applied to this ratio can be anything: text, illustrations, cards, tables, and more.

The main idea about cognitive disabilities I want you to take away is that they make individuals very sensitive to the way the information is presented. A font that’s too small or too bright will make content unperceivable. Adding gratuitous sound or animation may result in awful distractions (or worse) instead of nice enhancements.

I’ll repeat it:

A good user experience will prevent cognitive overload for everyone. It’s just that we have to remember that many out there are more sensitive to such noises and loads.

Focusing on individuals with specific considerations only gives you a more detailed view of what you need to solve for everybody to live a simpler life.

Considering Cognitive Disorders In UX Design

Now that we have defined the main problems that can arise in a design, I can sum up our goals for effective UX:

  • Reduce the cognitive load.
  • Maximize the signal-to-noise ratio.
  • Use correct cognitive biases to boost the user experience.

“Design” is a loaded term meaning lots of different things, from colors and fonts to animations and sounds and everything in between. All of that impacts the way an individual understands the information that is presented to them. This does not mean all design elements should be excluded when designing table elements. A good table design is invisible. The design should serve content, not the other way around.

With the help of lots of academic, professional, and personal research, I’ve developed a set of recommendations that I believe will result in cognitive-friendly and easy-to-perceive table designs.

Color Palettes And Usage

We should start by talking about the color because if the colors used in a table are improperly implemented, subsequent decisions do not really matter.

Many people consider colors to have their meanings, which differ from culture to culture. That’s certainly true in a sociological sense, but as far as UX is concerned, the outcome is the same — colors carry information and emotions and are often unnecessary to mean something in a design.

Rule 1: Aim For A Minimalist Color Palette

When you see a generous use of color in a table, it isn’t to make the table more functional but to make a design stand out. I won’t say that using fewer colors guarantees a more functional table, but more color tends to result in individuals losing attention from the right things.

Accordingly, bright colors and accents should highlight information that has established meaning. This isn’t to say that interesting color schemes and advanced color palettes are off-limits. This means using colors wisely. They are a means to an end rather than a splash of paint for attention.

Adam Wathan & Steve Schoger offer a perfect example of color usage in a design study of customized Slack themes. Consider the two following interfaces. It may not seem like it at first, but the second UI actually has a more extensive color palette than the first.

The difference is that the second interface applies shades of the core color defined in the palette and that brighter and more vibrant shades are only used to highlight the important stuff.

You can explore this phenomenon by yourself and test your perception of the colors in the design by changing the look of your messenger. For example, Telegram has some interface customization options, and while playing with that, I noticed I read and navigate between my chats in the “Night Accent” mode rather than the plain “System” mode.

Of course, both designs were designed for people with different preferences and characteristics, but such a personal experiment led me to the following thought. Even though the second option uses fewer colors, the uniformity of information is a bit confusing. From this, I concluded that too few colors and too minimal a design is also a bad choice. It is necessary to find a balance between the color palette and its usage.

The best option is to pick from one to three primary colors and then play with their shades, tints, and tones. To combine the colors wisely, you can use complementary, split complementary, or analogous approaches.

That said, I suggest using a “shading” monochromatic approach for tables. It means defining a base color in a palette, then expanding it with different shades in dark and light directions. In other words:

  1. Choose a primary color.
  2. Define an evenly darker and lighter shade of that primary color.

This produces two more colors to which you can apply the previous technic to create colors that are a perfect compromise between the shades on either side. Repeat this process until you reach the number of colors you need (generally, 7–9 shades will do).

Rule 2: Embrace The Power Of Whitespace

I find that it’s good to offer a fair amount of “breathing room” around elements rather than trying to crowd everything in as close as possible. For example, finding a balance of space between the table rows and columns enhances the legibility of the contents as it helps distinguish the UI from the information.

I’ll qualify this by noting that “breathing room” often depends on the type of data that’s being presented, as well as the size of the device on which it’s being viewed. As such, it sometimes makes sense to enhance a table’s functionality by allowing the user to adjust the height and width of rows and columns for the most optimal experience.

If you are worried about using too few or too many colors, apply the 60/30/10 rule. It’s a basic pattern for any distribution selection. People use this strategy when budgeting assets like content and media, and it’s applicable to design. The rule says the color usage should be distributed as follows:

  • 60% for neutral colors,
  • 30% for primary colors,
  • 10% for secondary colors (e.g., highlights, CTAs, and alerts).

Rule 3: Avoid Grays

Talking about neutral colors, in color theory, gray represents neutrality and balance. Its color meaning likely comes from being the shade between white and black and often is also perceived as the absence of color. You can not overdo it; its light shades do not oppress, so gray is just “okay.”

However, gray does carry some negative connotations, particularly when it comes to depression and loss. Its absence of color makes it dull. For this reason, designers often resort to it to de-emphasize an element or certain bits of data.

But maintaining such a philosophy of gray color will only work in black and white designs, such as on the Apple website. Though, as I mentioned before, it actually works really well as grey is the tone of black or a shade of white.

The problem, however, comes up when other colors are added to the color palette, which leads to a change in a color’s roles and functions. In the case of gray, putting it next to brighter colors makes the design pale and dull.

Having no color of its own, gray seems to eat away the brightness of neighboring elements. Instead of maintaining balance, gray makes the design cloudy and unclear. After all, against the background of already illuminated elements, gray makes the elements not just less significant but unnecessary for our perception.

That does not mean you should totally give up gray. But highlighting some information inherently de-emphasizes other information, negating the need for gray in the first place.

The easy way out is to replace gray with lighter shades of a palette’s base color on a table cell’s background. The effect is the same, but the overall appearance will pop more without adding more noise or cognitive load.

Rule 4: Know What’s Worthy Of Highlighting

Designers are always looking for a way to make their work stand out. I get the temptation because bold and bright colors are definitely exciting and interesting.

Blogs can be considered a good example of this problem as their variety is wide and growing, and a lot of platforms prioritize exclusive design over inclusive design.

For example, Medium uses only black and shades of it for a color palette, which significantly facilitates even simple tasks like reading titles. Hackernoon, although looking interesting and drawing attention, requires more concentration and does not allow you to “breathe” as freely as on Medium.

In analytical software, that only leads to a table design that emphasizes a designer’s needs ahead of the user’s needs.

Don’t get me wrong — a palette that focuses on shades rather than a large array of exciting colors can still be exciting and interesting. That provides a discussion about which grid elements benefit from color. Here are my criteria for helping decide what those are and the colors that add the most benefit for the given situation.

Active cells: If the user clicks on a specific table cell or selects a group of cells, we can add focus to it to indicate the user’s place in the data. The color needs to call attention to the selection without becoming a distraction, perhaps by changing the border color with a base color and using a light shade of it for the background so as to maintain WCAG-compliant contrast with the text color.

Tip! It’s also good to highlight the row and column that a focused cell belongs to, as this information is a common thing to check when deciphering the cell’s meaning. You can highlight the entire row and column it belongs to or, even better, just the first cell of the row and column.

Error messaging: Error messages definitely benefit from color because, in general, errors contain critical feedback for the user to take corrective action.

A good example might be an injected alert that informs the user that the table’s functionality is disabled until an invalid data point is fixed. Reds, oranges, and yellows are commonly used in these situations but bear in mind that overly emphasizing an error can lead to panic and stress. (Speaking of error messaging, Vitaly Friedman has an extensive piece on designing effective error messages, including the pitfalls of relying too heavily on color.)

Outstanding data: I’m referring to any data in the table that is an outlier. For example, in a table that compares data points over time, we might want to highlight the high and low points for the sake of comparison. I suggest avoiding reds and greens, as they are commonly used to indicate success and failure. Perhaps styling the text color with a darker shade of a palette’s base color is all you need to call enough attention to these points without the user losing track of them.

The key takeaway:

Data-heavy tables are already overwhelming, and we don’t want any additional noise. Try to remove all unnecessary colors that add to a user’s cognitive load.

Tip! Remember the main goal when designing a table: reliability, not beauty. Always check your final decisions, ideally with a variety of target users. I really recommend using contrast checkers to spot mistakes quickly and efficiently correct them.

Typographical Considerations

The fonts we use to represent tabular data are another aspect of a table’s look and feel that we need to address when it comes to implementing an inclusive design. We want the data to be as legible and scannable as possible, and I’ve found that the best advice boils down to the typography of the content — especially for numerics — as well as how it is aligned.

Rule 1: The Best Font Is A “Simple” Font

The trick with fonts is the same as with colors: simplicity. The most effective font is one that takes less brainpower to interpret rather than one that tries to stand out.

No, you don’t need to ditch your Google Fonts or any other font library you already use, but choose a font from it that meets these recommendations:

  1. Sans-serif fonts (e.g., Helvetica, Arial, and Verdana) are more effective because they tend to take up less space in a dense area — perfect for promoting more “breathing room” in a crowded table of data.
  2. A large x-height is always easier to read. The X-height is the height of the body of a lowercase letter minus any ascenders or descenders. In other words, the height of the lowercase “x” in the font.
  3. Monospace fonts make it easier to compare cells because the width of each character is consistent, resulting in evenly-spaced lines and cells.
  4. Regular font weights are preferable to bolder weights because the boldfacing text is another form of highlighting or emphasizing content, which can lead to confusion.
  5. A stable, open counter. The counter is a space in the letter “o” or the letter “b.” Fonts with distorted counters render poorly in small sizes and are hard to read.

Fonts that fulfill these criteria are more legible and versatile than others and should help whittle down the number of fonts you have to choose from when choosing your table design.

Rule 2: Number Formatting Matters

When choosing a font, designers often focus on good legible letters and forget about numbers. Needless to say, numbers often are what we’re displaying in tables. They deserve first-class consideration when it comes to choosing an effective font for a good table experience.

As I mentioned earlier, monospace fonts are an effective option when numbers are a table’s primary content. The characters take up the same width per character for consistent spacing to help align values between rows and columns. In my experience, finding a proportional font that doesn’t produce a narrow “1” is difficult.

If you compare the two fonts in the figure above, it’s pretty clear that data is easier to read and compare when the content is aligned and the characters use the same amount of space. There’s less distance for the eye to travel between data points and less of a difference in appearance to consider whether one value is greater than the other.

If you are dealing with fractions, you will want to consider a font that supports that format or go with a variable font that supports font-variant-numeric features for more control over the spacing.

Rule 3: There Are Only Two Table Alignments: Left And Right

Technically there are four alignments: left, right, center, and justify. We know that because the CSS text-alignment property supports all four of them.

My personal advice is to avoid using center alignment, except in less-common situations where unambiguous data is presented with consistently-sized icons. But that’s a significant and rare exception to the rule, and it is best to use caution and good judgment if you have to go there.

Justified content alters the spacing between characters to achieve a consistent line length, but that’s another one to avoid, as the goal is less about line lengths than it is about maintaining a consistent amount of space between characters for a quick scan. That is what monospaced fonts are effective for.

Data should instead be aligned toward the left or right, and which one is based on the user’s language preference.

Then again, at school, we’re taught to compare numbers in a right-to-left direction by looking first at single units, then tens, followed by hundreds, then thousands, and so forth. Accordingly, the right alignment could be a better choice that’s universally easier to read regardless of a person’s language preference. You may notice that spreadsheet apps like Excel, Sheets, and Notion align numeric values to the right by default.

There are exceptions to that rule, of course, because not all numbers are measurements. There are qualitative numbers that probably make more sense with left alignment since that is often the context in which they are used. They aren’t used for comparison and are perceived as a piece of text information written in numbers. Examples include:

  • Dates (e.g., 12/28/2050),
  • Zip/Postal code (e.g., 90815),
  • Phone number (e.g., 555-544-4349).

Table headings should be aligned to the same edge as the data presented in the column. I know there could be disagreement here, as the default UA styling for modern browsers centers table headings.

The screenshots above are examples of bad and good headers. When looking at the first screenshot, your initial focus is likely drawn to the column headers, which is good! That allows you to understand what the table is about quickly. But after that initial focus, the bold text is distracting and tricks your brain into thinking the header is the most important content.

The header in the second screenshot also uses bold text. However, notice how changing the color from black to white emphasizes the headers at the same time. That negates the impact bolding has, preventing potential cognitive load.

At this point, I should include a reminder to avoid gray when de-emphasizing table elements. For example, notice the numbers in the far left column and very top row. They get lost against the background color of the cells and even further obscured by the intense background color of surrounding cells. There’s no need to de-emphasize what is already de-emphasized.

I also suggest using short labels to prevent them from competing with the data. For example, instead of a heading that reads “Grand Total of Annual Revenue,” try something like “Total Revenue” or “Grand Total” instead.

Table Layout Considerations

There once was a time when tables were used to create webpage layouts because, again, it was a simple and understandable way to present the information in the absence of standardized CSS layout features. That’s not the case today, thankfully, but that period taught us a lot about best practices when working with table design that we can use today.

Rule 1: Fewer Borders = More White Space

Borders are commonly used to distinguish one element from one another. In tables, specifically, they might be used to form outlines around rows and columns. That distinction is great but faces the same challenge that we’ve covered with using color: too much of a layout can steal focus from the data, making the design busy and cluttered. With the proper design and text alignment, however, borders can become unnecessary.

Borders help us navigate the table and delimit individual records. At the same time, if there are many of them in a grid, it becomes a problem in large tables with a lot of rows and columns. To prevent the cells from being too densely connected, try adding more space between them with padding. As I have mentioned before, negative space is not an enemy but a design saver.

That said, the law of diminishing returns applies to how much space there should be, particularly when considering a table’s width. For example, a table might not need to flex to the full width of its parent container by default. It depends on the content, of course. Avoiding large spacing between columns will help prevent a reader’s eyes from having to travel far distances when scanning data and making mistakes.

I know that many front-enders struggle with column widths. Should they be even? Should they only be as wide as the content that’s in them? It’s a juggling act that, in my mind, is not worth the effort. Some cells will always be either too wide or too narrow when table cells contain data points that result in varying line lengths. Embrace that unevenness, allowing columns to take up a reasonable amount of space they need to present the data and scale down to as little as they need without being so narrow that words and numbers start breaking lines.

Lines should be kept to a minimum. Add them if adjusting the alignment, joining cells, and increased spacing is not enough to indicate the direction — or keep them as light as possible.

Allow multi-line wrapping when you really need it, such as when working with longer data points with just enough room around them to indicate the alignment direction. But if you caught yourself thinking of using multi-line wrapping in a grid, then first of all, analyze whether there is a more practical way to visualize the data.

Rule 2: Stylish rows, stylish columns

When deciding how to style a table’s rows, it’s important to understand the purpose of the table you are developing. Reducing visual noise will help to present a clear picture of the data on smaller datasets but not for large datasets.

It’s easy for a user to lose their place when scrolling through a table that contains hundreds or thousands of rows. This is where borders can help a great deal, as well as zebra striping, for a visual cue that helps anchor a user’s eyes enough to hold focus on a spot while scanning.

Speaking of zebra striping, it’s often used as a stylistic treatment rather than a functional enhancement. Being mindful of which colors are used for the striping and how they interact with other colors and shades used for highlighting information will go a long way toward maintaining a good user experience that avoids overwhelming color combinations. I often use a slightly darker shade of the table’s default background color on alternating rows (or columns) when establishing stripes. If that’s white, then I will go with the lightest shade of my palette’s base color. The same choice should be made while maintaining the borders — they should be marked but remain invisible.

Typically, row density gravitates around 40px-56px with a minimum padding of 16px on both the right and left edges of each column.

Feature Enhancements

Tables are often thought of as static containers for holding data, but we’ve all interacted with tables that do lots of other things, like filtering and reordering.

Whatever features are added to a table, it’s important to let users customize the table themselves based on their preferences. Then the user experience you create can become even better by conforming to the user’s comfort level. As with everything else, there is a line. Smaller datasets may not need the same enhancements for filtering data that large datasets do, for example, because they may wind up causing more confusion than convenience and raise the threshold for understanding the data.

In addition to the ability to customize a table’s elements, such as colors, fonts, conditional formatting, value formatting, and cell sizing, there are a few questions you can ask to help determine the enhancements a table might need for a better experience.

Could A User Lose Context When Scrolling?

We’ve already discussed how a table with hundreds of rows or columns can lead to many user scrolling and cognitive errors. Striping is one way to help users remain focused on a particular spot, but what if there’s so much scrolling that the table’s headers are no longer available?

If that’s a possibility, and the headers are important for establishing the context of the presented data, then you might consider sticky positioning on the headers so they are always available for reference. Chris Coyier has a nice demo that implements sticky headers and a sticky first column.

Who Can Have Problems Using My Design? (Accessibility Support)

Of all the points, this is the most difficult to implement, but at the same time, in our context, it is the most important. People with diagnosed abnormalities and disorders have a much stronger impact on their work process due to their condition. Therefore, supporting an additional — and optional — accessibility mode is necessary. Each element must be adapted for screen readers, navigable via keyboard, and contain the most semantic markup possible. This will help people who use assistive technology without a loss in performance.

Conclusion

Thanks for letting me share my best practices for presenting tabular data on the web. It’s amazing how something as seemingly simple as a table element can quickly grow in scope when we start considering user needs and enhancements to include as many of those needs as possible.

We discussed a great number of things that get in the way of an inclusive table design, including our own cognitive biases and design choices. At the same time, we covered strategies for tackling those obstacles from a wide range of considerations, from design choices all the way to determining possible features for enhancing a user’s experience when interacting with the table and the data it contains.

There can be a lot of headwork that goes into a table implementation, but not everything in this article has to be considered for every situation. A lot of the advice I’ve shared — like so many other things on the web — simply depends on the specific case. That’s why we spent a good amount of time defining the goals for an effective table experience:

  • Reduce the cognitive load.
  • Maximize the signal-to-noise ratio.
  • Use correct cognitive biases to boost the user experience.

But if you only take one thing away from this, I’d say it is this: in data analytics data > than everything else. Keeping that idea in mind throughout the development process prevents spoiling your design with frivolous designs and features that work against our goals.

Further Reading on Smashing Magazine

Accessible Target Sizes Cheatsheet

Rage taps are annoying and frustrating. These wonderful occurrences in our interface when we need to tap twice or sometimes three times to continue our journeys. Of course, sometimes they happen because the website is too slow, but sometimes it’s the target size of interactive elements that is the culprit.

So how big should our interactive elements be these days? What would be a reliable size for icons, links and buttons — in navigation and on mobile? How do we make it more difficult for our users to make mistakes? Let’s take a look.

Note: You can find a whole video chapter on designing for touch in Smart Interface Design Patterns as well — along with 30 other chapters all around UX and design patterns.

Target Sizes Cheatsheet

One of the common recommendations for target sizes on mobile is 44×44px. This is a little bit misleading because screen pixels, or at least device-independent pixels (dips) are scaled to a multiple of the display resolution. So pixels are different on different screens, and when we have a conversation about sizes, we probably should be speaking about dips, rather than pixels.

Depending on where an element appears on the screen, it needs more or less padding. In general, we are very precise in our input in the center of the screen, but we are least precise on the edges of the screen (both on the top and at the bottom).

Accordion to Steven Hoober’s research in his book on Touch Design For Mobile Interfaces, to minimize rage taps, we need to aim for 11mm (or 31pt / 42px) on the top of the screen, and 12mm (or 34pt / 46px) at the bottom of the screen. In the center though, we could potentially go as low as 7mm (or 20pt / 27px). This includes both the width and padding of an interactive element.

How do point units translate to CSS pixels or Android/iOS units? Fortunately, Steven Hoober provides a helpful conversion table to help you translate from points to px and em units, Android SPs or DPs, iOS points and Windows DIP or px.

Not All Pixels Are The Same

As we’ve seen above, target sizes change depending on where components appear on the screen. It’s worth noting that according to the WCAG 2.1 AAA level requirements, all targets should measure at least 44 by 44px, except if the target is in a sentence or block of text. For such exceptions, we could be using 27px as a goal, but in general, the larger, the better.

For sticky menus at the top or bottom of the screen, we should probably aim for around 44–46px boxes, or preferably even more. However, for links that appear on the screen as the user scrolls down the page, we probably will be able to avoid most issues with smaller components.

This is also why we probably will be able to place at most five items in the bottom tabs on a mobile phone. Instead, we might need to use a bottom sheet that would slide up from down as an overlay on top of the screen.

Prefer “Actions” Button To Single Icons For Data Tables

Complex tables typically have hover actions that appear once a user starts hovering over a particular row. They typically include everything from highlight and export to move and delete.

In testing, showing icons on hover produces too many mistakes: not only do users often accidentally jump to a wrong row as they navigate horizontally towards the icons. They also make mistakes by accidentally clicking on the wrong spot and starting all over again.

To avoid rage clicks, it might be a good idea to test how well an “Actions” buttons or a “Split”-Button would perform instead. Indeed, that button could live on every row, would open on tap/click, and wouldn’t close automatically. It might not be ideal for every use case, but it definitely gives users more sense of control as they need to take action in a row.

Provide An Assistant For Complex Manipulations

With complex manipulation, such as rotation of an image, or selection of a small part of a larger area, we often rely on pinch and zoom or zoom in/out buttons. These options, of course, work, but they easily become a bit tedious to use for very precise manipulations — especially if used for a while.

Instead, we can attach a little handle to allow users to move their selection within the object faster and with more precision. This is how Tylko allows users to customize their shelves on mobile. Zooming is supported as well, but it’s not necessary to select one of the areas.

When Multiple Taps Are Better Than One

But what do we do if some tap areas have to be small? Perhaps we can’t reserve 27×27px for each icon — for example, when we suggest a color selection in an eCommerce site? Well, in that case, one option to consider would be to prompt a “proper” selection of colors with one additional tap. This might be a bit slower in interaction, but way more accurate.

Fewer rage clicks: Grønland Color Picker Microinteraction, designed by Mykolas Puodžiūnas. (Large preview) Always Maximize Clickable Area

Whenever possible, encapsulate the entire element, along with enough padding to ensure that you hit the magical 42–46px size to prevent rage taps for good. This typically means adding enough padding for icons but also preferring full-width or full-height bars for accordions and navigation.

Ahmad Shadeed presents a few useful examples of using spacing to increase clickable areas and prevent rage clicks. Any Lupe provides even more suggestions in her article on accessible target sizes.

Wrapping Up

When designing for touch today, we need to use at least 27×27px for small links or icons in the content area and at least 44×44px for icons at the top and at the bottom of the page.

Personally, I would always go up to 30×30px and 48×48px to make sure mistakes are really difficult to make. And, of course, always use full width or full height for the clickable areas. Hopefully, this will help us remove any possible rage taps from our websites altogether — and many of your users will sincerely appreciate it indeed.

You can find more details on navigation UX in the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up in September this year.

Useful Resources

There are a few wonderful resources on accessible target sizes that might be helpful if you’d like to dive deeper in the topic:

Could UX Be The Key To Unlocking Web3 Mass Adoption?

Let’s pretend you are interested in trying out Web3 (aka Blockchain or Crypto). You might have experience with various software tools from Web 2.0 and think Web3 is going to be as equally user-friendly, right?

You get a blockchain wallet, and that’s your passport to everything in the space. Once you’ve got your wallet set up, you’re free to take advantage of blockchain apps. Well, that’s how it works in theory. The reality is far more complex and is enough to confuse even pretty technical people.

So let’s say you start by getting a wallet. Which wallet? Well, there are hundreds to choose from, so just pick one you like the look of. Not that one, though; it doesn’t work with the blockchain you need it to.

And when you set it up, make sure you keep a digital and physical copy of your 24-word seed phrase safe. Lose that, and someone could syphon all of the assets in the wallet.

Set it up? Awesome. Now just head to the project you want to use and... Oh, wait. Before you can sync your wallet and log in, you need to add and switch to a different network. Done that? Perfect.

Ok, now we’re ready to jump into the decentralized web! How long will a transaction take? I don’t know. It could be a few seconds, could be a few hours. It really depends on network congestion and what it is you’re looking to transfer.

Once that transaction has gone through, make sure you get a different wallet — ideally a hardware wallet — to keep everything safe. Yeah, I know there are fees involved, but that’s the price of having full control of your own assets and data.

Well done, you’ve actioned a single transaction in Web3! Give yourself a pat on the back because it’s anything but simple.

This is, sadly, not an exaggeration. This is what we expect new users to Web3 to do to get set up with a new project or platform. Is it any wonder that most people find the space confusing and frustrating?

I’ll soon come onto the issues in Web3 adoption and how we might be able to solve them. But first, let’s address the elephant in the room and speak briefly about what Web3 actually is.

What Exactly Is Web3 (And Why Should We Care)?

If we’re being blunt, Web3 is little more than a marketing term. Something brands in the space have conjured up to put a little distance between themselves and the negative public view of crypto.

However, there is a difference between Web 2.0 and Web3. At a high level, Web3 brands are built on blockchain technology, which allows a more decentralized approach to their operation. These brands also tend to focus on transparency, security, and accessibility.

In effect, the key benefits include:

  • Better security (fewer single points of failure);
  • Better interconnectivity and fewer controlling intermediaries.

But what does that actually mean?

Well, really, it’s about returning more control to the user and removing multiple intermediaries. In Web3, brands want users to control their owned assets and their data. They want to remove or limit the control of large, centralized entities.

Users are at the mercy of these large centralized entities. If these entities decide to implement a rule change, fare increase, or even experience negative outcomes themselves, the end users have no say in the matter and are often the ones who suffer.

Brands in the Web3 space are looking at how they can limit the amount of control centralized entities exert.

I’ll use financial systems as a starting point to highlight this.

If you want to set up a bank account, you often need to fill in an application and provide several forms of ID and information. Once you’re approved, you get an account.

That account comes with certain rules and regulations which you must abide by. If the bank decides you’re not abiding by the rules, they’ll close your account. If the bank decides that you shouldn’t have the ability to send funds internationally, you can’t. If the bank decides to hike its interest rates and fees, you have to pay them.

You are at their mercy because they own the infrastructure you need. It might not sound like an issue, and it’s not for the vast majority of people in Western nations. But access to a stable financial system can be a difficult thing for those in developing nations.

Let’s also think about how something like an international transfer is processed. If you want to send money to another country (or even someone who uses a different bank), there’s a multi-step chain of approvals and communications that needs to happen.

Now, each of these steps comes with a fee and a delay. Meaning it can take more than a few days for your payment to process.

With the decentralized nature of blockchain, though, you could send funds directly to the recipient without any intermediaries. That means fewer delays and zero chance a centralized entity within the system will decline the payment.

Now, let’s also talk briefly about the security of it all.

In the image above, you can see that there is one centralized ledger in the traditional banking system. If that one centralized entity is compromised, either through a hack or some form of error, everything suffers.

With blockchain tech, there’s a distributed ledger. If one of the “nodes” is attacked or fails, there are still multiple other copies that can be used to form backups and keep the system running.

As blockchain works on consensus between all nodes, you’d need to simultaneously attack 51% of the nodes to assume control. Currently, on Ethereum, there are 10,637 nodes across the globe.

An attacker would have to assume control of 5425 nodes at the same time. And even then, there are precautions and methods to prevent ongoing damage. As such, it’s generally considered to be far more secure than centralized systems.

All of the above might be focused on the financial. However, it’s true for any blockchain-based use case. From finance to data to the simple transference of ownership paperwork. It is more secure, more direct, and more easily controlled by the end user.

Now, there are issues with things like energy consumption that are being addressed. However, when we’re just looking at onboarding new users, there’s one big problem with blockchain-based apps and Web3. The UX is generally terrible.

Why UX Is Key To Unlocking Web3’s Potential

Let’s be blunt about this. Most people don’t care about the tech behind a service, nor do they want a convoluted, complex system to activate the most simple of actions.

People want convenience.

They want to quickly understand what a product does and how to achieve the benefit it offers. Great products attract users because they help people achieve their goals faster, easier, or cheaper than the existing method.

And yet, it feels like most Web3 projects are created by engineers, for engineers. The complexity extends beyond the actual service and includes how these projects explain themselves. The self-help documentation is often full of technical jargon most will never understand.

I mean, check out this paragraph from LooksRare (one of the most popular NFT marketplaces). It’s a simple statement about what they do.

“LooksRare’s smart contracts are custom-built within a modular system that enables new features to be rolled out over time — without compromising security — thanks to standardized signatures that clearly define the execution scope.”

I spend all day analyzing Web3 projects, and it takes me more than a second to decipher what they mean. Imagine trying to convince someone not in the space that they should take a chance on Web3 with the above. Right now, the only people truly involved in Web3 are those who have persisted through jargon-filled explanations and complex user journeys.

If QWeb3 and blockchain technology ever have a hope of going mainstream, everything needs to be simplified. The friction to onboarding new users needs to be reduced so that we can welcome those who aren’t technical. We need to make it so simple the generations that didn’t grow up with cell phones and video games can action a transaction. And that includes everything from the language used to the systems to onboard new users.

Here are a few of the overarching elements that should be addressed.

Core Elements Of Better Web3 UX

I’ll get into detail on these a little later on. First, I want to outline what I believe to be the major, big-picture difficulties that need to be overcome in the space.

Clear Communication

Too many projects fall back on jargon-filled explanations. They sound fancy, but they also limit who understands what the project does. It’s common when new developments are made, as most of the documentation is made by highly technical people. The issue is it’s extremely limiting.

Most people don’t care about how an L2 scaling solution helps improve the speed and efficiency of an underlying layer-1 blockchain without compromising cryptographic security. What they want is to quickly and safely send funds.

One of the best pieces of advice I received when first starting as a copywriter was to imagine you’re explaining concepts to a group of young children. If you can do that, even the most tech-unsavvy people out there will quickly understand why they need your offer.

Clear answers to key questions is critical to enabling your users to help themselves.

There’s a prime example of this below. You might not need to go that simple, but it definitely shouldn’t be as complex as most people make it.

Most Web3 apps have a fraction of that.

So the question is, what do these exchanges do differently? Well, they take the complexity out of cryptocurrency. Let’s look at Coinbase’s onboarding.

To sign up, they’ve used a common Web 2.0 sign-up process. It’s just your name, email address, and password. People are familiar with this, and anyone who’s been on the internet for more than a day will likely have auto-fill add in these details in a few clicks.

Once you’ve confirmed your email, you’re in the main dashboard. You’ll need to provide some details for the financial know-your-customer (KYC) checks, but then you’re ready to go. The whole thing takes maybe 2 minutes before you’re “interacting with the blockchain” and able to buy some cryptocurrency.

And even that’s made easier. On the main dashboard, there’s a huge "buy" button that brings up a modal where you simply add how much of the cryptocurrency you want to buy.

A few clicks later, you own some cryptocurrency. If you remove the approval of your KYC info, the whole process could be done in around 5 minutes. Likely the same time it would take you to process a bank transfer of some kind.

And notice how there was no mention of or need to set up:

  • Blockchain,
  • Crypto wallets,
  • Seed phrases.

The onboarding and usage mirror that of a familiar Web 2.0 system. The wallets and blockchain elements are all hidden from the user. This is how most tech-heavy businesses operate.

No one needs to see or know how the sausage is made. You don’t see YouTube going to great efforts to talk about how videos are stored and secured on their servers and then streamed to millions of devices. People simply click “upload” and then are given a link to share so others can watch it.

It’s so simple a child can do it. And it’s that level of simplicity blockchain-based brands should be aiming for. Crypto exchanges do this so well, and yet few other Web3 brands are mimicking their successful approach.

So, if you’re a UX professional and want to get involved in Web3, what are the primary opportunities you could explore as a new revenue stream?

UX Opportunities For Entrepreneurs And Designers In Web3

If I had to sum it up, the biggest opportunities in Web3 are in making everything more accessible for non-technical people. Think of how difficult it would have been to set up a website before popular website-building platforms and companies.

No one wants to code their own CMS and figure out how to host it on a domain. It’s way too complex for most people. As soon as companies like Cloudflare and WordPress came along, the potential for people to set up their own digital businesses exploded.

We need the same level of simplicity UX in Web3.

The person or team who solves any of the below issues will be on to a winner. They’ll have something the industry desperately needs for its growth, and I wouldn’t be surprised if great brands line up at the door of those offering these solutions. Here are a few of the biggest opportunities as I see them.

Now, I’ll preface this by saying there is a lot to be improved in Web3. Too much to cover in detail in this piece. So for the sake of brevity, I’ve segmented into two primary segments. First up is the issue with engineering.

Engineering Issues In Web3

I’d argue that engineering issues are more important for Web3 adoption. You can improve the marketing and general UI as much as you like, but if the products don’t work as intended or have huge flaws that prevent people from getting the best from them, it’s all in vain.

One of the major issues with the functionality of Web3 engagement is with wallets, more specifically, wallet recovery.

Wallet Recovery Without Compromising Security

This is a big one, in my opinion. As mentioned above, blockchain wallets are key to engagement with Web3 brands. They’re incredibly secure. So secure that if you lose that 12 or 24-word recovery seed phrase, you lose access to your wallet and its contents, probably forever.

It’s a huge risk. Some people take to writing their seed phrase on a piece of paper which obviously compromises security in more ways than one.

So what’s the solution? How can we keep that wallet’s security without making it so unforgiving that people are locked out of their own identity and assets?

One of the proposed solutions is to use what Vitalik Buterin calls a social recovery wallet.

In short, you add a couple of trusted guardians to your wallet. If you lose access, you ask them to authorise its transfer to a new address. It’s not perfect, but it’s, unfortunately, the best option we have right now.

This removes that single point of failure and turns the whole “I lost my seed phrase” from a complete loss into a slight hassle of asking friends or family to help you transfer to a new address.

If anyone out there can figure out how to create a better solution, they’ll be welcomed with open arms in Web3.

Potential fixes:

  • Social recovery systems as mentioned above.
  • Backup seed phrase to the cloud. (There are security risks here.) Potentially using a decentralized storage service to segment the seed phrase and store those segments separately.
  • Using multi-party computation to secure wallets. In this method, the private key could be split between a cloud server and a device like your phone. Both parties have to be available to access the wallet. Kind of like 2FA authentication.

Interoperability Between Different Blockchains

Blockchains are, unfortunately, siloed. Ethereum is different from Solana, and they don’t exactly work well together yet. If you want to work across chains, you need to work through multiple front-ends — blockchain bridges — and submit a lot of different bridge transactions. All of which are costly and cumbersome.

This is what the ecosystem looks like.

It’s a real pain to navigate. Most people will try to move assets and information across chains through centralized exchanges or individual cross-chain bridges, which is, at best, highly inefficient.

What’s needed is a method for assets and chains to interact with one another more seamlessly — for the end user to have a single dashboard that could pull details or assets from Chain 1 and use them on Chain 2 without the user having to do any manual moving of currencies or assets through a third-party service.

It’s a big problem, but the unlocking of this not only hugely improves UX but should foster greater innovation and growth in the sector as a whole.

Potential fixes:

  • There is sadly no real fix for this. There will continue to be new chains popping up. The best solution is for people to work on interoperability protocols that allow users to interact with two chains seamlessly.

Financial Off-ramps

One of the most talked about uses of blockchain technology is cryptocurrency. The big usability issue with crypto is that few places outside of Web3-specific services accept it as payment, and it’s peculiarly difficult to change back into fiat currency.

Imagine you have $1000 of Ethereum in your wallet and need $800 USD to pay a bill. If you wanted to turn that Ethereum into USD, you’d have to do something like the below:

  1. Log into a crypto exchange;
  2. Sync your wallet;
  3. Add your funds from your wallet to the Exchange’s wallet;
  4. Exchange your ETH for USD for a transfer fee;
  5. Withdraw the USD to your bank for yet another fee.

You’ll spend a good deal on fees, and the process takes longer than it should. There are some cool tools out there that are working to make the financial off-ramps simpler, but we’re still in the early days.

The faster and easier this process can be made, the more likely it is that crypto payments will be more popular. And for the person who solves this they have a great revenue-generating business on their hands.

I mean, think of how amazing Stripe has been for digital payments. Now add digital assets into the mix, and you can see the potential.

Potential fixes:

  • Creation of a crypto exchange-like service within an app that converts your crypto to select fiat currencies for you. You could even white-label some of the crypto exchange’s institutional services and do this for the user for a small fee.
  • Integration with various existing payment solutions. Apple Pay lets users use their Coinbase debit card for payments. You can also leverage a brand like MoonPay to enable easier on and off-ramps in the app. There’s a lot of disruption potential here. There are a handful of companies doing this, proving it is viable, but not enough yet to be competitive.

Communication And Education Issues In Web3

In addition to the basic functionality and ease of use issues with Web3 projects, we also have the marketing side of things.

Even if Web3 brands simplify the processes, they still talk about them in highly technical terms and make little to no effort to make it understandable to those not in the space. Below are a few of these issues and potential fixes in detail.

Marketing And Communications

Right now, Web3 is by engineers and for engineers. People are working on use cases that can really help non-technical people with their day-to-day lives, but they’re not succinctly communicating how it can help them.

And so, these great tools are being overlooked by the people they’re built to help.

One of the biggest opportunities I see is in better marketing and communications.

We, of course, need copy that explains what a product does. But more so, we need good UX copywriters and content producers to create information and education on how to simply set up the service and get the most from it. Without this, you might be able to attract new users, but they won’t get the most from your tool or stick around for a long time.

Make it simple, remove the jargon, and ensure even complete non-technical newbies understand how to achieve the key benefit with minimal effort. Manage to do this, and the project should succeed.

Potential fixes:

  • Hire technical writers from customer-facing, but highlight technical, Web 2.0 brands to help simplify messaging.
  • Make use of existing communication channels. A lot of Web3 brands don’t offer a bridge between something like email and Discord, meaning only those already in the space get the detail they need to onboard effectively.

Simplifying Transactions

There are two major problems with blockchain transactions right now:

  1. Addresses,
  2. The way transactions are processed.

Let’s first look at addresses.

My public Ethereum address is 0xde590D7ba25Ae2eCEAbbde7546D4Cbe94cc66961.

That’s not a typo. If I want someone to send me something, I need to give them that address. And they need to type it into the recipient field when sending funds without a mistake.

If either one of us messes it up, the transaction doesn’t fail, but the assets being sent are lost. Yeah, that’s right. You don’t get a nice warning message. The funds are sent to an address that doesn’t exist, and you’ve no way of easily getting them back.

These long hashes for addresses are also terrible when it comes to figuring out who sent what and when. Here’s a look at the Etherscan run down for my address:

Finding a particular transaction in that mess is insanely difficult. We need a way to simplify the way people refer and identify accounts and how the transactions are listed. The long-form cryptographic hashes are so user-unfriendly it’s unreal. It’s honestly amazing they’ve managed to get this far.

One of the tools aiming to help with this is ENS Domains. Much like buying a website domain, you buy an ENS domain, and that shows up instead of the long hash.

In the above, I had that insanely long hash as my address. With an ENSDomain, someone doesn’t need that as they can find my account by searching for PJBoyle.eth. That makes it much easier to find and send me assets or see how I’m engaging on the chain. But it’s only for Ethereum, which is why we also need that interoperability I mentioned earlier.

The second issue is in the way transactions are processed.

A lot of dApps need you to sign the agreement at each and every stage. Basically, to action one thing on the chain, you might have to stop the process in order to click “agree” multiple times. It’s a longer, more inefficient way of doing things and requires too much action from the user.

A solution that rolls all of these actions into one for a single-user authentication could improve the UX. Here’s an example diagram:

above is how a typical Defi app works today

below is how I think it should work

first, complete all actions (on simulated data if necessary), then batch-sign everything. more than one signature per interaction should be an anti-pattern pic.twitter.com/wQ8aSv0kNQ

— Hasu⚡️🤖 (@hasufl) June 20, 2022

Both of these improvements would make transacting so much easier and simpler, which should enable more people to get into Web3.

Potential fixes:

  • Roll out more services like ENS Domains, where abstract addresses are transformed into easily memorable phrases.
  • Reduce the load on the user. Don’t make them triple-check everything. Reduce the number of steps they have to take by rolling all confirmations into one approval.
Today’s Problems Are Tomorrow’s Opportunities

All of these problems are really because of the early nature of the tech.

None of the above will be the end of Web3, but for the people or teams who are able to solve them and make the entire ecosystem more user-friendly, these problems could be the catalyst that grows tomorrow’s most impactful businesses.

JavaScript Snippets For Better UX and UI

JavaScript can be used to significantly improve the user experience (UX) and user interface (UI) of your website. In this article, we will discuss some JavaScript snippets that you can use to boost the UX and UI of your website.

UNLIMITED DOWNLOADS: 500,000+ WordPress & Design Assets

Sign up for Envato Elements and get unlimited downloads starting at only $16.50 per month!

Smooth Scrolling

Smooth scrolling is a popular UX feature that makes scrolling through web pages smoother and more fluid. With this feature, instead of abruptly jumping to the next section of the page, the user will be smoothly transitioned to the next section.

To add smooth scrolling to your website, you can use the following JavaScript code:

$('a[href*="#"]').on('click', function(e) {
  e.preventDefault()

  $('html, body').animate(
    {
      scrollTop: $($(this).attr('href')).offset().top,
    },
    500,
    'linear'
  )
})

This code will create a smooth scrolling effect whenever the user clicks on a link that includes a # symbol in the href attribute. The code targets all such links and adds a click event listener to them. When the user clicks on a link, the code will prevent the default action of the link (i.e., navigating to a new page) and instead animate the page to scroll smoothly to the section of the page specified by the link’s href attribute.

Dropdown Menus

Dropdown menus are a common UI element that can help to organize content and improve the navigation of your website. With JavaScript, you can create dropdown menus that are easy to use and intuitive for your users.

To create a basic dropdown menu with JavaScript, you can use the following code:

var dropdown = document.querySelector('.dropdown')
var dropdownToggle = dropdown.querySelector('.dropdown-toggle')
var dropdownMenu = dropdown.querySelector('.dropdown-menu')

dropdownToggle.addEventListener('click', function() {
  if (dropdownMenu.classList.contains('show')) {
    dropdownMenu.classList.remove('show')
  } else {
    dropdownMenu.classList.add('show')
  }
})

This code will create a simple dropdown menu that can be toggled by clicking on a button with the class dropdown-toggle. When the button is clicked, the code will check if the dropdown menu has the class show. If it does, the code will remove the class, hiding the dropdown menu. If it doesn’t, the code will add the class, showing the dropdown menu.

Modal Windows

Modal windows are another popular UI element that can be used to display important information or to prompt the user for input. With JavaScript, you can create modal windows that are responsive, accessible, and easy to use.

To create a basic modal window with JavaScript, you can use the following code:

var modal = document.querySelector('.modal')
var modalToggle = document.querySelector('.modal-toggle')
var modalClose = modal.querySelector('.modal-close')

modalToggle.addEventListener('click', function() {
  modal.classList.add('show')
})

modalClose.addEventListener('click', function() {
  modal.classList.remove('show')
})

This code will create a modal window that can be toggled by clicking on a button with the class modal-toggle. When the button is clicked, the code will add the class show to the modal window, displaying it on the page. When the close button with the class modal-close is clicked, the code will remove the show class, hiding the modal window.

Sliders

Sliders are a popular UI element that can be used to display images or other types of content in a visually appealing and engaging way. With JavaScript, you can create sliders that are easy to use and customizable to fit your website’s design.

To create a basic slider with JavaScript, you can use the following code:

var slider = document.querySelector('.slider')
var slides = slider.querySelectorAll('.slide')
var prevButton = slider.querySelector('.prev')
var nextButton = slider.querySelector('.next')
var currentSlide = 0

function showSlide(n) {
  slides[currentSlide].classList.remove('active')
  slides[n].classList.add('active')
  currentSlide = n
}

prevButton.addEventListener('click', function() {
  var prevSlide = currentSlide - 1
  if (prevSlide &lt; 0) {
    prevSlide = slides.length - 1
  }
  showSlide(prevSlide)
})

nextButton.addEventListener('click', function() {
  var nextSlide = currentSlide + 1
  if (nextSlide &gt;= slides.length) {
    nextSlide = 0
  }
  showSlide(nextSlide)
})

This code will create a slider that can be navigated by clicking on buttons with the classes prev and next. The code uses the showSlide function to show the current slide and hide the previous slide whenever the slider is navigated.

Form Validation

Form validation is an essential UX feature that can help to prevent errors and improve the usability of your website’s forms. With JavaScript, you can create form validation that is responsive and user-friendly.

To create form validation with JavaScript, you can use the following code:

var form = document.querySelector('form')

form.addEventListener('submit', function(e) {
  e.preventDefault()
  var email = form.querySelector('[type="email"]').value
  var password = form.querySelector('[type="password"]').value

  if (!email || !password) {
    alert('Please fill in all fields.')
  } else if (password.length &lt; 8) {
    alert('Your password must be at least 8 characters long.')
  } else {
    alert('Form submitted successfully!')
  }
})

This code will validate a form’s email and password fields when the form is submitted. If either field is empty, the code will display an alert message prompting the user to fill in all fields. If the password field is less than 8 characters long, the code will display an alert message prompting the user to enter a password that is at least 8 characters long. If the form passes validation, the code will display an alert message indicating that the form was submitted successfully.

In conclusion, JavaScript is a powerful tool that can be used to enhance the UX and UI of your website. By using these JavaScript snippets, you can create a more engaging and user-friendly experience for your users. However, it is important to use these JavaScript snippets wisely and sparingly to ensure that they do not negatively impact the performance of your website.

The 14 Best .NET Developers: Your Secret Weapon to Digital Transformation

Our recommendation for most people is N-iX because of their well-rounded portfolio and wide range of .NET development services. Get in touch to see how they can help transform your business, today.

Whether you’re after new software or want to give an existing tool a face lift, a .NET developer is the way to go for anything built on Microsoft’s .NET framework. To help you find the best .NET developer for you, we looked at 43 of the best and narrowed them down to the top 14.

No matter which you choose, every developer on our list has meaningful certifications and a proven track record of transparent communication, industry expertise, full stack proficiency, and clean code architecture.

The Best .NET Developers and Development Companies

  • N-iX – Best overall
  • Chetu – Best for custom CRM, ERP, and business management solutions
  • 10Pearls – Best for health and medtech projects
  • Altexsoft – Best for travel and hospitality software development
  • Brainsmiths Lab – Best developers for startup projects
  • EPAM Anywhere – Best for hiring individual .NET developers
  • Fingent – Best for custom real estate software
  • CShark – Best for fintech development projects
  • Hidden Brains – Best for HIPAA compliant software projects
  • Iflexion – Best for custom B2C and B2B client portals
  • MentorMate – Best for manufacturing and agriculture
  • Solw’it – Best for innovative IoT applications
  • Netguru – Best for identifying and fixing security vulnerabilities
  • ScienceSoft – Best for marketing and advertising projects
Company logos for our best .NET developers reviews

Is a .NET Developer The Right Choice?

.NET is best suited for enterprise-level applications, including desktop and web apps, with high performance requirements. It’s a powerful framework that can handle a wide range of applications.

However, it’s not necessarily the right framework for your next project.

  • Unsure of which framework or language is best? Consider a software development company
  • Need to fill in gaps with various types of developers? Try staff augmentation services
  • Interested in AI and machine learning? AI development companies are where it’s at
  • Looking for a mobile app in particular? A mobile app developer might be a better fit
  • Need a new website? Check out our favorite web design agencies
  • Know you want a WordPress site? Go with a WordPress developer
  • Want to re-imagine the user experience? UI/UX agencies specialize in that

If none of those quite fit the bill, you’re probably in the right place. Continue reading to learn about our favorite .NET developers, what they specialize in, how we narrowed them down, and what you should consider when making your final decision.

N-iX Review – Best Overall

N-iX, one of the best .NET developers.

N-iX has two decades of experience under their belt – they’re a powerhouse in the realm of .NET solutions. Just like the big names they’ve collaborated with – Siemens, Office Depot, and OpenText, to name a few – they cater to a diverse array of industries, including large-scale enterprises, burgeoning startups, and everything in between.

Whether it’s data analytics, IoT, game & VR development, or software QA and testing, N-iX does it all.

They offer four collaboration styles to suit your needs: team extension for seamless integration with your existing squad, end-to-end custom software development, product discovery to validate ideas, and consulting for expert guidance.

N-iX has a proven track record of creating top-notch enterprise software, web and mobile apps, cloud solutions, desktop apps, microservices, and cross-platform apps. Maybe you need to migrate or modernize existing applications? They’ve got you covered.

Their prowess in building secure, scalable solutions is commendable. Take RateSetter, a prominent UK-based peer-to-peer lending service – N-iX took their large, outdated monolithic software and turned it into agile, modern, and secure microservices that meet regulatory requirements with ease.

With an extensive range of services, specialized expertise, and a multi-faceted team capable of handling diverse projects across industries, N-iX stands out as a brilliant choice for anyone seeking a .NET solution that ticks all the boxes.

Chetu – Best for Custom CRM, ERP, and Business Management Solutions

Chetu, one of the best .NET developers.

While Chetu’s expertise in .NET spans across various industries, their wealth of experience in building complex software for diverse business functions sets them apart from the rest.

From field service management to operations, asset tracking, document management, facilities, and franchise management, Chetu has the expertise to create one-of-a-kind software that caters to the unique demands of your business.

They specialize in scoping the big picture, while also perfecting and executing the tiniest details to give you what you need.

Their impressive portfolio includes a custom franchise management tool for National Property Inspections, a complex data management solution for ADEA, and an asset management platform for PlanIt AV. Chetu has a knack for transforming your wish list into a tailored tool that fits your business like a glove – no more juggling between overpriced solutions or piecing together cheap alternatives.

Chetu’s services encompass .NET developer toolkits, microservices, Docker containerization deployments, app deployment, and mobile configurations, with a strong emphasis on .NET core development. They are well-versed in frameworks and languages such as .NET core, Accord.net, ML.NET, F#, Silverlight, Visual Studio, ASP.NET, Mono, and C#.

In a nutshell, Chetu is your one-stop solution for building customized, complex software to streamline how you do business.

10Pearls – Best for Health and Medtech Projects

10Pearls, one of the best .NET developers.

With an awe-inspiring clientele featuring Johnson & Johnson, AARP, National Institutes of Health, VillageMD, CVS Health, MedStar Health, and Amwell, this seasoned healthtech firm boasts 18 years of experience and a global team of experts.

They provide specialized healthtech consulting and software development services for both private and public organizations. Their focus is on enhancing patient care and workforce productivity with the right blend of innovation and expertise.

Their four operating models cater to every client’s unique needs: onshore for on-site collaboration, nearshore for real-time teamwork within the same time zone, offshore for swift project delivery and round-the-clock support, and rightshore – a custom blend tailored to each client.

This healthtech powerhouse develops patient portals, wearable devices, caregiver engagement apps, telemedicine apps, AR/VR medical software, AI-powered tools, data collection and analytics through CRMs, secure migrations, and API management, among other offerings. On top of that, they specialize in custom EHR and EMR solutions that combine everything you need to improve the patient experience from the first appointment to secure record management and post-visit communication.

With 10Pearls, you can expect nothing but the best – reliable healthtech solution tailored to your needs in hand, your patients and providers get the tech they need.

Altexsoft – Best for Travel and Hospitality Software Development

AltexSoft, one of the best .NET developers.

With a prestigious roster of over 200 clients, including heavyweights like Rakuten Travel, ASL Aviation, and Fareboom, AltexSoft stands as a trailblazer in the traveltech engineering landscape. From travel agencies to management solution providers and travel tech startups, this dynamic firm takes your vision and turns it into reality.

Their comprehensive service suite is tailored to accommodate your every need – from minimum viable product (MVP) development that gets your business to market at breakneck speeds to software reengineering that adapts to dynamic loads, scalability, and rapid changes.

AltexSoft offers three working models for optimal flexibility: team extension for quick starts and high scalability, dedicated team for seamless collaboration with your existing workforce, and hybrid teams that blend resources for a cost-efficient, balanced approach.

With an impressive force of 45,000+ specialists at your disposal, AltexSoft is well-equipped to tackle any challenge you throw their way.

AltexSoft’s portfolio is full of innovative projects, from revamping a multisite vacation rental booking system to integrating booking.com into a travel website, optimizing flight inventory management, and crafting algorithms for early booking prices. They’ve also built a search and booking module from scratch, a cross-platform flight schedule notifications app, and a machine learning tool that scores hotel amenities based on customer reviews.

But one of their most impressive feats is the co-creation of a mobile-first airline operations management environment, which speaks volumes to their ability to work on large-scale projects.

Their developers are well-versed in a range of languages and frameworks, such as C#, ASP.NET, WPF, TPL/Async, WCF, T-SQL, Xamarin, and LINQ, in addition to PHP, Java, and Python for a comprehensive development team.

Brainsmiths – Best Developers for Startup Projects

Brainsmiths, one of the best .NET developers.

Dedicated exclusively to startups, Brainsmiths is a trusted partner in the world of innovation. With expertise in data science, IoT, blockchain, and augmented reality, they go above and beyond standard cross-platform web development.

Brainsmiths seamlessly bridges the development skills gap for startups so they don’t have to hire in-house experts.

They’ve demonstrators their expertise across various projects such as tutoring platforms, email marketing platforms, project management software, meal planning portals, and fintech ecommerce.

As proficient masters in Microsoft technologies, including C#, ASP.NET, .NET Core, .NET MVVM, Microsoft Teams, SharePoint, and MSSQL, they boast the ability to turn ideas into minimum viable products within a remarkable 90-day timeframe.

From business automation and systems integration to infrastructure reengineering and custom app development, Brainsmiths excels in every aspect of the fast-paced startup world. On top of new development, they offer software modernization, maintenance, and monitoring services, ensuring a comprehensive approach to support you as your needs change.

Not merely consultants, Brainsmiths prides themselves on being doers, working tirelessly to bring your vision to life. With a balanced, agile approach that embraces change and dynamic momentum, they are your ideal partner in turning your startup dream into a reality.

EPAM Anywhere – Best for Hiring Individual .NET Developers

EPAM Anywhere, one of the best .NET developers.

Streamlined communication and alignment with a single developer allows for fast, high-quality results and easy pivots as your goals change.

EPAM Anywhere’s 3,700+ developers, 30 years of experience, and expertise with key .NET technologies provide an unparalleled resource for your company to tap into. A single developer from their platform offers an efficient, budget-friendly alternative to building an in-house team or outsourcing to a full team.

They thoroughly vet all developers on their platform to ensure companies have access to top experts with the ideal blend of skills and experience for any .NET project. Businesses can hire EPAM Anywhere’s .NET developers for web apps, desktop apps, mobile apps, APIs, CMS projects, or any other development needs.

Any developer you hire will deliver fast, high-quality results thanks to close collaboration and communication throughout a project’s lifecycle. With EPAM, you gain flexibility to pivot or scale your .NET development as strategic priorities change.

They also provide necessary technology, workstations, and management to the developers so you can focus on running your business.

Minimum project duration is six months and developers can get started on whatever you need in as little as two weeks – much faster than it would take to onboard and align an entire team.

Fingent – Best for Custom Real Estate Software

Fingent, one of the best .NET developers.

As a real estate professional, you’ve probably tried your fair share of off-the-shelf property management software and CRMs. Some are easier to use than others, but they all seem to fall short in one way or another – they either lack key features, have clunky UX, or come with hefty price tags for features you’ll never use.

They aim to be one-size-fits-all solutions for dozens of industries, but real estate management involves workflows that generic software just can’t support.

Fingent gets that. They work with a range of industries, but their real estate clients are some of the happiest. And it’s easy to see why. They take the time to get to know you so their custom software caters to how you work.

On top of that, they can easily integrate your new software with the tools you already use and love. They handle the complex backend and APIs so you don’t have to. All that to say, you can keep using your favorite property listings service, renter management tools, CRM, or accounting software and Fingent will pull data from all of them into one place.

Or they can create a solution that does it all for you.

Either way, there’s no extra fluff or wasted features to pay for. You get exactly what you need to dominate in your market, no more, no less.

If you’re tired of making excuses for your less-than-ideal tech stack and want a solution that actually supports your business, Fingent should be your first call. Their custom software gives you the freedom and control you need to focus on what really matters: your clients and growing your business.

CShark – Best for Fintech Development Projects

CShark, one of the best .NET developers.

CShark is a .NET development company that understands the fintech industry’s complexities with an unwavering commitment to success. With their impressive track record of supporting clients such as ENO, Fenergo, ASA International, and PastDue, you know they’re up for the challenge.

By immersing themselves in your company, asking the right questions, and truly getting to the root of the issue at hand, they deliver more than just software development services – they provide predictability, efficiency, and a wealth of knowledge for their fintech clients.

Established enterprises can count on comprehensive solutions that streamline operations, optimize processes, minimize risks, and ensure compliance.

On the other end of the spectrum, startups can expect dedicated support to help turn their ideas into fully-functioning products, from establishing fit in the market to navigating regulatory compliance and data security in a chaotic landscape.

Their global presence, with operations in major business hubs across Europe, the UK, Canada, and Singapore, makes them an ideal partner for businesses seeking end-to-end digital transformation or start-ups looking to bring their innovative ideas to fruition. When you work with CShark, you’re placing your fintech project in the hands of experts who not only understand the industry’s intricacies but also demonstrate empathy, confidence, and unwavering support.

Hidden Brains – Best for HIPAA Compliant Software Projects

Hidden Brains, one of the best .NET developers.

From managing patient records and scheduling appointments to handling billing and inventory, medical-grade software has a huge impact on your level of productivity, efficiency, and ultimately, patient satisfaction.

Hidden Brains’ team of .NET developers has years of experience building solutions for medtech companies of all sizes, from private practices to large hospital networks.

They get the unique challenges you face, including the big one – keeping up with the rigid demands of healthcare and privacy laws. Hidden Brain stays on top of it for you and ensures your custom solution keeps you HIPAA compliant from day one.

What’s more, Hidden Brain gets how frustrating clunky, non-intuitive medical software can be. They design every custom solution with the end user in mind, whether you have physical therapists, nurses, doctors, or dentists on staff. If software that’s easy to navigate and cuts down on the time your staff spends clicking through screens sounds too good to be true, you’re not wrong for off-the-shelf solutions.

However, Hidden Brain is dedicated to shaking things up and giving you your time back – time you can use to deliver quality, personalized care for your patients.

Whether you want to improve patient flow, offer telemedicine services, or create a single system to run your entire operation, Hidden Brain has the experience to develop a custom solution tailored to your needs.

Iflexion – Best for Custom B2C and B2B Client Portals

Iflexion, one of the best .NET developers.

If you’re losing sleep over security issues, slow load times, hard to use interfaces, or downtime concerns with your client-facing portal, it’s time to rethink your tool stack. Your client portal says a lot about your business, whether you want it to or not.

And one-size-fits all portal solutions (or those baked into other tools you use to run your business) aren’t up for the task of meeting your business’s unique needs.

The good news is, there’s a better way. Iflexion’s .NET developers have extensive experience creating custom portals from the ground up. On day one, they work directly with your team to understand what’s not working with your current portal and what your ideal solution looks like.

Do slow page loads leave your clients frustrated? They can help with that.

Worried about keeping sensitive data safe? They’ll implement powerful security features to put your mind at ease.

Aside from solving all of your biggest problems, custom portals look more professional. Not only do they put your branding front and center, they can also integrate seamlessly with your other systems. And scale as your business grows.

Whether you’re a marketing agency, SaaS company, school, law firm, or something else entirely, the time you’ll save and increased client satisfaction are well worth the investment.

Forget about settling for an off-the-shelf solution. Iflexion’s .NET development services can give you the custom portal you’ve always needed but never had.

MentorMate – Best for Manufacturing and Agriculture

MentorMate, one of the best .NET developers.

Unlike generic software tools that try to help everyone, MentorMate helps manufacturing and agriculture businesses tackle industry-specific problems like equipment downtime and regulatory non-compliance.

All while helping you improve productivity, profitability, and even Industry 4.0 adoption.

MentorMate knows the ins and outs of manufacturing and agriculture – that’s what makes them so good at what they do.

Need a better inventory management system, for example? They can give you everything you need for real-time visibility into raw materials and finished goods to help optimize stock levels and reduce waste. Talk about a game-changer for improving efficiency and cutting costs!

Struggling with supply chain? They’re no strangers to streamlining communication and avoiding delays when working with suppliers or distributors.

From quality control and monitoring systems to predictive maintenance schedules, MentorMate’s custom .NET solutions mean fewer surprises, downtime, and unpredictable situations.

Regardless of what you need (even if you’re not sure what you need), they have a proven track record of optimizing processes and future-proofing businesses.

Solw’it – Best for Innovative IoT Applications

Solw'it, one of the best .NET developers.

If you want the rewards of IoT but lack the know-how to make it happen, Solw’it can fill your IoT knowledge gaps, handling everything from planning and development to deployment and management. The result? A revolutionary IoT solution without having an expert on staff.

While cost is a major hurdle for IoT implementation, Solw’it helps keep costs as low as possible by determining the most budget-friendly solutions up front.

They also help drive down maintenance costs with optimized, clean systems that make for easy updates, upkeep, and changes.

Plus, the initial investment in IoT pays off through increased efficiency, productivity, and reduced waste.

If you’re worried about implementing new technology because of the headache or potential disruptions, Solw’it understands. They take every measure to make integration a breeze. And they know how to minimize disruptions because they’ve done it so many times.

When it comes to security, they take utmost care by including data encryption, access control, and network segmentation when needed so you know your infrastructure is protected.

On top of their IoT expertise, they know a thing or two about analytics. They can even help you make sense of all the data you collect from your new systems to help you make strategic decisions and optimize operations even more.

IoT may seem complex, but with a partner like Solw’it, it leads to smarter business.

Netguru – Best for Identifying and Fixing Security Vulnerabilities

Netguru, one of the best .NET developers.

Securing critical systems and sensitive data can feel like an overwhelming (or impossible) task. With the help of an expert partner like Netguru, protecting your .NET infrastructure doesn’t have to be a source of constant frustration.

How do they do it? With comprehensive security vulnerability and remediation services.

Their team of security experts know how to identify weaknesses and potential exploits before anyone else can find them. Almost like a hacker breaking into your system to discover your vulnerabilities, rather than take advantage of them.

If they happen to find issues, then can work directly with your team to patch security holes and reinforce your infrastructure with minimal disruptions or downtime.

Thanks to Netguru, you longer have to worry about the high costs or lack of internal expertise required to manage vulnerabilities in-house.

Whether it’s legacy software, rapid growth, attempted cyber attacks, or emerging technologies (like working in the cloud or IoT devices) that are introducing potential vulnerabilities, you don’t have to face the challenge alone.

Netguru offers numerous cybersecurity services, including audits, consulting, training, and scans. Regardless of what you need, they’re here to help.

ScienceSoft – Best for Marketing and Advertising Projects

ScienceSoft, one of the best .NET developers.

Whether you’re a startup needing to market the latest tech, an established enterprise looking to streamline the marketing department, or a marketing agency desperate to find a better way to manage campaign data, ScienceSoft has you covered.

With their help, you can gain a competitive advantage and accelerate your marketing efforts without feeling overwhelmed by constant changes. Or worrying about paying top dollar for marketing tools that simply don’t cut it.

Their portfolio speaks for itself: they developed an enterprise-grade planning platform that spans multiple channels for the largest advertising agency in the US.

A custom CRM capable of supporting two thousand car retailers isn’t out of their realm, either.

Needless to say, ScienceSoft can change the way you run your marketing campaigns. For example, they can help sync data in real-time across all of your marketing platforms, giving you every data point at your fingertips.

They can also build custom social media software, data management platforms, advertisement solutions, and loyalty software.

Better yet, they can combine everything you need – and nothing you don’t – in one system.

From integrating CRM, marketing automation and analytics tools to leveraging AI and machine learning, you can automatically nurture leads, optimize campaigns in real-time, and deliver hyper-personalized experiences – while spending less time doing it.

With a lead time of just 2 to 4 weeks, you can get started revolutionizing your growth system with ScienceSoft right away.

How We Determined The Top .NET Developers

We started with 43 .NET developers and development companies, including: 10Pearls, Algoworks, AltexSoft, Belitsoft, Binary Studio, Brainhub, Brainsmiths Labs, Chetu, Ciklum, Codica, CSHARK, Cyber Infrastructure, Inc., Daxima, ELEKS, EPAM Systems, Exadel, Fingent, Grapecity, Grid Dynamics, Hidden Brains, Iflexion, Infragistics, Intersog, ITechArt Group, MentorMate, N-iX, Neoteric, Netguru, PixelCrayons, Redwerk, Scalefocus, ScienceSoft, Softura, Software Mind, Solvd, Solw’it, Sphere Partners, STX Next, SumatoSoft, Syncfusion, Telerik, Toptal, X-Team

Using the criteria below, we narrowed the list to the top 14.

Expertise based on past projects: We dove deep into each company’s portfolio to gauge their proficiency in different industries. We scrutinized the quality, scope, and diversity of their previous work to make sure we make accurate recommendations.

Certifications: A developer’s certifications are the badges of honor they’ve earned in the digital realm. When putting our list together, we looked for credentials such as Microsoft Certified Azure Developer Associate, Microsoft Certified Azure IoT Developer Specialty, Microsoft Certified Power Platform Solution Architect Expert, Microsoft Certified Power Platform Developer Associate, and Microsoft Gold Partner status attesting to their mastery of the platform and dedication to honing their craft.

Full stack proficiency: To make it on our list, a developer has to be proficient in both front-end and back-end skills. Why? Because full stack developers have a holistic understanding of the entire development process, ensuring seamless integration of all components, from visually stunning interfaces to powerful backend functionality.

Eye for aesthetics: We’ve handpicked developers who can skillfully weave together form and function. Possessing a discerning eye for aesthetics, these developers ensure that your application excels not only in efficiency and reliability but also in visual appeal, user-friendliness, and overall user experience.

Clean architecture: Clean code is a necessity because it makes your application easy to understand and change. With an organized architecture, anyone can add new features, remove things you no longer need, and scale the application. Having clean code also improves collaboration and speeds up the project, as it’s easier for others to read and comprehend. Ultimately, clean code results in higher-quality software and a more efficient development process.

What to Consider When Choosing a .NET Developer

We did the heavy lifting and found the top .NET developers out there. However, every project is unique, and the ideal partner for one project may not be the best fit for another. While we can’t identify the perfect developer for every situation, we can help guide you to the right option for your next project.

Use the following considerations to narrow the list further and find the right option for you and your business.

Services needed

When evaluating developers, we took into account their versatility in handling various project types, such as crafting tailor-made software, designing mobile and desktop applications, developing APIs, working with cloud technologies, managing database projects, maintaining software, migrating and modernizing systems, providing consultation, and integrating systems.

Some developers we analyzed are akin to a Swiss Army knife, equipped to tackle a broad array of tasks, while others excel in niche services.

Ultimately, the ideal choice hinges on what you need.

Data ownership

Ownership of data and code in a .NET project depends on the agreement between you and the developer, with common scenarios being work for hire, custom development with reusable components, licensing, or joint ownership.

It’s crucial to have a clear contract outlining IP rights, data ownership, and other terms to ensure the appropriate arrangement.

Ongoing support and maintenance

Support and maintenance services offered by .NET developers are crucial for keeping applications up-to-date and secure.

They ensure your software adapts to technological changes and remains relevant while also addressing bugs and vulnerabilities to minimize negative impacts. Because of that, we focused on developers and agencies that provide post-project support.

However, not everyone needs these services.

Communication preferences

We selected developers who employ a diverse array of collaboration methods, including regular meetings, email correspondence, instant messaging, in-person presentations, project management tools, and version control systems.

We believe that using a blend of these approaches helps maintain open channels of communication, leading to more efficient project execution and superior end results.

However, the best option for you depends on how you wish to communicate with your developer.

The Best Handoff Is No Handoff

Many companies organize their workflows around projects and departments. Especially in large companies, work often travels from one place to another, often getting stuck between emails and Slack messages, and often “refined” on its never-ending journey between design and engineering teams.

This inevitably brings up the question about the design hand-off: that magical moment when designers are done with their work and developer can take over. Most importantly, that’s where designers must stop working, and move on to other work — unless the scope changes or late adjustments creep their way in.

The “No Handoff” Method

Last week, I stumbled upon an interesting article about the no-handoff method, in which Shamsi Brinn shows an alternative to typical design hand-offs. Shandi shows a fluid model where product and engineering teams work on the product iteratively all the time, with functional prototyping being the central method of working together.

With the process, the working prototype is the living spec of the project and a shared language for the team. No more translation is needed because everyone works on the same prototype. The problem space and the solution space are explored by designers and engineers collaboratively, and the entire workflow is organized around the product, rather than company’s internal structure.

The “Hot Potato” Process

This reminded me of the Hot Potato Process by Dan Mall and Brad Frost, where ideas are passed quickly back and forth from designer to developer and back to designer then back to developer for the entirety of a product creation cycle — similar to throwing hot potato back and forth (audio, video).

From my personal experience, I can only testify that the best collaboration doesn’t have any handoffs between teams. There, work flows seamlessly from design to engineering and back — with both teams working simultaneously, and discussing issues as they occur, during the entire product lifecycle.

There are phases of independent work for sure, but there are also plenty of overlaps for collaborative work, which are opportunities to discuss the progress, explore what is and what isn’t viable and hence avoid lurking issues down the line.

Create As Many Overlaps As Possible

Of course, the process works well for small product teams. But what if a part of the product is outsourced to an external agency? Many companies choose the route of extensive documentation — almost to the last pixel, along with a brief explaining the strategy and the thinking behind the design.

This isn’t enough though. Design decisions have to be informed by technical implementations and its limitations. There is no universal language around design patterns and their interaction design either. And not every design detail can be implemented in an accessible and performant way. This is why beautiful mock-ups turn into painfully slow and inaccessible monsters.

We can reduce the risks of hand-offs with dedicated overlaps between designers and engineering teams. With regular check-ins. Weekly reviews. Shared channels for communications. Visibility into the work done. Usability testing of functional prototypes and small but regular design revisions.

Design is a team work. It involves everybody who contributes to the website — from customer service and marketing to developers and designers. Any overlaps you can create will benefit the teams, their productivity, and ultimately your users.

Wrapping Up

So we want to move away from handoffs. But how to convince teams to change their workflow entirely? With a small experiment on a small project. Pick a project where you could test the waters and suggest a collaborative process. Ask what designers could do while developers are busy. Ask what developers could do while designers iterate. And enable both teams to work together, at the same time.

Ultimately, the success depends on one simple thing: just how well the teams work together. And if they can’t collaborate particularly well, chances are high that a design hand-off won’t make it any better, and a major change in the team culture will need to happen first.

You can find more details on design patterns and UX in the video library on Smart Interface Design Patterns 🍣 — with a live UX training that’s coming up in September this year.

Moving From Vue 1 To Vue 2 To Vue 3: A Case Study Of Migrating A Headless CMS System

This article is a sponsored by Storyblok

One of the greatest challenges in software development is not in creating new functionality but in maintaining and upgrading existing systems. With growing dependencies and complexity, it can be a tedious task to continuously keep everything updated. This becomes even more challenging when upgrading a base technology that the whole system runs on.

In this article, we will discuss how Storyblok solved the challenges of migrating the front-end interface of our headless content management system from Vue 1 to Vue 2 to Vue 3 within six years of growing the startup.

While migrating larger front-end systems can be a daunting task, it can be helpful to understand the reasons and strategies behind it. We’ll delve into the considerations and steps involved in such a migration and explore the potential benefits and drawbacks. With a clear understanding of the process, we can approach the migration with more confidence and ensure a smooth transition for our users and stakeholders.

The Vue Ecosystem & Storyblok’s Early Days

The Vue.js framework’s first large pre-beta release happened in late 2016, and Storyblok began work on a full prototype built on top of Vue in late 2015. At the time, Vue was still a relatively new framework, and other more established options like React were available. Despite this, Storyblok decided to take a chance on Vue and built their own prototype on top of it. This turned out to be a good decision, as the prototype worked well, and up to today, Vue is kept as the underlying framework for the front-end interface.

Over the years, Storyblok has played a key role in the growth and development of Vue, participating in forums, conferences, and meetups, sponsoring certain projects, as well as contributing to the Vue ecosystem through open-source projects and other initiatives. As Storyblok grew together with the Vue community over the years, Vue started upgrading its framework, and Storyblok began growing out of its prototype to become a fully-fledged product. This is where our migration story starts.

Ground-up Migration vs. Soft Migration

There were two main points in time when Storyblok was facing large migration challenges. The first one was when the upgrade from Vue 1 to Vue 2 happened. This went hand in hand with the update from Storyblok Version 1 to Storyblok Version 2. The decision was to completely rebuild the system from scratch. This is what we’ll call Ground-up migration. The second large migration happened when going from Vue 2 to Vue 3, where the front-end interface did not change. The existing codebase was updated in the background without visual changes for the user, and this is what we’ll call Soft migration.

Ground-up migration allows for greater flexibility and control over the design and architecture of the new system, but it can be a time-consuming and resource-intensive process. For Storyblok, it allowed the development of an open-source Blok Ink design system as the core of the new system. This design system could then simultaneously be used by our customers to build their own extensions.

Soft migration, on the other hand, can be quicker and more cost-effective, but it’s strongly limited and influenced by the current design and architecture of the existing system. Upgrading large codebases and all their dependencies can take months to achieve, and the time for this can be hard to find in a growing business. When thinking about customers, soft migration tends to be easier because the user doesn’t have to relearn a whole new interface, and no large marketing and communication resources need to be allocated towards this kind of migration.

How were these migration decisions made from a business perspective? After Storyblok was launched as a product in 2017 with Vue 1, it was continuously improved and extended with new features. In 2019, the team received its first seed investment, which allowed them to hire more developers to work on Storyblok. In 2020, work began on Storyblok V2 with Vue 2, with around five developers starting on the project for the first time. Instead of updating the old codebase from Vue 1 to Vue 2, the team decided to start with a completely new codebase. This gave the new team two main benefits:

  1. The developers were fully involved in creating the architecture of the new system;
  2. They learned how the system worked by rebuilding it.

In the core, the decision to make a ground-up migration was correct because the flexibility of that migration allowed the team to build a better, newer, and more stable version of the prototype while also understanding how it works. The main drawbacks of the ground-up migration were the cost of time and resources and getting the buy-in from the customers to switch from the old to the new version.

As Storyblok continued to evolve and improve, the codebase needed to be upgraded from Vue 2 to Vue 3. Migrating to the new version involved updating large amounts of code and ensuring that everything continued to work as expected. In this migration, we had to invest a lot of resources in retesting the interface, as well as allocating time for the developers to learn and understand the changes in Vue 3. This can be especially challenging when working with a large team, as there may be different codebases and business needs to consider.

Ultimately, the decision between these two approaches will depend on the specific needs and circumstances of the migration, including the following:

  • Resources and expertise available,
  • Complexity and size of the system,
  • Desired level of control and flexibility over the design and architecture of the new system.

It’s important to have a clear plan in place to guide the migration process and ensure a smooth transition, so in the next chapter, we will look into what that plan looked like for us.

Strategies For Large Migrations

These five factors are essential to consider when planning a migration:

Time Creating a timeline for the migration
Functionality Identify and prioritize critical parts of the system to migrate
Resources Use automation and tools to support the migration
Acceptance Engage and communicate with users
Risk Monitor and evaluate the migration process

Creating A Timeline

One of the main challenges of migration is getting the buy-in from the organization, clients, and teams. Since migrations aren’t adding any new functionality, it can be hard to convince a team and the product owners of the importance of migration. However,

In the long term, migrations are necessary, and the longer you put them off, the harder they will become.

Secondly, migrations tend to take more than a few weeks, so it’s a harder and more tedious process that has to be planned with all the developers and stakeholders. Here is what our timeline looked like:

Going from Vue 1 to Vue 2

This process took us around two years from start to finish:

  • Before Mid–2020: Develop new features in the old version.
  • 2020 June: Identify and develop ‘core’ components in a new open-source design system.
  • 2020 November: Create a new Vue 2 project.
  • 2020 Nov — 2021 August: Redevelop all parts of the old app in the new app with the new design system.
  • 2021 August: Beta Release of parts of the new application (e.g., our Visual Editor).
  • 2021 August — 2022 August: Add all the missing functionality from the old app, add new features, and improve overall UX through customer feedback.
  • 2022 August: Official release of the new app.
  • During that time: onboard 20+ developers, designers, QAs, and product owners.

Going from Vue 2 to Vue 3

This process took us around eight months:

  • 2022 July — 2022 November: Start migrating the Design System to Vue 3.
  • 2022 November — 2023 January: remove all the ‘old’ breaking functionality and update or replace old dependencies that depend on Vue 2.
  • 2022 December: Several meetings to explain what changed in Vue 3 with developers and stakeholders and how the transition will happen.
  • 2023 January: Introduce the Vue 3 codebase, switch developers to the new codebase, and thoroughly test and start developing in Vue 3.
  • 2023 February: Launch the Vue 3 version into production.

To create a timeline, you need to identify all the parts of the migration first. This can be done in an excel sheet or a planning tool like Jira. Here is an example of a simple sheet that could be used for creating a rough timeline. It can be useful to split different areas to separate sheets to divide them into the teams they belong to.

Identifying And Prioritizing Functionality to Migrate

In order to manage the cost and resources required for the migration, it is essential to identify and prioritize the critical features and functionality of the system that need to be migrated. For us, it meant starting bit by bit with more important functionality. When we built the new version of Storyblok, we started with our most important core feature, the “Visual Editor,” and built an entirely new version of it using our Design System. In any migration, you should ask yourself these questions to find out what the priorities are:

  • Is the goal to create a completely new version of something?
  • What parts does the system have? Can some of them be migrated separately?
  • Which parts of the system are most important to the customer?
  • Who knows the system well and can help with the migration?
  • Does every developer need to work on the migration, or can a few ‘experts’ be selected to focus on this task?
  • Can I estimate how long the migration will take? If not, can I break down the parts of the system more to find out how long smaller parts of the system can be migrated?

If you have multiple sub-parts that can be migrated separately, it’s easier to split them to different people to work on the migration. Another big decision is who is working on the migration. For our Vue 1 to Vue 2 migration, all our developers worked on creating the new functionality, but on the Vue 2 to Vue 3, it was one expert (the person who is writing this article) who did most of the migration and then it was handed over to the teams to finish and retest the whole application to see if everything was still working as it should.

At the same time, I organized some training for the developers to dive deeper into Vue 3 and the breaking changes in the system.

The core of the migration strategy always depends on the knowledge of the system as well as the importance of the features to be migrated.

More important features will be migrated and worked on first, and less important things can be kept to be improved in the end.

Use Automation And Tools to Support The Migration

Since a migration process is always very time-consuming, it pays off to invest in some automation of tedious tasks to find out all the problems of the migration. For our migration from Vue 2 to Vue 3, the migration build and its linting were very helpful in finding all the potential problem areas in the app that needed to be changed. We also worked with hand-written scripts that iterate through all Vue files in the project (we have over 600 of them) to automatically add all missing emit notations, replace event names, that updated in Vue 3 and update common logic changes in the unit tests, like adding the global notation.

These scripts were a large timesaver since we didn’t have to touch hundreds of files by hand, so investing time in writing such scripts can really pay off. In the core, utilizing regex to find and replace large logic chunks can help, but for the last final stretch, you will still spend hours fixing some things manually.

In the final part, all the unit and end-to-end tests we already had, helped to find some of the potential problems in the new version of our app. For unit testing, we used Jest with the built-in Test Utils as well as the Vue Testing Library, for the e2e tests, we’re using Cypress with different plugins.

Engage And Communicate With Users

If you create a new version of something, it’s essential to make sure that the experience is not getting worse for the customer. This can involve providing training and support to help users understand and use the new version, as well as collecting feedback and suggestions from users to help improve the new system. For us, this was a very important learning during the ground-up migration from Vue 1 to Vue 2 because we continuously collected feedback from the customer while rebuilding the app at the same time. This helped us to ensure that what we were building was what the customers wanted.

Another way was to have the beta version accessible way ahead of the new version being finished. In the beginning, we only made the Partner Portal available, then the Visual Editor, then the Content Editing, and lastly, the missing parts of the app. By gradually introducing the new parts, we could collect feedback during the development time and adjust things where the customer experience was not perfect yet.

In any scenario, it will be important to ask yourself these questions in a ground-up migration:

  • How can we collect feedback from our customers early and often to ensure what we’re building is working?
  • How can we communicate with the existing customers to make them aware of using the new version?
  • What are the communication channels for the update? Can we leverage the update with the marketing team to make users more excited about it?
  • Who do we have internally that handles communication, and who are the stakeholders who should be updated regularly on the changes?

For us, this meant building ‘feedback buttons’ into the interface to collect feedback from the users starting to use the new version. It pointed to a form where the users could rate specific parts but also give open feedback. This feedback was then handed back to the design team to evaluate and forward if it was valid feedback. Further, we added channels in our Discord to hear directly from developers using the system and introduced ‘tour’ functionalities that showed users where all the buttons and features are located and what they do. Finally, we added buttons to the old app to seamlessly switch between the old and new versions. We did various campaigns and videos on social media to hype our community about using the new version.

In all cases, it’s crucial to find out who the core stakeholders and communicators of the migration are. You can find that out with a simple impact/influence matrix. This matrix documents who is impacted by the migration and who should have how much influence over the migration. This can indicate who you should be in close contact with and who might only need to be communicated with occasionally.

Monitor And Evaluate The Migration Process

Since a migration process will always take a few months or even years to accomplish, it’s essential to monitor the process and make sure that after a few months, it’s still going in the right direction.

Here are some questions that can help you figure out if you’re on the right track:

  • Have all the areas and functionalities that need to be migrated been defined? How are we tracking the process of each area?
  • Are all stakeholders, including users and other teams, being effectively communicated with and their concerns addressed?
  • Are there unexpected issues that have arisen during the migration that require you to adjust the budget and time frame of the migration?
  • Is the new version being properly tested and validated before being put into production?
  • Are the final results of the migration meeting the expectations of the users and stakeholders?

During the different migration phases, we hit several roadblocks. One of them was the customer’s expectations of having the exact same functionality from the old app in the new app. Initially, we wanted to change some of the UX and deprecate some features that weren’t satisfying to us. But over time, we noticed that it was really important to customers to be close to what they already knew from the older version, so over time, we moved many parts to be closer to how the customer expected it to be from before.

The second big roadblock in the migration from Vue 2 to Vue 3 was the migration of all our testing environments. Initially, we didn’t expect to have to put so much effort into updating the unit tests, but updating them was, at times, more time-consuming than the app itself. The testing in the “soft migration” had to be very extensive, and it took us more than three weeks to find and fix all the issues. During this time, we depended heavily on the skills of our QA engineers to help us figure out anything that might not work anymore.

The final step in the migration from Vue 2 to Vue 3 was to put the new version of the app into production. Since we had two versions of our app, one in Vue 2 and one in Vue 3, which looked essentially the same, we decided to do a blue/green deployment. This means that we transferred a subset of the user traffic to the new app while the majority of the users were still using the stable old app. We then tested this in production for a week with only a small subset of our users.

By slowly introducing the new version to just a percentage of the users, we could find more potential issues without disrupting all of our users. The essential part here was to have direct communication with our Sales and Support teams, who are in direct contact with important clients.

Lessons Learnt

Migration to Vue 2

The core lesson when we completely rebuilt Storyblok in Vue 2 was that migrating a large system can be a significant challenge for the development team that consists of new developers who are not familiar with the system yet. By handing the power over to the developers, they could be directly involved in forming the architecture, quality, and direction of the product. In any migration or significant change, the onboarding and training of developers will be an essential part of making the migration successful.

Another big lesson was the involvement of the existing users to improve the quality of the newer version we were building. By slowly introducing the new design and features in different areas of the system, the customers had the opportunity to get used to the new version gradually. With this gradual change, they could give feedback and report any issues or problems they encountered.

Overall, customers have a number of expectations when it comes to software, including:

  • Reliability and stability,
  • Ease of use,
  • Regular updates and improvements,
  • Support and assistance,
  • Security and privacy.

Migrating a large system can impact these expectations, and it's important to carefully consider the potential impacts on customers and take steps to ensure a smooth transition for them.

Migration to Vue 3

As we got more teams and more customers, it kept getting more critical to keep our production version of the app as stable as possible, so testing was an important part of making sure the quality was monitored and bugs were eliminated. All that time we had invested in unit and e2e testing in the Vue 2 version helped us to find problems and bugs during the migration process to Vue 3.

We found that it was essential to test the migrated system extensively to ensure that it was functioning correctly and meeting all of the required specifications. By carefully planning and executing our testing process, we were able to identify and fix the majority of the issues before the migrated system was released to production.

During the Vue 3 migration, we also saw the advantages of having a ‘separate’ part of the system, our design system, that could be migrated first. This allowed us to learn and study the migration guide there first and then move to the more complex migration of the app itself.

Lastly, a big thing we learned was that communication is essential. We started creating internal communication channels on Slack to keep marketing and other teams up to date on all the functionality changes and new features. Certain people could then weigh in on the ways new features were built.

Conclusion

Migrating Storyblok from Vue 1 to Vue 2 to Vue 3 was a significant challenge for the whole organization. A well-formed migration plan should outline the steps to be taken, the areas and functionalities that need to be migrated and in what way (rebuild or create a new version), the people to be involved, and the expected timeline.

For us, some key takeaways were the importance of involving the development team in forming the architecture and direction of the product, as well as onboarding and training them properly. It was also essential to communicate effectively with stakeholders, including users and other teams, to address their concerns and ensure their expectations were met.

Testing plays a crucial role in ensuring the migrated system functions correctly, and the better your QA engineers, the more smoothly the migration will go. Gradually introducing the new version to a subset of users before a full release can help identify any potential issues without disrupting all users. Another approach is gradually introducing new parts of the system one by one. We made use of both of them.

If you’re planning a large system migration, starting with a well-defined plan is important. Make sure to consider budget and time frame, build in time for testing and validation, continuously monitor the progress of the migration and adjust the plan as necessary.

It’s also important to involve existing users in the migration process to gather feedback and identify any potential issues. Make sure your migration is actually improving the experience for the users or developers. Internal communication is key in this process, so ensure that all stakeholders are effectively communicated with throughout the migration to make sure everyone is on board. Consider gradually migrating different parts of the system to help manage complexity or introducing a new system only to a subset of users first.

And lastly, work with your team. Migrating really takes a lot of hands and time, so the better your teams can work together, the smoother the transition will go.