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.

Getting Internationalization (i18n) Right With Remix And Headless CMS

This article is a sponsored by Storyblok

How much of a language barrier is there still in the 21st century? You, as the reader, are probably very familiar with English, but what about others?

Nowadays, most of us have often heard the importance of accessibility, better performance, and better UX or DX. You might not hear or often see about i18n compared with these topics. But if you see facts and numbers from the statistics, you might find some surprising results about i18n and its impact. Let’s find out about that together.

i18n And l10n

Before we go through the impact of i18n, let’s learn the difference between the two terminologies.

  • i18n
    i18n stands for internationalization. Between the first character “i” and the last character “n” from this word, there are 18 characters. i18n describes implementing the structures and features for your applications to be ready to localize content.
  • l10n
    l10n stands for localization. Between the first character “l” and the last character “n” from this word, there are ten characters. l10n means translating content into the languages for users who are accessing from specific regions.

As a follow-up, i18n contains a programmatic process to implement features for content editors and translators to be able to start the l10n process from the UI.

Why Does i18n Matters That Much?

To see the importance of i18n, let’s look at the numbers and statistics for objective information. You will see the numbers of some facts below, and before reading further, let’s guess what those numbers stand for.

  • 5.07 billion
  • 25.9%
  • 74.1%
  • China
  • Asia

The first fact shows a tremendous amount of the numbers. 5.07 billion is the number of users in this world in 2020. The world population in 2021 was 7.837 billion, nearly 8 billion. More than half of the world's population has access to content on the internet and apps.

Based on the number of users in this world, there’s another research about the most common languages used on the internet. Looking at the chart, most of us pay attention to the highest number on this diagram: 25.9%, English.

The second highest is the rest of the languages, 23.1%. Also, suppose you gather the rest of the percentage except English. In that case, you may realize out of the over 5 billion users, 74.1% of the users are accessing the content in any other language.

After going through these facts, we can now talk about why internationalizing and localizing your content for Asia and China, in particular, is crucial. China has the most internet users worldwide. As a result, more than half of all internet users globally are from Asia.

Based on what we saw, probably, we can not ignore localizing content. It will improve UX if these huge amounts of users worldwide could have localized content. After knowing the potential impact of proper i18n, let’s look at the fundamental logic.

How i18n Works At A Basic Level

Regardless of the technology to implement i18n, there are three ways to determine languages and regions.

  1. The location of the IP address
  2. Accept-Language header/Navigator.languages
  3. Identifiers in URLs

Using the IP address detects the region of the users and allows them to access content in their regional languages. However, the users’ IP address does not necessarily match their language preference. Moreover, location analysis prevents the sites from being crawled by search engines.

Using Accept-Language header or Navigator.languages is another possible approach to implement i18n. However, this approach provides language information but not regional information.

i18n is not just about localizing content. It includes improving UX as well. For example, creating identifiers in URLs enhances UX. It also helps to divide localized content into the dedicated system. We will cover how it’s possible to implement such a system in the “A Combination Of Remix And CMS” section.

Typically, identifiers in URLs exist in three different patterns:

  1. Differentiate by domains (i.e. hello.es, hello.jp)
  2. URL parameters (i.e. hello.com?loc=de)
  3. Localized sub-directories (i.e. hello.com/es, hello.com/ja)

To follow the same-origin policy for better SEO, localized sub-directories can be used.

Based on the interesting facts and the fundamental logic for implementing i18n, we’ll talk about frameworks and libraries, as some of them use i18n libraries.

Libraries

In order to not reinvent the wheel whenever we want to implement i18n into our projects, developers have different libraries, tools, and services that can be used to facilitate the work. If we are working with React or React-based frameworks, we have different options available. Let’s talk about some of them.

Format.js

Format.js is a modular collection of JavaScript libraries that we can use to implement i18n logic in both the client and the server. This group of libraries is focused on formatting numbers, dates, and strings. It offers different functionalities and tooling and runs in the browser as well as in the Node.js runtime. It integrates with various frameworks, like Vue and React, so that we can use its functionalities on our Remix projects. You can read more about it on the official React Intl's docs.

i18next

Another alternative that we can evaluate for our project is i18next. This JavaScript library goes beyond the standard i18n features, providing a whole suite to manage i18n in our projects. We can detect users’ language, cache translations, and even install plugins and extensions. As it was built in JavaScript, we can use this tool for websites as well as for mobile and desktop applications.

What About Remix?

When creating a website using Remix, we have different options to consider. As it is a React-based framework, we can use any of the previously mentioned libraries. However, we will go through two approaches that can fit better in your Remix projects. First, we will see how to localize content using remix-i18next, a Remix specific library for i18n. Second, we will use a headless content management system as the source of our content’s different languages/locales.

remix-i18next

Based on i18next, Sergio Xalambrí, one of the main Remix contributors, created remix-i18next. This library offers similar features and modules as the JavaScript library but focusing on Remix concepts and approaches. Easy to set up and use, production-ready, and without any requirement or dependency. Let’s have a closer look at how to implement i18n into our Remix projects using remix-i18next.

First of all, we need to install some npm packages:

npm install remix-i18next i18next react-i18next i18next-browser-languagedetector i18next-http-backend i18next-fs-backend

All of them will help us to manage i18n on both the server and the client side of our website. We will also use them to set up our backend and define the logic that will detect the language from the user.

Now, we should add some configuration that will be used across the website from both the client and the server side. Let’s create a couple of JSON files with the translations of the different character strings that we’ll use on our website:

{
  "intro": "Hello everyone!"
}
{
  "intro": "Hola a todos!"
}

By naming the files “common.json”, we’re defining the namespace for the strings that we’ll list in them.

Now, let’s create a file called i18n.js. This file contains different configuration settings that we’ll use at the moment of initializing our i18n server.

export default {
  supportedLngs: ["en", "es"],
  fallbackLng: "en",
  defaultNS: "common",
  // Disabling suspense is recommended
  react: { useSuspense: false },
};

You can see more configuration options in the official i18next docs.

Now, create the file i18next.server.js, which contains logic that will be used in the entry.server.jsx file of our Remix project.

import Backend from "i18next-fs-backend";
    import { resolve } from "node:path";
    import { RemixI18Next } from "remix-i18next";
    import i18n from "~/i18n"; // The configuration file we created

    let i18next = new RemixI18Next({
      detection: {
        supportedLanguages: i18n.supportedLngs,
        fallbackLanguage: i18n.fallbackLng,
      },
      i18next: {
        ...i18n,
        backend: {
          loadPath: resolve('./public/locales/{{lng}}/{{ns}}.json'),
        },
      },
      backend: Backend,
    });

    export default i18next;
We’re basically initializing a new i18n server that will run with our Remix backend. We’re specifying the location of the JSON files containing the translations to be used. Let’s add these features to our main Remix config files. First, we add some logic to be able to translate content client side. To do that, let’s edit our entry.client.jsx file:
import i18next from "i18next";
import LanguageDetector from "i18next-browser-languagedetector";
import Backend from "i18next-http-backend";
import { I18nextProvider, initReactI18next } from "react-i18next";
import { getInitialNamespaces } from "remix-i18next";
import i18n from "./i18n"; // The configuration file we created

i18next
  .use(initReactI18next)
  .use(LanguageDetector)
  .use(Backend)
  .init({
    ...i18n, // The same config we created for the server
    ns: getInitialNamespaces(),
    backend: {
      loadPath: "/locales/{{lng}}/{{ns}}.json",
    },
    detection: {
      order: ["htmlTag"],
      caches: [],
    },
  })
  .then(() => {
    // After i18next init, hydrate the app
    hydrateRoot(
      document,
      // Wrap RemixBrowser in I18nextProvider
      <I18nextProvider i18n={i18next}>
        <RemixBrowser />
      </I18nextProvider>
    );
  });

We need to wait to ensure translations are loaded before the hydration in order to keep our web app interactive.

Let’s add the logic to the entry.server.jsx file now:

import { createInstance } from "i18next";
import Backend from "i18next-fs-backend";
import { resolve } from "node:path";
import { I18nextProvider, initReactI18next } from "react-i18next";
import i18next from "./i18next.server"; // The backend file we created
import i18n from "./i18n"; // The configuration file we created

...

export default async function handleRequest(
...
) {
  // We create a new instance of i18next
  let instance = createInstance();

  // We can detect the specific locale from each request
  let lng = await i18next.getLocale(request);
  // The namespaces the routes about to render wants to use
  let ns = i18next.getRouteNamespaces(remixContext);

  await instance
    .use(initReactI18next)
    .use(Backend)
    .init({
      ...i18n,// The config we created
      lng, // The locale we detected from the request
      ns,
      backend: {
        loadPath: resolve("./public/locales/{{lng}}/{{ns}}.json"),
      },
    });

  return new Promise((resolve, reject) => {
    ...

    let { pipe, abort } = renderToPipeableStream(
      
        {" "}
      ,
      ...
    );
    ...
  });
}

Identifying users’ preferred language will allow us, among other things, to redirect them to certain routes.

Now we can start using the functionalities provided by remix-i18next to detect the user’s locale and deliver translated content based on that. Let’s edit the root.jsx file:

...

import { json } from "@remix-run/node";
import { useChangeLanguage } from "remix-i18next";
import { useTranslation } from "react-i18next";
import i18next from "~/i18next.server";

...

export let loader = async ({ request }) => {
  let locale = await i18next.getLocale(request);
  return json({ locale });
};

export let handle = {
  i18n: "common",
};

export default function App() {
  // Get the locale from the loader
  let { locale } = useLoaderData();
  let { i18n } = useTranslation();

  useChangeLanguage(locale);

  return (
    <html lang={locale} dir={i18n.dir()}>
      ...
    </html>
  );
}

The useChangeLanguage hook will change the language of the instance to the locale detected by the loader. Whenever we do something to change the language this locale will change, and i18next will load the correct translations.

Now, we are able to translate content in any route:

import { useTranslation } from "react-i18next";

export default function MyPage() {
  let { t } = useTranslation();
  return <h1>{t("intro")}</h1>;
}

We use the t() function to show translated strings based on the list of messages that we defined in our JSON files.

In this example, we use one default namespace, but we can set up multiple namespaces if we want. You can read more about the t() function in the official i18next docs.

In case we want to translate content server side, we can use the getFixedT method inside our loaders and actions:

import i18next from "~/i18next.server";

...

export let loader = async ({ request }) => {
  let t = await i18next.getFixedT(request);
  let title = t("intro");
  return json({ title });
};
A Combination Of Remix And CMS

Together, we explored the available options to implement i18n with Remix. At the beginning of this article, we learned that i18n could result in hugely improved UX and SEOUX, and SEO. As part of UX, it’s also important to include better DX.

The approach above creates translation files at the source code level. Also, we don’t have the logic to implement identifiers in URLs. To achieve this, let’s look at the approach of integrating a CMS. In this article, we’ll use Storyblok, which offers three different approaches to localizing content and handles to determine the languages and regions.

Note: If you want to create the connection between your Remix app and Storyblok, there’s a 5-minute tutorial that explains just how to do that.

After that, you can quickly clone a starter space by using this magic link to have all the necessary components and field types. This example space covers an approach called folder-level translation. We’ll cover what it is about in the next section. https://app.storyblok.com/#!/build/181387

Choose Between Three Approaches

Storyblok has three ways to create the layout to store localized content and determine languages and regions.

  1. Folder-level translation: Divide localized content in folder-level.
  2. Field-level translation: Translate in field-type level.
  3. Space-level translation: Dedicate spaces (environments or repositories) into certain localized content.

To cover identifiers in URLs, folder-level translation works perfectly, as each folder will only contain relevant localized content.

Also, identifiers can be modified from the folder settings via the slug.

By modifying the slug from the folder settings screen, this localized identifier in the URL appears in all stories inside this Japanese folder. For example, the about page inside of the Japanese folder already has a localized identifier in the URL.

To programmatically generate content pages, Remix has a feature called Splats, catching all slugs regardless of the nested levels. Naming a file $.jsx will enable the catch-all slug fundamental function.

app
├── root.jsx
└── routes
    ├── files
    │   └── $.jsx
    └── files.jsx

The difference between dynamic segments from Remix is that splats still match at the next /. Therefore, splats will capture everything in the path. If the URL path is hello.com/ja/about/something, the splat route has a special param to capture the trailing segments of the URL.

export async function loader({ params }) {
  params["*"]; // "ja/about/something"
}

Using the splat route’s special param, let’s edit $.jsx file.

export default function Page() {
 // useLoaderData returns JSON parsed data from loader func
 let story = useLoaderData();
 story = useStoryblokState(story, {
   resolveRelations: ["featured-posts.posts", "selected-posts.posts"]
 });
 return <StoryblokComponent blok={story.content} />
};
// loader is Backend API & Wired up through useLoaderData
export const loader = async ({ params, preview = false }) => {
 let slug = params["*"] ?? "home";
 slug = slug.endsWith("/") ? slug.slice(0, -1) : slug;
 let sbParams = {
   version: "draft",
   resolve_relations: ["featured-posts.posts", "selected-posts.posts"],
 };
 // …
 let { data } = await getStoryblokApi().get(cdn/stories/${slug},
 sbParams);
 return json(data?.story, preview);
};

HINT: In the section “Choose between 3 approaches”, we didn’t cover all three approaches, but if you’d like to know more, all approaches are documented below.

Summary

We learned together the facts and statistics to know the impacts and the importance of i18n and saw how Remix handles several options to implement advanced i18n. Interestingly, a better i18n experience provides better SEO and UX. Hopefully, this article provided you with new knowledge and insightful learnings.

Video version of this article https://portal.gitnation.org/contents/lets-remix-to-localize-content-1072
Remix docs https://remix.run/docs/en/v1
remix-i18next https://github.com/sergiodxa/remix-i18next
Storyblok docs https://www.storyblok.com/docs/guide/introduction

Five Steps To Design Your Product With Powerful Storytelling

I can’t imagine the digital world without the magic of storytelling. While I consider storytelling as an art, it is also a discipline that has its roots in Ancient Greece and Aristotle’s writing: Poetics:

“A whole [story] is what has a beginning and middle and end.”

In this essay, the Greek philosopher identified for the first time the three main components of a story: beginning, middle, and end, and how they each related to one another.

“A beginning is that which is not itself necessarily after anything else, and which has naturally something else after it. An end is that which is naturally after something itself, either as its necessary or usual consequent and with nothing else after it. And a middle, that which is by nature after one thing and also has another after it.”

Aristotle’s three-act structure has remained unchanged since 300 BC. Although many writers, screenwriters, and film directors have conducted a variety of complex experiments, the most successful stories never stray from this basic root.

Today, designers use the same structure to map user experiences and design user-centered products. A remarkable and memorable example of the power of storytelling is the change in Apple’s direction of communication on Steve Jobs’ return. He had spent some time running Pixar, and his experience with the company’s storytellers was essential to what happened next at Apple: the belief that by focusing on customers’ needs and tapping into their stories, they would sell more computers. (They did, of course!)

However, designers cannot become good storytellers by using Aristotle’s three-act structure alone. We must also identify specific storytelling elements to help develop our narrative.

In the following five steps, we will tap into each of the different elements of storytelling, with a running example of the approach I used to design the experience and interface behind the video course landing page.

Meet Smart Interface Design Patterns, our new video course on interface design & UX. Step 1: Understand Your Protagonist And The Purpose Of The Product

As designers of experiences, we need to build beautiful interfaces that create meaningful interactions with our audience. So before imagining the layout of the landing page, I needed to find an answer to a critical question: who is our protagonist?

The protagonist is the hero of our story. The story, therefore, is never about the product we sell. It is always about the protagonist, who reflects the audience’s own interaction with that product.

So to answer the first question, we need to know our protagonist’s needs, goals, fears, and frustrations. This is the rule number one for every UX designer, just as it is for any storyteller.

When you need insights about your protagonist, you can use a set of questions to conjure a most likely persona. If the product already exists in the market, you can use other research tools, like usability testing or heat maps. In my case, Vitaly Friedman, the creator of the video course, had already identified his target ahead of time, during the workshops and conferences he had completed in the past year.

Watching the video chapters of the course, I understood that our story’s protagonists would be UX and UI designers with a beginner to advanced level of knowledge about design and interface design patterns.

The frustration of these protagonists is usually the lack of time to research and learn. Specifically, those who are trying to fully embrace the world of UX design wish to learn design patterns quickly, so they can figure out the reasons why one might offer a better experience than another. On the other hand, a more experienced target group doesn’t have time to stay updated with the latest UX best practices between projects.

Our protagonists’ needs and story, therefore, define our story’s purpose: Why does this story matter to them?

Defining the why of the story is always a challenging step of storytelling. It only becomes easy once you know your protagonist well. The audience will only stick around if the story resonates with them. Additionally, a story without a clear purpose is hazy and irrelevant, so the story’s intention must be defined upfront.

Re-articulating Simon Sinek’s Golden Circle, a stickable story needs to know the purpose of its existence, i.e. the audience problem it is trying to solve (why), what sets it apart from others (how), and at the end, the product and service it is selling to solve the problem (what).

This is what the Golden Circle looks like when applied to the experience design for the landing page:

  • The why of our story tapped into our protagonists’ frustrations about the lack of time. So our story is first about communicating that learning is an investment. Secondly, through Vitaly’s own experience and research, they will save time and effort.
  • The how reflects on their learning goals and staying up to date: if they are hungry for knowledge, they will be satisfied.
  • The what is a reflection on the WHY and HOW. We want people to subscribe to the video course only after evaluating its benefits and tasting the material (adding some valuable features during navigation with free samples, previews, extra gifts, and persuasive elements, like testimonials).

The protagonist and the purpose are the elements that propel us to the next step of our narrative: the plot.

Step 2: Define The Structure Of Your Narrative

Aristotle teaches us that stories must be a chain of cause-and-effect moments. Each scene must lead to what happens next and not work as a standalone episode, no matter how attractive and well-executed it is. Remember, the plot must also have a beginning, middle, and end.

In his book, Building a Story Brand, Donald Miller examines the cause-and-effect structure as follows: a protagonist aims for something, but in her quest, she encounters a problem. During her journey, a guide steps into her life and shows her a plan that invites her to action. By acting, the protagonist will avoid failure and end her story in a success. He calls this structure the StoryBrand Structure.

For every project, whether a digital product or brand design, I combine Miller’s StoryBrand format with Aristotle’s three-act structure to convey a clear sense of continuity throughout the narrative.

Then I work on each act individually, analyzing every element of the narrative.

The Beginning

The beginning, also known as the first act, is the setup.

In UX design, this is the moment where we meet our protagonist (the hero) with her problems and goals, as analyzed in the previous step.

At the end of Act I, our protagonist meets a guide. The guide is not another hero. They simply act as a helping hand, showing the protagonist how to move forward in her transformational journey. You could use the plot of your favorite movie as an example of how this occurs.

Here’s an example from my own favorite childhood movie, The Neverending Story. The child-protagonist, Bastian, is neglected by his father and bullied at school (problem). Trying to escape the bullies, Bastian enters a bookstore, annoying the bookseller (the guide) who is reading an interesting book that is not for children. Secretly, Bastian takes the book, titled The Neverending Story, and reads it in the school’s attic.

The book describes the fantasy world of Fantasia, which is slowly being devoured by a malevolent force called “The Nothing”. The Childlike Empress, who rules Fantasia, has fallen ill, and the young warrior Atreyu is tasked to discover a cure, believing that once the Empress is well, The Nothing will no longer be a threat.

Bastian soon understands that the book he is reading will save Fantasia from disappearing (the plan), and he needs to give a new name to the princess (Action) to help Atreyu win his battle against The Nothing (avoid failure). Then, he will save the Childlike Empress and her Empire (success).

So, when identifying the guide of your story, whether a person, a service, a product, or a brand, ensure it is someone the audience will trust and follow because they feel understood and in safe hands. The guide’s inner qualities are empathy and authority, which should be reflected in every communication material they share with their audience.

In the landing page example, our story’s guide is Vitaly Friedman. Investigating his profile, I established a past of remarkable work sharing resources and best practices in Smashing Magazine and many conferences, workshops, and online. On social media, Vitaly has built a strong reputation in his community as a UX expert and extremely knowledgeable in this field. He, therefore, possesses all the traits of a guide.

The Middle

The middle, also known as the second act, is the confrontation. In this specific part of the story, we assist the transformation of the protagonist and her emotional state (this transformation is also known as the character arc).

At the beginning of the second act, the guide gives the protagonist a plan. The question the protagonist expects the guide to answer is, “What do you want me to do now?”

In the middle of The Neverending Story, we discover that Bastian needs to follow a precise plan: he needs to give a new name to the Childlike Empress to prevent the dissolving of Fantasia.

So the plan needs to be clear, highlighting every step and removing any sense of risk or doubt that our protagonist may have in considering it. By giving your users a plan, you set a clear path to help them move forward in their journey.

In the case of the landing page, I asked Vitaly to list the content of his offer and explain the simple steps that must be taken to subscribe to the available plans. I then underlined the unique values and the plan for each subscription and designed a simple overview.

At the end of the second act, the guide must clearly communicate what action the protagonist needs to perform with the plan.

In The Neverending Story, the protagonist Bastian is in complete disbelief that he is part of the solution, and moved by the Empress begging, he calls out the new name, running to the attic window to call out “Moon Child”.

In the same way, when we sell a service or a product, we need to invite the users to take a journey with us, just as we have via the landing page. If we plainly tell them, they will know what to do with our well-laid plan.

Vitaly invites the audience to act in two ways. One is a direct call to action through a "Buy"-button that is positioned on different parts of the landing page. The other is a transitional call to action through free video episodes, email newsletter and content samples.

Transitional actions also come in other forms:

  • testimonials from other experts in the field, and
  • unlimited access to the UX checklists, an elegant deck of 165 cards to learn and recall basic design patterns for successful digital experiences.

The End

The ending is the story’s third and final act.

It is here that we will decide how our protagonist will succeed in her goal or avoid failing. In doing so, we need to achieve the peak of our story or climax by specifying what’s at stake if the user (or the protagonist) doesn’t engage with us.

It is essential to find the right balance in how we introduce negative consequences, so we can avoid generating fear that will parallyze and freeze the protagonist from moving forwards in her journey.

In The Neverending Story, when the Childlike Empress begs Bastian, she tells him that Fantasia will disappear without his help, and so will his favorite hero, Atreyu, and his dragon Falkor. She taps into Bastian’s wishes of belonging to something bigger than himself, thereby proving that he is worthy. This a desire we sense the protagonist seems to aspire to since the beginning of the movie when he seeks his father’s attention or tries to escape his bullies.

For the video course, we remind the user that she can only become an expert after a while and that it would probably take many years of research and reading and studying to become good at UX. So why not build the knowledge on top of well-explained, curated foundation and jump into a course with Vitaly, who has “cooked” the best recipes and bulletproof design patterns over 15 years?

We should remember that our story’s goal is to motivate our users to become better versions of themselves, and that they need only start this journey with us to achieve such an incredible transformation!

For this particular reason, the third act is also called the resolution. When designing a user journey, we also define a list of resolutions to the protagonist’s problem. In designing the user experience for the landing page, the list was created from a mix of status and inspirational resolutions:

  • Self-improvement: Become an influential and more knowledgeable UX designer, and receive a UX certificate.
  • Networking opportunities: Join an advanced UX workshop where you will meet Vitaly, get feedback from him personally and work with other designers around the world.
  • Improve the web: Work confidently towards designing better digital experiences on the web.

These resolutions were presented in different parts of the landing page to remind the user why she is on this journey with us, and where we wish to take her.

Step 3: Connect The Plot With A Wireframe

Now that all of the story elements are in place, it is essential to understand how they will fit together and connect on the landing page. I usually think about each page of the website as a single shot with its beginning, middle, and end scenes. Many of these shots make a scene, and a series of scenes make an entire website or application.

Following the plot I created in the previous step, I started out by organizing the content and adding critical plot points.

Plot points in dramaturgy are incidents that directly impact what happens next in a story. When used well, they help the protagonist move forward in her journey. In UX, the plot points work precisely in the same way. They are actions (for example, “buy now” buttons), barriers (logins or forms to fill), delights (unexpected interactions or free samples), system events (confirmation messages and emails), and triggers (notifications) that the user needs to perform to move forward in their journey.

Using a simple piece of dotted paper, I usually start sketching how my story’s content will ideally be displayed between the different parts of the page. You may wonder about the mobile-first approach at this point. When designing an experience as we are doing right now, what matters is ensuring it is consistent with our story and that it can be replicated on every media, no matter the pixel size or the support used.

So if you wish to start with mobile or a large screen, our aim is to define the user journey in a way that could be transformed into an interface for the landing page (as in our case), in a leaflet, or in a marketing campaign.

Opening Scene

The opening scene sets up the story’s premise and is the first element of the page that the user will see, regardless of which website or application she lands on. The upper area of the page presents the product or service to the audience.

We wanted to induce curiosity in our protagonist in this specific part of the page. For this reason, the content needs to be engaging and compelling, prompting the user to scroll down for more. I would add a trigger that actively invites the user to “scroll down” to the next part of the shot, the middle scene.

Middle Scene

The middle scene of our shot is the place where most of our narrative will happen. We will introduce our protagonist to the guide, the plan, and the action we wish them to perform. There will be a section that explains the video course and the content in full detail, with content samples and other elements that will help users better understand and explore the video course.

To build authority and trust around our experience, we do not simply introduce Vitaly but also a series of testimonials from other experts. Our protagonist is no longer curious but armed with relevant information! She needs a clear reason to engage with our product. For this reason, any action or plot point added should satisfy this specific emotional aim.

Closing Scene

The closing scene is the resolution of our plot.

As previously explained, we offer two plans that evoke two specific outcomes; we are not simply asking which plans our protagonist wants, but what kind of transformation she is aiming for. Here the user is mindful, so we need to ensure nothing distracts her from the decision-making.

So in this specific scene, the “Buy”-button is the one and only action we wish our user to focus on.

The footer and the top navigation are complementary elements of our narrative. The navigation facilitates the journey, while the footer provides more engagement in case our hero needs additional time to decide or wishes to join the larger community that Vitaly is serving.

Step 4: Add Emotional Connection To Create A Memorable Story

The first three steps focused on the user journey and page content. In this step, we think about making the story memorable for our users. Otherwise, our landing page will look like any other random page!

Emotional connection is an essential part of the storytelling process and can be conveyed through visual elements like colors, sounds, illustrations, animations, and images. These play a huge role in motivating and giving intention to the actions taken by the user.

To find the central theme of our landing page, I focused on critical elements and designed a map with keywords to help me create a forced connection, another wonderful aspect of storytelling that is based on combining disparate functions, materials, or processes.

This process is used to generate disruptive ideas and original concepts:

  • Our users’ needs (hungry users): learning fast, getting the best lessons in UX, and hungry for knowledge.
  • The set (kitchen): a friendly and informal kitchen.
  • Vitaly’s role (chef): experienced teacher, UX expert and guide.
  • The tools (recipes): real-time examples, blackboard, notes, video courses, and slides.

These elements all remind me of a well-designed food experience conveniently delivered right to your door: our “knowledge-hungry” users can follow Vitaly’s recipes (the videos) at their own pace. Each recipe has been prepared and cooked by Vitaly, packed with the best nutritional elements (tips, tools, examples. slides, and so on) that create strong and compelling designs.

The color palette is a mix of inspiration from the blackboard that opens each episode of the course, the primary red of the Smashing Magazine theme, and the wonderful video course illustrations by Guillaume Kurkdijan.

I then used the previous wireframe and enriched it with sketches that could complete and clarify the scene. These sketches served as a blueprint for the final illustrations.

Opening Scene

A rich starter to introduce some of the design patterns taught in the course is accordion UX (the spring with fish), reviews and ratings (stars), cookies (the biscuit), hamburger menu (the spaghetti), adding personality to the web (salt and pepper).

The illustration matches the user’s emotional state, curiosity, by surprising her with an unexpected food theme.

Middle Scene

We decided to introduce Vitaly with images showing him involved in teaching, while the course chapters are like cookbooks on the shelf, shown through a carousel.

My favorite illustration is the Buddha Bowl, which is used to introduce all the content provided during the course. This illustration satisfies our protagonist’s need for more information. It is interactive so that from the ravioli to the small bottle of oil, the audience can explore the nutritional elements that make this course so unique and flavourful!

End Scene

Three small illustrations introduce the available plans that tap into the resolutions we mention in step 2. The illustrations for each plan are relevant to the plans but presented small to avoid interfering with the focused state of our protagonist.

An empty bowl suggests that our users have now eaten a part of the content, but if they are still hungry, there are more ways to engage with Vitaly.

Additional small illustrations, all food related, introduce the different sections of the landing page and their content. Talented animator, Cassie Evans, brought these illustrations to life with subtle animations so that the entire landing page is playful and appealing.

Step 5: Test Our Narrative Before Engaging With Our Customers

Before presenting an idea to customers, I usually follow a detailed check to ensure that the final design still represents the user’s story, as outlined during the previous steps.

Some of the questions I ask myself are the following:

What Primary Action Do I Want The User To Take On This Page?

The answer references the story element action. I usually check if there are enough plot points, like buttons and triggers, on the page to engage the user at different stages of her journey.

What Secondary Action Do I Want The User To Take?

This answer relates to the transitional actions, which means anything that invites the user to engage with us in other ways before they click the “Buy”-button.

How Am I Supporting The Need To Scroll For More Details?

In this case, my attention switches to the plot and the cause-effect element that define the narrative. Looking at the structure laid out in step 2, I check if the scenes included in the landing page still follow the logic of the user’s journey and if there are enough plot points to carry the narrative.

Does Any Content Distract The User, Or Prevent Her From Completing Her Task?

This question focuses on the clarity of the message and our resolutions. In general, each page should focus on a specific outcome. Anything that blurs our intentions should therefore be removed.

Different parts of the landing page refer to our three resolutions, with the entire page built around them.

Can We Anticipate The Final Action?

The answer to this question usually relies on the user’s ability to jump into the climax of the story quickly, to the action (in our case: available plans with “Buy”-buttons). Think about fast-forwarding your favorite movie to get to the most thrilling scene or leafing to the last page of a book to discover who the killer is!

In the case of a landing page, the “Buy”-button is at the beginning of the navigation and follows the user as she scrolls… so she can jump to the story’s third act at any time she likes.

Conclusion

As we have discovered, storytelling is more than just another business buzzword. Storytelling is an exciting and strategic approach with rules and clear principles that, when used well, can help brands stand out from the crowd with a clear message and a user-centric approach. It’s an essential skill that designers should embrace, no matter their specialization or profile.

As such, the different steps I have illustrated will help you to:

  • Identify your protagonist and build a powerful, purposeful story that speaks to their frustrations and goals.
  • Create a user journey that directly relates to the protagonist’s story.
  • Structure that journey as a wireframe to identify your chosen story content based on the narrative structure.
  • Create an emotional bond with the user by adding meaningful illustrations.
  • Check the story’s narrative with questions that evaluate your use of the wider storytelling process.

Precisely as it occurs in the world’s most acclaimed movies, building a solid narrative structure guides you in creating scenes and chapters that are consistent with the user’s own story.

In this way, you can use the plot of a solid, recognizable, and popular narrative as a base from which to create additional scenes and chapters, and even successive sequels — as a great many movie franchises have achieved with thrilling effects.

In fact, the same plot illustrated in this post for the landing page helped me to create a warm and instantly recognizable design for Vitaly’s upcoming secretive new project. Still, as the narrative voice of The Neverending Story reminds us, “that is another story, and shall be told another time!”

Where everything is coming together: Smart Interface Design Patterns.

You can find the final result now live on Smart Interface Design Patterns, created with incredible contributions by so many talented and hard-working people:

Thank you for your incredible work, everyone! 👏🏼👏🏽👏🏾

Healthcare, Selling Lemons, and the Price of Developer Experience

Every now and then, a one blog post is published and it spurs a reaction or response in others that are, in turn, published as blogs posts, and a theme starts to emerge. That’s what happened this past week and the theme developed around the cost of JavaScript frameworks — a cost that, in this case, reveals just how darn important it is to use JavaScript responsibly.

Eric Bailey: Modern Health, frameworks, performance, and harm

This is where the story begins. Eric goes to a health service provider website to book an appointment and gets… a blank screen.

In addition to a terrifying amount of telemetry, Modern Health’s customer-facing experience is delivered using React and Webpack.

If you are familiar with how the web is built, what happened is pretty obvious: A website that over-relies on JavaScript to power its experience had its logic collide with one or more other errant pieces of logic that it summons. This created a deadlock.

If you do not make digital experiences for a living, what happened is not obvious at all. All you see is a tiny fake loading spinner that never stops.

D’oh. This might be mere nuisance — or even laughable — in some situations, but not when someone’s health is on the line:

A person seeking help in a time of crisis does not care about TypeScript, tree shaking, hot module replacement, A/B tests, burndown charts, NPS, OKRs, KPIs, or other startup jargon. Developer experience does not count for shit if the person using the thing they built can’t actually get what they need.

This is the big smack of reality. What happens when our tooling and reporting — the very things that are supposed to make our work more effective — get in the way of the user experience? These are tools that provide insights that can help us anticipate a user’s needs, especially in a time of need.

I realize that pointing the finger at JavaScript frameworks is already divisive. But this goes beyond whether you use React or framework d’jour. It’s about business priorities and developer experience conflicting with user experiences.

Alex Russell: The Market for Lemons

Partisans for slow, complex frameworks have successfully marketed lemons as the hot new thing, despite the pervasive failures in their wake, crowding out higher-quality options in the process.

These technologies were initially pitched on the back of “better user experiences”, but have utterly failed to deliver on that promise outside of the high-management-maturity organisations in which they were born. Transplanted into the wider web, these new stacks have proven to be expensive duds.

There’s the rub. Alex ain’t mincing words, but notice that the onus is on the way frameworks haved been marketed to developers than developers themselves. The sales pitch?

Once the lemon sellers embed the data-light idea that improved “Developer Experience” (“DX”) leads to better user outcomes, improving “DX” became and end unto itself, and many who knew better felt forced to play along. The long lead times in falsifying trickle-down UX was a feature, not a bug; they don’t need you to succeed, only to keep buying.

As marketing goes, the “DX” bait-and-switch is brilliant, but the tech isn’t delivering for anyone but developers.

Tough to stomach, right? No one wants to be duped, and it’s tough to admit a sunken cost when there is one. It gets downright personal if you’ve invested time in a specific piece of tech and effort integrating it into your stack. Development workflows are hard and settling into one is sorta like settling into a house you plan on living in a little while. But you’d want to know if your house was built on what Alex calls a “sandy foundation”.

I’d just like to pause here a moment to say I have no skin in this debate. As a web generalist, I tend to adopt new tools early for familiarity then drop them fast, relegating them to my toolshed until I find a good use for them. In other words, my knowledge is wide but not very deep in one area or thing. HTML, CSS, and JavaScript is my go-to cocktail, but I do care a great deal about user experience and know when to reach for a tool to solve a particular thing.

And let’s acknowledge that not everyone has a say in the matter. Many of us work on managed teams that are prescribed the tools we use. Alex says as much, which I think is important to call out because it’s clear this isn’t meant to be personal. It’s a statement on our priorities and making sure they along to user expectations.

Let’s alow Chris to steer us back to the story…

Chris Coyier: End-To-End Tests with Content Blockers?

So, maybe your app is built on React and it doesn’t matter why it’s that way. There’s still work to do to ensure the app is reliable and accessible.

Just blocking a file shouldn’t totally wreck a website, but it often does! In JavaScript, that may be because the developers have written first-party JavaScript (which I’ll generally allow) that depends on third-party JavaScript (which I’ll generally block).

[…]

If I block resources from tracking-website.com, now my first-party JavaScript is going to throw an error. JavaScript isn’t chill. If an error is thrown, it doesn’t execute more JavaScript further down in the file. If further down in that file is transitionToOnboarding();— that ain’t gonna work.

Maybe it’s worth revisiting your workflow and tweaking it to account to identify more points of failure.

So here’s an idea: Run your end-to-end tests in browsers that have popular content blockers with default configs installed. 

Doing so may uncover problems like this that stop your customers, and indeed people in need, from being stopped in their tracks.

Good idea! Hey, anything that helps paint a more realistic picture of how the app is used. That sort of clarity could happen a lot earlier in the process, perhaps before settling on development decisions. Know your users. Why are they using the app? How do they browse the web? Where are they phsically located? What problems could get in their way? Chris has a great talk on that, too.


Healthcare, Selling Lemons, and the Price of Developer Experience originally published on CSS-Tricks, which is part of the DigitalOcean family. You should get the newsletter.

Product Reviews And Ratings UX: A Designer’s Guide

When we make purchasing decisions, we often rely on expertise from people like us who happen to have purchased that item already. And so we seek user reviews, often looking for a high enough average score, a good number of these reviews, and a good number of ratings.

In fact, 95% of users rely on reviews to make their decisions and learn more about how well a product fits their needs. Unfortunately, too often, the way we design reviews and ratings UX confuses and frustrates users, rather than helps them. Let’s fix that.

This article is part of our ongoing series on design patterns. It’s also a part of the video library on Smart Interface Design Patterns 🍣 and is available in the live UX training as well.

What Customers Search In Reviews

We often assume that the only thing that a best-selling product needs is a high number of positive reviews. Positive reviews indeed are needed to build up trust, but just as many users need to be convinced that a product would work for them. This shows up in a few attributes that customers seek to verify in reviews:

  • The product is indeed of high quality as advertised,
  • They aren’t overpaying: the pricing is fair and acceptable,
  • They’ve chosen the right product that addresses their needs well,
  • People like them (similar age group, experience, needs) were satisfied with the product,
  • They haven’t missed any critical details (accessories not included, different sizing),
  • The risk is low and manageable (simple return policy, cancellation process, 30-days-money-back-guarantee),
  • The worst thing that could happen to them due to purchase (poor customer service that’s hard to reach, fraudulent activities that have been flagged).

All these fine little details are quite difficult to decipher from a standalone, beautiful 5-star rating on a landing page. So how can we communicate with them to remove doubts and concerns? Well, we can start off with negative reviews, which often can be way more helpful than not.

Reward Negative Reviews

We shouldn’t be surprised by the fact that most customers, when shopping online, meticulously study negative reviews first, and they need enough of those to tackle the concerns and skepticism most customers almost instinctively come with. The more specific negative reviews are, the easier customers can connect the dots and reach that threshold of trust. Especially if all negative reviews simply don’t apply to them.

Most negative reviews focus on specific things that went wrong during the purchase. For most decent products and most decent brands, that isn’t going to be a particularly long list. It might be that the customer service reaches its busyness spikes every now and again, or that promised delivery times weren’t achieved during holidays, or that there is a high severity bug in the application that’s being solved that week. These things, however, wouldn’t be relevant throughout the entire year (hopefully!).

However, it might be that a product is incredibly faulty, confusing, malicious, or intricately complex — and that the cancellation process is designed to keep as many paying customers as possible. Users will watch out for any red flags that might indicate just that. And the lack of negative reviews altogether is one of those red flags, as it might be hiding some critical underlying issues.

Not every negative review is negative, though. It’s worth repeating that customers tend to seek customer feedback from people like themselves on issues that are relevant to them. If negative reviews mostly focus on poor packaging for shipping overseas or low brightness outdoors, it might be less of an issue for a customer ordering in the same country with the intent to use a device at home. These issues are definitely less critical than any notion of “extremely buggy,” “horrible customer support,” “major refund troubles,” or “severe cancellation issues.”

Chances are high that you will need some negative reviews to appear trustworthy; they will, in fact, increase conversion rates and boost customers’ confidence. That’s why you should consider encouraging customers to write honest negative reviews and ask them to be very specific about the parts of the experience they didn’t like. Also, prompt them to explain if the issue has been successfully resolved in the end. To do that, you could reward users with bonus points or coupon codes that they could redeem with their next billing cycle or with their next purchase.

Always Show Decimal Ratings And Number Of Ratings

Another detail that customers often rely on is a precise estimation of the experience that similar customers have had. In that regard, many websites don’t go far enough, though. Frequently we can spot bright orange stars used as indicators of how great or poor the experience has been, but there are vast differences and nuances between “4 stars”- and “5 stars”-experiences, yet they are somehow getting lost between two aggressively rounded scores.

The problem is that stars alone don’t provide enough context, nor do they provide a detailed enough explanation. With this pattern,

  • we can’t easily tell what exactly customers liked or disliked;
  • we can’t tell how satisfied users with a profile similar to ours are;
  • we can’t say what’s particularly good or particularly bad about the product;
  • it’s impossible to distinguish between products with a rating closer to 4.0 and a rating closer to 5.0. The difference between them, however, is vast.

In order for us to provide a slightly better assessment, our rating scores could be a bit more precise. As a general rule, it’s always a good idea to display a decimal average score (e.g., 4.7 out of 5) and the total number of reviews (78 reviews) together. The average decimal score provides a more granular estimate, while the total number of reviews guarantees a high enough number of reviewers contributing to that score.

Bite prominently highlights the total number of reviews, but it doesn’t reveal an average score. However, once a product reaches 19,348 reviews (overwhelmingly positive), displaying an average score might not be as necessary.

In fact, the number of reviews matters significantly. In usability testing, customers “often show greater preference towards some products with 4.5-star averages than some with perfect 5-star ratings due to the number of reviews that these averages are based on”. In fact, 70% of customers would pick the one with the higher number of ratings despite its lower average.

For example, for two otherwise identical products, where one product has a product ranking of 4.5 with 180 reviews and another has 4.8 with 39 reviews, a majority of customers are likely to choose the first one, despite a lower average. That’s also why it’s critical to mix the number of ratings and average score to avoid the bias towards products with a better ranking but lower number of reviews.

Is there a perfect score, by the way? Well, as long as your product’s score is somewhere between 4.5 and 4.89 — with a high enough (75+) number of reviews, you probably shouldn’t be worrying too much about its competitiveness. When a rating score hits anywhere beyond 4.9, customers start getting suspicious; that’s when they slow down and search for traps and flaws that aren’t explicitly stated. Unsurprisingly it doesn’t help in closing sales.

Why is that? Because in real life, anything sincere with a score above 4.9 is very hard to come by and hence less likely to be true — unless it’s based on a very small sample of biased and dishonest reviews. Don’t feel tempted or pressured to hit that average user rating, though, as it’s not the only detail that customers pay attention to.

Display A Full Rating Distribution Summary

In addition to bright yellow stars, over the years, we’ve learned to rely on distribution summaries for ratings. They explain the relation between high-score reviews vs. low-score reviews and give customers a more granular overview of how good the product is on average for most people. There, we can tell quicker if most customers had an overwhelmingly positive or negative experience.

We do so by looking for specific patterns in the rating distribution summary. As users, we quickly eliminate options with a disproportionate number of low-score reviews. We quickly eliminate options with a disproportionate number of mid-score reviews. And we abandon options without any low-score reviews.

We almost instinctively search for the pattern — the one perfect, trustworthy distribution that is representative of good products. In it, we need to find a lot of positive reviews and enough negative reviews.

Typically this means that a vast majority of ratings will be 5-star-reviews, followed by plenty of 4-star reviews, and eventually followed by a large enough (but not too large!) number of low-score reviews. Most importantly, there must be enough negative reviews to give customers pointers about the most negative experience they might have. Usually, products that match that perfect pattern appear most trustworthy and perform best.

In user research, this “perfect” pattern is called the J-shaped distribution pattern. However, as it turns out, it’s not really that perfect and conceals some troubles for businesses.

The J-Shaped Distribution Issues

You might be wondering why that particular rating distribution has such an unusual name. The distribution resembles a capital letter “J”, with a small spike of the most negative reviews (★), a flat middle ground (★★, ★★★), and a high spike of the most positive ones (★★★★★). It is very different from the omnipresent, classic bell curve that we might have expected initially.

In the examples for IMDB scores of “Game of Thrones” and “Avatar: The Way of Water,” you’ll notice that the distribution in the top scores is much clearer for “Game of Thrones” and much less conclusive for “Avatar: The Way of Water.” Despite a stronger negative scoring in the lower ratings, the distribution of “Game of Thrones” is likely to perform much better — both in movies and for any other products.

We can also notice that in both cases, the lowest score (Rating 1) gets a disproportionate amount of attention. That’s the “J”-shaped distribution in action. Why does it happen?

As Sav Sidorov and Nikita Sharaev explain, user feedback is often skewed towards the extremes. Customers who are just satisfied may not take the time to leave a review or rating, but those who are either extremely happy or extremely frustrated are more likely to do so. This makes rating scores very vulnerable to the strongest opinions of the extremes and hence biased and inaccurate.

An alternative design that Sav has suggested includes four options: , , ↑↑, and ↓↓. When providing a review, customers could click or tap multiple times to provide a stronger assessment. This might eliminate the large spread between the extremes.

Another option is to introduce a delay for reviews. As Marianna Alshina noticed, Etsy doesn’t allow its customers to review products straight away. They have to wait for one week to have a “full” experience with the product, and only then leave pictures and their review.

Will it work? Maybe.

Either way, the distribution needs context that explains it. And that’s where breaking the rating distribution summary by product attributes can help.

Break Rating Distribution Summary By Product Attributes

Showing a distribution summary provides a better overview to customers, but it still requires quite a bit of effort to discover how well-performing a specific product attribute is. For example, a customer might be interested in how long the battery life is or how sophisticated a particular feature is. To learn both, they’ll need to sip through dozens or even hundreds of reviews, often without any success.

A useful approach to help out customers there is to break down the distribution summary even further. For each standalone product attribute — appearance, value for money, product quality, battery life, etc. — we could gather and highlight average scores, based on user reviews. When a customer chooses to provide their feedback, we could ask them to evaluate specific qualities of the product and then calculate a separate average score for each attribute.

On Flipkart (pictured above), customers are encouraged to provide feedback broken down into groups of attributes that are very specific for the product. The “Value for Money” is a classic one that is being used across all products. The color coding is used to indicate “good” and “bad” reviews, but a slightly different color scheme would be more accessible. Also, unfortunately, customers can’t filter reviews by a particular score.

On Adidas and LL Bean, customers can explore specific qualities of a product in a bit more detail. It can be a position on a scale or yet another distribution summary. Both patterns make it clear to customers how well a product performs in relation to that one specific attribute.

Enhance User Reviews With Suggested Tags

The quality of the experience can’t be measured by product attributes alone. A skillfully designed and manufactured product might not be a good fit for some customers, and learning it from a product description spec is impossible. To help there, we could suggest relevant tags when customers write a review. Typically, it could be something along the lines of “great fit,” “great for kids,” “easy to use,” “love the design,” “beautiful packaging,” etc.

These tags could also be slightly more personal and individual; they could relate to the product but also to the customers who have already purchased that product. The goal here is to gather and surface insights and personal details that would make it easier for prospective customers to relate to published reviews. In other words, we try to help prospective customers find similarities with already existing customers and explore their reviews in that light.

Personal details could be anything from the frequency of use and level of experience to age range and current location. But it would differ depending on the product, of course. For skin products, for example, we could ask about the preferred look, skin type, shade, glow, scent, characteristics of the face, but also texture and typical type of makeup. That’s exactly what Glossier and Sephora do.

These tags, then, could be displayed as additional rating filters — and hence help customers find relevant reviews faster, and perhaps even scores for important attributes, based on feedback from customers like them. And that’s much more valuable than any general feedback based on averages could be.

Highlight Social Proof From Reviews

In addition to suggested tags, one of the questions we could ask existing customers at the very end of the review is if they’d recommend this product to their friends, colleagues, or total strangers. As a result, we could calculate a quite significant number that’s often neglected but can be quite a game-changer: the recommendation score.

Asos (pictured above) highlights that “86% of customers recommend this product.” This is quite different from 5-star ratings or 1-star ratings because even customers who aren’t quite happy with the product and would perhaps give it a 3-star rating might still recommend it to their friends. It might not be a perfect fit for them, but they are quite satisfied with its quality.

Highlighting prominently how many customers actually recommend the product is definitely a good idea. A magical number to stay above is 90% recommendation score; yet again, if you climb over 95%, it’s getting a bit suspicious.

To make it even stronger, you could specify the group of customers that actually has recommended the product and allow customers to choose the group that would fit them best. There, we could include fine details such as level of experience, frequency of use, type of projects, and others.

A statement such as “86% of customers (5+ years of experience, enterprise-level) recommend this product” would probably perform the strongest for people who fit that particular group.

Provide Quick Summaries Of Pros And Cons

We’ve come quite far already, yet customers still need to filter and explore reviews on their own. We could help them faster grasp the good bits and the bad bits about the products though. To do that, we could highlight the pros and cons of a product, along with quick summaries of positive and negative reviews.

Ideally, these quick summaries would be analyzing user reviews and listing pros and cons as bullet points. This information is precious and often not displayed at the right time. For example, it would be a very impactful add-on for a category listing page, a product page, and a feature comparison page where users land when they try to compare a couple of products side-by-side.

Allow Users To Mark Helpful Reviews

Not every review is helpful. Some reviews appear very generic, others lack important details, and others again focus too much on irrelevant details. To make sure that relevant reviews get surfaced to the top of the reviews list, we could kindly prompt users to mark if they find a review helpful — both for positive and negative reviews.

Marked reviews — a few of each kind — could then be highlighted at the top of the reviews section, along with the number of users who found them helpful. This dramatically boosts trustworthiness and reduces time to relevance, as highlighted reviews have been validated by other customers. This appears authentic and builds trust.

Provide Helpful Sorting Types and Search Autocomplete

We typically allow users to filter reviews by a particular rating score, but what if a customer is interested in specific details within a particular score range? Once a filter has been applied, we can allow users to sort by specific details of reviews. On Bite, for example, users can sort by the date of review, available photos and videos, as well as highest and lowest ratings and most and least helpful reviews. That’s better.

Additionally, customers on Glossier and Wayfair can sort by reviews that include customer photos and search in reviews, and that’s where an autocomplete feature could be particularly helpful as well. Notice how Wayfair (pictured below) not only displays the tags used for products and customer photos but also highlights how often the keywords have been mentioned in reviews. That’s helpful.

Enhance Reviews With Personal Details

For a review to be convincing, it needs to appear trustworthy, be written by an actual person with credentials and a public social presence, or be recommended by a brand or person that carries some weight. This is why testimonials and logos of big brands work well; this is also why video reviews and customer success stories are quite impactful.

If possible, prompt your users to add some personal details to their reviews, such as:

  • full name,
  • location,
  • age (range),
  • current role or job title,
  • link to a social media account (LinkedIn, Twitter, Instagram),
  • a casual personal photo,
  • a casual personal video (less than 30 sec),
  • a photo of the product,
  • the logo of the brand they work for (if applicable).

One of the most effective ways to build authenticity with a review is to display customer photos prominently next to reviews. Because many customers don’t trust marketing illustrations or can’t reliably visualize product specs, they often rely on customers’ (unedited) product photos to get a more realistic preview of what they should be expecting.

Any personal details are very valuable. Hence it’s a good idea to always prompt users to upload personal product photos and more details about themselves and reward such reviews as well.

Wrapping Up

Getting user ratings right requires quite a bit of work. We need to gather and highlight relevant reviews, present distribution charts with the number of ratings and decimal averages, and allow users to use filters, tags, or search to find reviews faster from people who are very much like them.

Users need:

  • The average score presented with decimal numbers;
  • An overall number of ratings;
  • A full distribution chart of ratings;
  • Customer’s unedited product photos;
  • Ratings for individual features (size, fit, support, etc.);
  • The number of reviews for intermediate values (1.0, 2.0, 3.0, 4.0, 5.0);
  • Tags and filters to find relevant reviews;
  • Personal details that will help customers find people like them in the reviews;
  • The date of when the review was written or published;
  • How many people find it helpful;
  • How many customers (%) recommend the product for purchase.

Sounds like a lot of effort — and it actually is. The impact of a proper user rating design can be remarkable and drive your sales efforts much stronger than any other campaign could have. And once it’s done, it can work for you long-term, building up a community of people who trust your brand and recommend it online and offline. Without any doubt, that’s very much worth the effort.

Useful Resources Meet “Smart Interface Design Patterns”

If you are interested in similar insights around UX, take a look at Smart Interface Design Patterns, our shiny 9h-video course with 100s of practical examples from real-life projects. Design patterns and guidelines on everything from mega-dropdowns to complex enterprise tables — with 5 new segments added every year. Just sayin’! Check a free preview.

Meet Smart Interface Design Patterns, our new video course on interface design & UX.

100 design patterns & real-life examples.
9h-video course + live UX training. Free preview.

The Year in Review at WPMU DEV: A Look Back and a Peek Ahead

Is everyone still basking in that holiday glow? Many of us here at WPMU DEV took a wee break over Christmas, but are back in the full swing of things now.

Topping my to-do list was putting this roundup/roadmap post together, to share what we rolled out in 2022, and what you can look forward to from us in 2023. It’s always a thrill to see it all in one place, and I know a lot of you feel the same.

I want to thank my teammates who work hard every day to make our products and services the best they can be, and for being gracious with their time and knowledge.

I also want to thank you – our devoted customers and discerning audience – for sharing your ideas, testing ours, and playing a large role in our current level of success.

So here we go… a summary of our 2022 accomplishments and a reveal of what’s in the pipeline for 2023, with key points and insights from our brilliant Product Managers and Lead Developers.

Keep reading, or jump ahead with these links:

First up, a view from the top from our CEO, James, who continues to keep our ship righted as we steer into both new and familiar territory.

Executive Summary, from CEO James Farmer

“2022 was truly an epic year that I hope was reflected in the new and improved tools, services, and software that we provided for our members.

We hope you found our plugins – the core of who we are – better in every aspect, from their feature sets to their reliability and UX.

Our hosting has also come along in leaps and bounds, including our first genre-busting product release with Quantum… managed, dedicated, VPS-style hosting from $3.60/m in half a dozen global locations (with your own dedicated IP). I’m still a bit surprised it exists.

And bringing it all together has been The Hub, which continues to take giant strides forward and for which 2023 is going to be its biggest year yet (automated reseller, white label support, from the greatest support team on the planet… yes please!)

And that’s where we’re all at now, making sure you have the best possible 2023 using WPMU DEV for your web development, agency, freelancer or personal projects.

Below, we’ve outlined more specifically what we brought to the table in 2022 and what else is in the works for this coming year, so read on to get up to speed.”

Want to hear more from James? Check out this Post Status interview from the Product Founder Series: WordPress in the Long View with James Farmer.

All right, off to explore the individual products and services. Starting with…

Our Powerhouse Plugins

Plugins are what put us on the map, and continue to play a central role at WPMU DEV.

We currently manage 13 pro plugins, along with nine free versions on the WordPress plugin repository.

Let’s take a look at the journey plugins took last year, and what lies ahead for each in 2023.

Smush

The most popular image optimization plugin for WordPress, Smush continues to rule with blazing-fast CDN, super 2x compression, caching, and lazy loading.

Our Head of Products, Mohammad Sharab, will be providing summaries for Smush, Hummingbird, SmartCrawl, Defender, Forminator, and Snapshot.

First up, here’s Mo with the lowdown on Smush:

“In 2022, we focused on improving the user experience of bulk image optimization and giving back to our free users who made Smush the number one image optimization plugin.

Bulk image optimization processes are much faster with the new Parallel optimization improvement, putting Smush on the top of the list of image optimization speeds. We also removed wait times on image optimization, making workflow more efficient with the introduction of Background Optimization features.

Additionally, we unlocked two features to our free users: Lossy Compression, and the 50 images limit. Now free users can benefit from any amount of lossy, compressed images.

In 2023, we have some key items coming up:

  • Improve our Local WebP Compression
  • Revamp Smush UI/UX
  • Introduce CDN Management per site for users who are managing multiple sites (instead of per account)

As always, we’ll keep you informed when new features hit.”

Hummingbird

The ultimate performance suite, Hummingbird monitors, analyzes, and optimizes the performance of all your websites, assuring they run at peak speeds.

From Mo:

“The Hummingbird team is working with two goals in mind: to make it safer, and easier to optimize.

We know that Manual Asset Optimization isn’t easy for all users, and moving the wrong file to the footer or delaying it from loading could affect/break the front page style. That’s why we introduced a new Safe Mode feature for Manual Optimization, so users could optimize their files and test page speed without breaking anything. Then publish those changes to live, once happy with their configuration.

For 2023, the team is working on two new features that will help users improve site speed score with a click of a button. These are: Delay JS, and Critical CSS features.”

SmartCrawl

SEO superstar SmartCrawl provides higher ranking and improved SERPs, with full schema support, crawling and indexing audits, and content analysis.

Once again we have Mo here to recap last year’s advancements and what’s coming next.

“SmartCrawl has been steadily growing and improving every year, and this year is no exception. We continue to strive to make SmartCrawl a plugin that will be synonymous with SEO and WordPress. To do that, we’re making it more powerful, flexible, and accessible to all our users and members.

Our most recent update is an improvement to our in-post Content Analysis. We now support analysis for multiple keywords or key phrases. In the past, we allowed our users to enter multiple key phrases separated by commas but we only did an analysis on the main/first focus keyword.

Now you can add multiple key phrases and do analysis on subsequent secondary key phrases enabling you to optimize your content even further.

Some other updates we tackled last year were:

  • Multilingual Support for Readability Analysis – We now support 7 Languages with our readability analysis
  • Automatic Linking Refactoring – We have made Automatic linking more efficient and have added a few new features
  • Regex and Bulk Imports for Redirection – You can now use Regex for Redirection and bulk Import and Export redirects between sites

On the horizon for 2023 is… Breadcrumbs! You’ll be able to add Breadcrumbs visually, and they will also include schema data. And, there is still so much more we want to do with Content Analysis, so look for those upgrades this year, as well as other great new features and improvements.”

Defender

Seamlessly integrated with WPMU DEV’s powerful WAF, our tough-as-nails security plugin Defender has helped more than 300,000 sites stay secure while assisting with the early detection of malware.

Mo continues with Defender news:

“In 2022, we made several improvements to Defender, including:

  • Allowlist/Blocklist IPs on multiple sites from The Hub
  • Biometric and YubiKey Authentication for 2 Factor authentication
  • Google reCAPTCHA & 2FA integration with BuddyPress and WooCommerce Checkout
  • Enhancing the Malware scanner’s ability to detect security threats and provide CVSS severity score for vulnerabilities

In 2023, we’re planning several improvements in Defender to make it even better. Here’s the shortlist:

  • Safe Quarantine – Quarantine malware-affected files
  • Defender Firewall – Protect your site from Bad IPs flagged by other sites
  • Improving the plugin’s user interface to make it even more user-friendly and intuitive
  • Enhanced ability to detect and block security threats, such as malware and malicious code

With the ever-increasing need for website security, we are committed to improving Defender and making it the best protection possible from security threats on WordPress websites. To that end, upcoming updates will be comprehensive and effective.”

Forminator

There’s no limit to what you can do with interactive forms, polls, and quizzes in Forminator. Create campaigns in minutes with the most flexible, easy-to-use, drag-and-drop form builder for WordPress, and see user engagement soar.

Mo has this to say about Forminator:

“Our first big feature of 2022 was Global Appearance Presets, released in February. This enabled users to easily create presets of form appearance and reuse them for as many forms as desired.

Our next most-voted feature was Partial Submissions, which we introduced last June. This enables you to save your progress when filling up a large form by saving your submission as a draft, and continuing where you left off at any point later.

We implemented Reports in September 2022, in order to better track the performance of your forms, polls, or quizzes. These reports come both in a dashboard form, where you can see stats about a specific form straight in WordPress admin, or you can schedule regular sends of these reports via email.

Also in September, based on many requests received to support more automation services like Zapier, we adjusted our Webhook integration to support multiple automation tools. In addition to Zapier, Integrately, Tray.io, Make, Workato, and more will now support webhooks through Forminator.

Two other highly requested features that improve form usability are Field Grouping, and Group Repeater functionality. We rolled these out in October, making users able to group fields into sets – which can be repeated on the frontend as many times as needed or desired. This can be particularly useful, for example, if you want your site visitors to fill out the form with multiple guests attending an event, where the same set of details from each extra guest is needed.”

Mo continues with a look-see of what’s up and coming in 2023:

“We’re pumped about what it will bring. For starters, we’re pleased to announce that Forminator version 2.0 will be released in Q1 of 2023, with a highly requested feature: PDF Generation.

While we already have an integration with E2PDF, building this into the plugin will bring a lot more usability, and will allow the use of invoices, quotes receipts, and more.”

Snapshot

A final roundup from Mo, this time for Snapshot, our automatic, efficient, off-site storage backup buddy. Select from reliable third-party storage options, get instant email alerts, and implement one-click restores.

“Last year we formed an awesome new team for Snapshot with the goal of improving the backup success rate. We took care of lots of underlying issues in the Snapshot Incremental API and in the Snapshot plugin, which boosted the backup success rate in 2022 from 80% to 90%.

We’ve also fixed issues where backups were running for a long time without any success or timeout error.

And finally, with November’s 4.13 release, Snapshot now consumes even less memory. That means higher backup success rates on third-party servers with lower specs.

Here are some other 2022 improvements we made on Snapshot (in chronological order):

  • Redesigned Snapshot Installer with a new engine that takes lower memory
  • Added HTTP Authentication option for password-protected sites
  • Fixed compatibility issue with Siteground’s Ultrafast PHP (We’ve seen a 50% drop in backups failing at random database tables.)
  • Added ‘OneDrive’ destination
  • Database table exclusion UI
  • Snapshot uses MySQLDUMP (if available) to dump the database

Early in 2023, we have a couple of items lined up:

  • Continue improving backup and restoration success rate
  • Redesign File exclusion UI

Then later in 2023, we’ll be working on AZURE Destination.”

Dashboard

The WPMU DEV Dashboard plugin securely connects your site to your Hub via our API, giving you one-click installation, upgrades, and security updates for all our plugins, directly from your WordPress.com dash.

Lead Developer Joel James is bringing us the intel on Dashboard.

“Dashboard had some nice growth this year. For starters, we added the ability to sign-in with Google.

Next, we added the ability to select the Hub Team after login, as well as Optimizing SQL queries for a noticeable performance improvement.

And finally, we added WP Consent API integration for WPMU DEV Analytics, and Improved UX on the login screen.

Looking ahead, we plan on refactoring the UI this year. Also, we’ll be improving support for third-party plugins and themes updates.”

In Maintenance Mode

Hustle, Branda, Beehive, Shipper, and Integrated Video Tutorials have been in maintenance mode.

While they had no major feature upgrades in 2022, we continued to fine tune and squash bugs on these workhorse plugins.

The Hub & The Hub Client

The Hub and The Hub Client come together as your client portal extraordinaire, entirely customizable with your own branding, navigation, and domain. White label everything WPMU DEV, resell our services, and handle Client Billing and management needs.

The Hub Client allows you to control settings and configure navigation and user access from the WordPress dashboard. It syncs seamlessly with The Hub, our WordPress site management tool that is cPanel on steroids – but more beautiful and bountiful.

Both have exploded this year, with a ton of new features and enhancements.

Leading us through all things Hub-alicious is our Product Manager, Mukul Chawla.

“I won’t be burying the lede here. While we accomplished quite a bit with The Hub this year, our two biggest feature adds were Domains and the Free Hub.

Fulfilling our promise to ‘be your own GoDaddy’, Domain Services were added in Q4 of 2022. Agency members can now buy domains within The Hub from WPMU DEV for themselves, or to resell to their clients (manually for now, automated reselling coming soon). Clients can buy just the domains from their client portal and link them to their existing sites.

The Free Hub was also released in Q4, allowing users on free plans to sign up and experience The Hub. There are some limits on the free version, such as the quantities permitted and some advanced settings, but most of the features allow you to experience the basic functions that paid members enjoy in full.

Global IP Banning was added, providing members with a global IP allow/block list that they can easily sync with all their websites from The Hub Sites page.

Members also got their first look at our Automated Reseller in the form of a video prototype. The response was great, and allowed us to gather valuable feedback.

Remove Issued Invoices was one of the top requests for Client Billing, and that option is now available. The payment due or failed invoices can be canceled, which will change the invoice status to Void. This applies to both one-time and recurring invoices.

Live Chat got a couple of highly requested features added as well. Members can now Download Transcripts of their live chats with our support team on The Hub > Support page. Additionally, members can now buy Live Chat Add-on for Team Members, so they too can get access to WPMU DEV support.

We also rolled out Sidebar Navigation last year. This provides the flexibility to add more site services without worrying about available space. It also improves navigation; with hosting subtasks as a drop down, users can go to any page (under Hosting) from the side navigation directly, eliminating an entire navigation step for users.

Here are some additional features and improvements that we implemented in 2022:

  • Pre-paid Hosting Credits – members can buy hosting credits in bulk to save on Hosting costs
  • Delete SnapShot backups for disconnected sites
  • Custom Thumbnails for websites – members can upload custom thumbnails instead of keeping defaults, providing a more customized UX for their clients
  • ‘Hub Accounts’ release to Hub 2.0 – we’ll keep running Hub 1 & 2 for now, but plan to completely remove Hub 1 by the end of March

All in all, 1000+ tasks were completed last year, including the development and improvement of the above mentioned projects, as well as other bug fixes, updates, and new features that were implemented across The Hub.”

Eager to share what’s up and coming for The Hub & Hub Client, Mukul continued:

“At the top of our punch list is Domains Transfer. Coming soon, members will be able to move their existing domains to WPMU DEV.

Also, we’re already hard at work on one of the most highly requested features by members – IMAP emails.

Here are some other items in the pipeline for 2023:

  • Automated Reselling for Hosting & Domains – members will be able to resell our hosting and domains to their clients in a self-provisioned way
  • Broken Link Checker (BLC) plugin – will integrate with The Hub (with a new API-based broken link checker service)
  • Centralized White Label Settings in The Hub – improved white labeling experience across our products, with configurations moving into a centralized location in The Hub
  • Reports 2.0 – coming this year, based on a lot of feedback, reports will be new and improved

We’re stoked about what’s coming, and believe you will be too.”

Premium Hosting

We’re toasting to hosting! 2022 has been a banner year for our Hosting service. New plans were added, and we’ve continued to boost the core features for every tier while the platform grows exponentially.

Product Manager Neel Gajjar is on deck to share all the highlights.

“It’s been almost three years since we launched our Hosting platform, and last year we were thrilled to introduce the addition of Quantum.

Quantum is a brand new droplet for Agency members, ideal for reseller hosting. It’s an even smaller, lower-priced offering than our prior starter plan, Bronze, but provides the same dedicated and compartmentalized resources. And, we’ve already updated its features. When first released, we had blocked certain items (such as plugins), then lifted those restrictions based on user feedback.

Also new – the ability to Suspend Hosting Sites. This valuable tool allows members to quickly incentivize slow or non-paying clients by temporarily (or permanently) suspending their site(s) from within The Hub.

Hourly Backups Add-on was implemented last year as well. Members can optionally enable hourly backups, instead of the default nightly backup on hosted sites.

Here are some other great new features and enhancements for Hosting in 2022:

  • Disable Staging Pass protection – option added
  • PHP 8.1 Support – added for both production and staging sites
  • ionCube Loader – enable or disable this on sites hosted with us (if any plugins require it)
  • Performance and Security improvements – hundreds of improvements in our hosting performance and security
  • Additional SSH commands allowed

To wrap up 2022’s accomplishments, I’ll share a cool stat. WPMU DEV Hosting handled 3000+ Manual Migrations last year for members, with the fastest time clocking in under 12 minutes!”

Ready to dish the dirt on what’s to come for hosting, Neel added:

“We’ve got some awesome stuff already mapped out for 2023, including:

  • Block XMLRPC by default – only used by outdated Windows/Mac software, XMLRPC is vulnerable and should be blocked by default
  • Custom SSH and SFTP path – members will be able to create SSH | SFTP accounts with custom paths
  • Ubuntu 22.08 – We will be upgrading our server operating system to the latest Ubuntu 22.08
  • PHP 8.2 – adding support for this released version, so members can use the latest PHP version for best site performance
  • Advance Monitoring of server resources such as Server load history, PHP Limits History, Ram Usage history, etc. Currently you can only see live server stats but with this feature you can see history of the data, such as what was the server usage like 24 hours ago

And of course, we’re constantly at work refining our Hosting platform overall, to offer better security and performance, so expect to continue seeing those upgrades.”

Hosting is going places, and we’re glad you’re with us for the ride.

A Good Year For WPMU DEV & Our Customers

That’s everything, folks. If you’re still reading, thanks for sticking with us.

It’s your input, usage, and feedback that helps us focus on what our members and the web development community value most. Then we get to work on implementing those features and enhancements in the way that most benefits our products, services, and you.

To see what’s on deck at any time during the year, check out our company Roadmap.

If you’re not a part of WPMU DEV, we invite you to try our Free Membership, which includes all of our free Plugins and Features, including the Free Hub (all maintained and updated) – completely free, no credit card required.

Take it to the next level with one of our Premier Memberships (all Pro plugins, The Hub, CDN, Client Billing, and much more) – along with a 30-day, money-back guarantee.

Go the distance with our Managed Hosting (Fully Dedicated, Lightning Fast, Rock-solid Security), which comes with a free 7-day trial for a no-risk, hassle-free experience.

Bonus: all of our Hosting and pro Membership plans come with WPMU DEV’s always on-call Expert Support – who assist with anything WordPress, not just our products.

Cheers to 2023! We wish you and yours happiness, health, and success throughout the year and beyond.

 

Using Automated Test Results To Improve Accessibility

A cursory google search will return a treasure trove of blog posts and articles espousing the value of adding accessibility checks to the testing automation pipeline. These articles are rife with tutorials and code snippets demonstrating just how simple it can be to grab one’s favorite open-source accessibility testing library, jam it into a cypress project, and presto changeo, shifting left, and accessibility has been achieved… right?

Unfortunately, no, because actioning results in a consistent, repeatable process is the actual goal of shift-left, not just injecting more testing. Unlike the aforementioned treasure trove of blog posts about how to add accessibility checks to testing automation, there is a noticeable dearth of content focused on how to leverage the results from those accessibility checks to drive change and improve accessibility.

With that in mind, the following article aims to fill that dearth by walking through a variety of ways to answer the question of “what’s next?” after the testing integration has been completed.

Status Quo

The confluence of maximum scalability and accessibility as requirements has brought most modern-day digital teams to the conclusion that the path to sustainable accessibility improvements requires a shift left with accessibility. Not surprisingly, the general agreement on the merits of shifting left has led to a tidal wave of content focused on how important it is to include accessibility checks in DevOps processes, like frontend testing automation, as a means to address accessibility earlier on in the product life cycle.

Unfortunately, there has yet to be a similar tidal wave of content addressing the important next steps of how to effectively use test results to fix problems and how to create processes and policies to reduce repeat issues and regression. This gap in enablement creates the problem that exists today:

The dramatic increase in the amount of accessibility testing performed in automation is not correlating to a proportional increase in the accessibility of the digital world.

Problem

The problem with the status quo is that without guidance on what to do with the results, increased testing does not correlate with increased accessibility (or a decrease in accessibility bugs).

Solutions

In order to properly tackle this problem, development teams need to be enabled and empowered to make the most of the output from automated accessibility testing. Only then can they effectively use the results to translate the increase in accessibility testing in their development lifecycle to a proportional decrease in accessibility issues that exist in the application.

How can we achieve this? With a combination of strategically positioned and mindfully structured quality gates within the CI/CD pipeline and leveraging freely available tools and technologies to efficiently remediate bugs when they are uncovered, your development team can be well on their way to effectively using automated accessibility results. Let’s dive into each of these ideas!

Quality Gates

Making a quality gate is an easy and effective way to automate an action on your project when committing your code. Most development teams now create gates to check if there are no linting errors, if all test cases have passed, or if the project has no errors. Automated accessibility results can fit right into this same model with ease!

Where Do The Gates Exist?

For the most part, the two primary locations for quality gates within the software development lifecycle (SDLC) are during pull requests (PRs) and build jobs (in CI).

With pull requests, one of the most commonly used tools is GitHub Actions, which allows development teams to automate a set of tasks that should be completed or checked when code is committed or deployed. In CI Jobs, the tools’ built-in functionality (Azure, Jenkins) is used to create a script that checks to see if test cases or scenario has passed. So, where does it make sense to have one for your team?

It all depends on what level development teams want to put a gate in place for accessibility testing results. If the team is doing more linting and component-level testing, the accessibility gate would make the most sense at a pull request level. If the automated test is at an integration level, meaning a full baked-out site ready for deployment, then the gate can be placed with a CI job.

Types Of Gates

There are two different ways that quality gates can operate: a soft check and a hard assertion.

A soft check is relatively simple in the definition. It looks at whether or not the accessibility tests were executed. That is it! If the accessibility checks were run, then the test passes. In contrast, assertions are more specific and stringent on what is allowed to pass. For example, if my accessibility test case runs, and it finds even ONE issue, the assertion fails, and the gate will say it has not passed.

So which one is most effective for your team? If you are looking to get more teams to buy into accessibility testing as a whole, a best practice is to not throw a hard assertion right away. Teams initially struggle with added tasks or requirements, and accessibility is no different. Starting with a soft gate allows teams to see what the requirement is going to be and what they are required to be doing.

Once a certain amount of time has passed, then that soft gate can switch to a hard assertion that will not allow a single automated issue out the door. However, if your team is mature enough and has been using accessibility automation for a while, a hard assertion may be used initially, as they already have experience with it.

Creating Effective Gates

Whether you are using a soft or hard gate, you have to create requirements that govern what the quality gate does with regard to accessibility automated results. Simply stating, “The accessibility test case failed,” is not the most effective way to make use of the automated results. Creation of gates that are data-driven, meaning they are based on a piece of data from the results, can help make a more effective gate that matches your development team or organization’s accessibility goals.

Here are three of the methods of applying assertions to govern accessibility quality:

  • Issue severity
    Pass or fail based on the existence or count of specific severity issues (Critical, Serious, and so on).
  • Most common issues
    Pass or fail based on the existence or count of specific issue types which are known to be most common (either global or organization specific).
  • Critical or Targeted UI /UX
    Do these bugs exist in high-traffic areas of the application, or do these bugs directly impede a user along a critical path through the UX?

Fixing Bugs

The creation and implementation of quality gates is an essential first step, but unfortunately, this is only half the battle. Ultimately a development organization needs to be able to fix the bugs found at the various quality gate inspection points. Otherwise, the applications’ quality will never improve, and nothing will clear the gates that were just put in place. What a terrifying thought that is.

In order to translate the adoption of the quality gates into improved accessibility, it is vital to be able to make effective use of the accessibility test results and leverage tools and technologies whenever possible to help drive remediation, which eliminates accessibility blockers and ultimately creates more inclusive experiences for users.

Accessibility Test Results

There is a common adage that “there is no such thing as bug-free software,” and given that accessibility conformance issues are bugs, this axiom applies to accessibility as well. As such, it is absolutely necessary to be able to clearly prioritize and triage accessibility test results in order to apply limited resources to seemingly unlimited bugs to fix them in as efficient and effective a way as possible.

It is helpful to have a few prioritization metrics to assist in the filtration and triage work when working with test results. Typically, context is an effective top-level filter, which is to say, attacking bugs and blockers that exist in high-traffic pages or screens or critical user flows is a useful way to drive maximal impact on the user experience and the application at large.

Another common filter, and one that is often secondary to the “context” filter mentioned above, is to prioritize bugs by their severity, which is to say, the impact on the user caused by the bug’s existence. Most free or open-source automated accessibility tools and libraries apply some form of issue severity or criticality label to their test results to help with this kind of prioritization.

Lastly, as a tertiary filter, some development teams are able to organize these bugs or tasks by thinking about the level of effort to implement a fix. This last filter isn’t something that will commonly be found in the test results themselves. Still, developers or product managers may be able to infer a level of effort estimation based on their own internal understanding of the application infrastructure and underlying source code.

Thankfully, accessibility test results, for the most part, share a level of consistency, regardless of which library is being used to generate the test results, in that they generally provide details about what specific checks failed, where the failures occurred in terms of page URL and sometimes even CSS or XPath as well as specific component HTML, and finally actionable recommendations on how to fix the components that failed the specific checks. That way, a developer always has a result that clearly states what’s wrong, where’s it wrong, and how to fix what’s wrong.

In the above ways, developers can clearly stack, rank, and prioritize tasks that result from automated accessibility test results. The test results themselves are typically designed to be clear and actionable so that each task can be remediated in a timely fashion. Again, the focus here is to be able to effectively deliver maximal impact with limited resources.

Helpful Tools

The above strategies are well and good in terms of having a clear direction for attacking known bugs within a project. Still, it can be daunting to figure out whether one’s remediation solution actually worked or further to figure out a path forward to prevent similar issues from recurring. This is where a number of free tools that exist in the community can come into play and support and empower development organizations to expedite remediation and enable validation of fixes, which ultimately improves downstream accessibility while maintaining development velocity.

One such family of free tools is the accessibility browser extension. These are free tools that can help teams locate, fix, and validate the remediation of accessibility bugs. It is likely that whatever accessibility library is being used in the CI/CD pipeline has an accompanying (and free) browser extension that can be used in local development environments. A couple of examples of browser extensions include:

The browser extensions allow a developer to quickly and easily scan a page in the browser, identify issues on the page, or as in the case described above, they can validate that an issue that was detected during the testing automation process, which they have since remediated, no longer exists (validation!). Browser extensions are also a fantastic tool that can be leveraged during active development to find and fix bugs before code gets committed. Often, they are used as a quality check during a pull request approval process, which can help prevent bugs from making their way downstream.

Another group of free tools that can help developers fix accessibility bugs is linters which can be integrated within the developers integrated development environment (IDE)and automatically identifies and sometimes automatically remediates accessibility bugs detected within the actual source code before it compiles and renders into HTML in a browser.

Linters are fantastic because they function similarly to a spell checker in a document editor tool like Microsoft Word. It’s largely fully automated and requires little to no effort for the developer. The downside is that linters typically have a limited number of reliable checks that can be executed for accessibility at the point of source code editing. Here are some of the top accessibility linters:

Equipping a development team with browser extensions and linters is a free and fast way to empower them to find and fix accessibility bugs immediately. The tools are simple to use, and no special accessibility training is required to execute the tests or consume and action the results. If the goal is to get farther faster with regard to actioning automated accessibility test results and improving accessibility, the adoption of these tools is a great first step.

The Next Level

Now that we have strategies for how to use results to improve accessibility at an operational level, what’s next? How can we ensure that all of our organization knows that accessibility is a practical piece of our development lifecycle? How can we build out our regression testing to include accessibility so that issues may not be reintroduced?

Codify it!

One way we can truly ensure that what we have created above will be done on a daily basis is to bring accessibility into your organization’s policy (also known as code policy or policy of code) — establishing such means that accessibility will be included throughout the SDLC as a foundational requirement and not an optional feature.

Although putting accessibility into the policy can take a while to achieve, the benefits of it are immeasurable. It creates a set of accessible coding practices that are clearly defined and established for how accessibility becomes part of the acceptance criteria or definition of “done” at the company level. We can use the automated accessibility results to drive this policy of code and ensure that the teams are doing full testing, using gates, and fixing the issues set by the policy!

Automate it!

Most automated accessibility testing libraries are standard out-of-the-box libraries that test generically for accessibility issues that exist on the page. The typical amount of issues caught is around 40%, which is a good amount. However, there is a way in which we can write automated accessibility tests to go above and beyond even more!

Accessibility regression scripts allow you to check accessibility functionality and markup to ensure that the contents of your page are behaving the way they should. Will this guarantee it works with a screen reader? Nope. But it will ensure that the accessible functionality of it is properly working.

For example, let’s say you have an expand/collapse section that shows extra details have you click the button. Automated accessibility libraries would be able to check to ensure the button has accessible text and maybe that it has a focus indicator. Writing a regression script, you could check to ensure the following:

  • It works with a keyboard (Enter and Space);
  • aria-expanded=” true/false” is properly set on the button;
  • The content in the expanded section is properly hidden from screen readers.

Doing this on key components can help ensure that the markup is properly set for assistive technology, and if there is an issue, it can be easier to debug if the issue is in code or potentially a bug in the assistive technology.

Conclusion

The “shift left” movement within the accessibility industry over the last few years has done a lot of good in terms of generating awareness and momentum. It has helped engage and activate companies and teams to actually take action to impact accessibility and inclusion within their digital properties, which in and of itself is a victory.

Even so, the actual impact on the overall accessibility of the digital world will continue to be somewhat limited until teams are not only empowered to execute tests in efficient ways but also that they are enabled to effectively use the test results to govern the overall quality, drive rapid remediation, and ultimately put process and structure in place to prevent regression.

In the end, the goal is really more than simply shifting left with accessibility, which often ends up taking what a bottleneck of testing in the QA stage of the SDLC is and simply dragging it left and upstream and placing it into the CI/CD pipeline. What really is desired, if sustainable digital accessibility transformation is the goal, is to decentralize the accessibility work and democratize it across the entire development team so that everyone participates (and hopefully into the design as well!) in the process.

The huge increase in automated accessibility testing adoption is a wonderful first step, but ultimately its impact is limited if we don’t know what to do with the results. If teams better understand how they can use these test results, then the increase in testing will, by default, increase accessibility in the end product. Simple gatekeeping, effective tool use and a mindful approach can have a major impact and lead to a more accessible digital world for all.

Related Reading on Smashing Magazine

Ecommerce Website Design Starter Guide: Learn the Basics

If you want to make designing an ecommerce website easy and fast, our top recommendation for the best ecommerce platform is Shopify. It has great security and tons of pre-made themes, and new users can try it for 14 days free, no credit card required

Designing an ecommerce website is just as important as writing the copy or marketing the products. A good site will make it easy for users to browse products, talk to customer service, and finalize their sales at checkout. But, there are right ways and wrong ways to design a site. In this guide, we’ll break down the best practices for designing a great ecommerce website, and the biggest pitfalls you should avoid.  

The 6 Best Ecommerce Platforms For Ecommerce Website Design 

Trying to design an ecommerce website is a lot easier if you choose the right platform. That’s why we’ve spent hours researching the best platforms out there to help you choose the right one based on what you’re hoping to achieve. You can check out the full review of our top recommendations here. 

  • Shopify – Best all-around ecommerce platform
  • Zyro – Best price for a full online store
  • Wix – Best for stores with fewer than 100 products
  • BigCommerce – Best for large inventories
  • Squarespace – Best for cornering a niche market
  • Bluehost – Best for WordPress users who want to sell online
Quicksprout.com - Ecommerce Website Design Starter Guide: Learn the Basics.

What is Ecommerce Website Design? 

Ecommerce website design, put simply, is designing an online store website in a way that makes it easy for people to buy things and creates an overall positive user experience.

Having a good design is important for any website because it takes most people less than a second to decide whether they like a site. But, with ecommerce website design, it’s especially important for a site to be easy to navigate and to be attractive because that will determine whether or not the business is successful. 

When looking at ecommerce specific design, there are also a few extra design elements that need to be considered. Building trust by creating the right sections and adding the right logos, badges, and colors is important. And, the design needs to reflect the branding of the products, but without becoming messy. 

The goal, and the challenge, of ecommerce website design, is to create something aesthetic that compliments the products being sold, while still functioning successfully and being attractive to users. 

How Ecommerce Website Design Works 

When you’re looking at designing an ecommerce website, there are three routes you can choose: 

  1. Using a Template 
  2. Paying a Designer 
  3. Build Your Own Site From Scratch

For most people, using a template is the best option. 

Let’s break down these three options and see what each one involves. 

Using a Template 

Most ecommerce platforms will have templates included when you sign up and set up your store. For example, one of our top recommendations, Shopify, offers users almost one hundred themes to choose from, catering to different types of stores and different industries. 

You can browse through the themes and then choose the one that works for your brand and customize it. This is a great option for anyone who is limited in coding experience. 

You’ll still get to add all the important design elements we talk about in this guide without having to worry about messing up code or a slow-loading website. 

And, especially if you use a good platform like Shopify, you can add plugins for all the extra features you like so it’s easy to create a design that’s personalized to your brand.

Screenshot of Shopify webpage showing free themes
Shopify has a plethora of ecommerce themes and templates to choose from. 

Paying a Designer

If you have a big budget, your next option is to pay a designer. 

They can either help you customize a template for the ecommerce store, or you can pay them to build a store from scratch and add code. This option is great if personal branding is really important or if you want lots of complex features. 

However, due to the complicated nature of ecommerce sites (setting up secure payment processors, adding different currencies, etc) be prepared for the cost of hiring a designer to grow quickly. 

It’s a good way to save time, but it will be a lot more expensive than just using a theme from an ecommerce platform. 

Creating Your Own Site

If you really want complete control over your ecommerce website design, you do have the option of creating your own website from scratch. 

However, this will be extremely difficult unless you are a web designer, and you truly understand coding. An ecommerce store is more complicated than a regular site – because money is involved, and there is a certain standard of safety and functionality that has to be programmed into the design. 

You should only consider this route if you are experienced in web design and you need to create something unique. Bear in mind that if you do create and design your own site from scratch, you then need to figure out how to connect it to ecommerce features like payment processors. 

Realistically, you’re much better off using a platform like Shopify, and then customizing as you go. 

Strategies for Better Ecommerce Web Design

When you’re designing any website, there are some things you need to take into consideration. This includes things like site loading speeds, colors, site mapping, link-building, and graphics. 

But, when it comes to ecommerce web design, there are a couple of extra things you’ll need to consider because you need to make security a priority and make the user journey simple. 

Here are some of the things you should focus on when designing an ecommerce website: 

Building Trust 

If you use a platform like Shopify, it’ll make your life a lot easier, because a lot of safety features like paywalls and SSL certificates will be built in. When it comes to security features, Shopify has a great reputation and can help add the right features and display the right security badges.

Another way that you can build trust is by creating pages that tell people about the brand, and the team behind it, including photos. You should also make sure you have a privacy policy and terms and conditions clearly displayed in the footer, and that you make any shipping or return instructions obvious and easy to find. 

Important website information such as privacy policy, terms of service, disclaimer, and terms and conditions.
Make sure to put all the important information in your footer.

UX 

Because ecommerce websites tend to be really complicated with lots of pages and product categories, you want to make it easy for people to navigate the site. 

You should make a sitemap on paper first before you set about customizing your design. You’ll need to know how many pages you want to add, where each page is going to link to, and how to connect them all to each other. 

Once you’re clear on which pages you are creating, what goes where, and how you need to display them, it’ll be easier for you to create a design that makes sense and that keeps your audience flowing through the sales funnel all the way to making a purchase. 

Everything that needs to be navigated or clicked should be clearly labeled with things like buttons. You should also include a search bar and both a header and footer menu so users can easily find what they are looking for. 

Site Speed

With any website, loading speeds are important. But, when it comes to ecommerce sites, they are more important than ever because you’ll have lots of products with images that need to load fast. The audience will leave a page if the product they want to see doesn’t load fast enough, losing you the sale. 

When you create your design, you want to remove any unnecessary code, compress images to the perfect size, and consider using a caching plugin to help keep things as fast as possible. 

If you use a theme, many platforms will be able to point you in the direction of a lightweight theme with faster loading times (like Shopify does with Dawn.) You can also use a free tool called Test My Store Speed that will help you test your ecommerce website speed so you can see where there’s room for improvement.

Shopify Performance Analyzer
Shopify has a plethora of ecommerce themes and templates to choose from.

Examples of Ecommerce Website Designs That Work

If you’re not a professional designer, you might be struggling to know where to start. 

Let’s take a look at some examples of ecommerce websites that have great designs and analyze what they’re doing right: 

1. Harper Wilde

Harper Wilde home page.
Harper Wilde does a great job of creating a clear brand while still being simple with its design. 

You can see in the screenshot that they have a clear menu, and buttons that are easy to find and that give a clear CTA, and they build trust straight away by adding a guarantee in the top banner. 

Harper Wilde is also a Shopify site, showing that you can still design a unique and attractive website on the platform using a theme. 

2. Pop Chart

Pop Chart home page.
Pop Chart makes great use of design to build a brand and highlight deals. 

Like Harper Wilde, Pop Chart is created using a customized Shopify template. You can see that both sites are still different and have their own distinct branding, even if they both use themes. 

Pop Chart focuses more on making sure the design highlights sales features like discounts or promos. This is a great trick you can use when you are designing your own ecommerce website – putting discounts on buttons or on banners to catch your user’s eyes and give them the incentive to buy straight away. 

Pop Chart also makes great use of design to build a brand and highlight deals while still making it easy for users to navigate and keeping the important things clean, like menus. 

3. Haus

Haus home page.
Haus is another Shopify theme that’s been customized to fit its own brand. 

Haus is a great example of playing around with the design to keep things interesting while still being easy to navigate and keeping things simple. 

You can see that Haus puts the Menu to the side, which means they can still use a big picture to fit their clean aesthetic and show off their products right away, without confusing users. They also use small details like arrows to help move users through the site and avoid people getting lost and clicking away. 

Haus is a good example of using design in a creative and intentional way to get users to follow the website journey from your sitemap without sacrificing branding. You can see how easy it is to play with where and how you place different elements on your site to make it easier for audiences to navigate and create a better overall experience. 

How to Get Started With Ecommerce Web Design 

If you want to create a great ecommerce website design that’s personalized and functional, you can get started easily in just a few steps. Let’s break down the easiest and most effective way you can set up and design a site: 

Step 1. Sign up for an Ecommerce Platform 

As previously mentioned, the best way to design an ecommerce website is to sign up for an ecommerce platform, like Shopify, and choose a theme to customize. 

Shopify is an easy and popular option, but there are plenty of other choices you might want to check out. We’ve recently reviewed the best options available, so if you want to see the pros and cons of each, check out our guide here

Step 2. Choose A Template Or A Free Theme 

Most ecommerce platforms have tons of themes to choose from – many with selections ranging into the hundreds. 

Once you’ve selected an ecommerce platform and got signed up, you can choose a theme that has all the functionalities you want. If you want to make this step as easy as possible for yourself, focus on choosing a theme that is the most similar to the final site you’d like. 

You can customize colors, and add logos and fonts after, but the more similar to your end site your theme is, the less work you’ll have with planning your site. 

Shopify website template example.
Customize your Shopify theme with colors, fonts, logos, and more.

Step 3. Create a SiteMap 

As we mentioned before, to create a great site that makes sense, you should start by creating a site map on paper where you plan out which pages and category pages you have, and where each one will be linked. 

Once you have a clear idea on paper of which pages you’ll need and how they all fit together, you can add any new pages or categories to your theme and start building out your website directly on your chosen platform. 

Having the sitemap will also make it a lot faster for you to add things like buttons, menus, and footers to help with navigation.

Step 4. Download Plugins 

The next thing you’ll want to do is add some customizable plugins to your site. 

Each different platform will be able to integrate with different plugins, and big platforms like Shopify can integrate with thousands of other apps and services. 

Shopify app store.
Shopify has thousands of plugins to integrate with your ecommerce website. 

You should add plugins for any functionalities that aren’t included in your theme – so things like pop-ups, chat boxes, countdown timers, etc. Only add plugins that are really necessary though, because the more plugins you have, the slower your site. 

Keep the focus on adding plugins that help with any of the following: 

  • Security
  • UX Experience 
  • Customer Service 
  • Making Sales 
  • Building Trust 

Step 5. Customize Your Theme 

The next step is to actually customize your site with things like different fonts, images, and brand colors. 

You’ll also want to add high-quality images for all of your products and pair them with short but powerful descriptions. This is where you get to play around with your plugins and theme builder to balance functionality with branding and aesthetics. 

Try to always keep the user experience at the front of your design though. You can see from the examples we looked at that it’s better to keep things simple and use block colors and images to do the talking than to confuse your audience with too many CTA’s and buttons. 

Things To Avoid With Ecommerce Web Design 

When it comes to designing an ecommerce website, there are a few things you want to avoid. Here are some of the biggest mistakes most people make that you should try not to do: 

Trying to Do Everything for Free 

Yes, using an ecommerce platform is very cost-effective, and some even have free versions – but trying to design an ecommerce website that is safe enough to handle money and easy to navigate will be a pain. 

If you try to do your own coding, you’ll just end up having more and more issues as your store grows – which will mean you could end up having to spend more money fixing code in the future. It’s worth the investment to work with a secure ecommerce platform that can guarantee online security and good loading speeds. 

Making Your Site Too Complicated 

When you are designing a site, it’s easy to get caught up in the fun parts of things, like the photos or color scheme. But, you need to remember the goal of an ecommerce site isn’t to look good – it’s to make sales. 

Don’t fall into the trap of making the design so complicated that users get distracted, get overwhelmed when they get to check out or struggle to find the product they want. Take inspiration from the examples we looked at and make sure that the way to the checkout page is always clear and easy to find. 

Using Low-Quality Images 

All sites should strive to have high-quality images in order to improve the UX and SEO. But, when you are designing an ecommerce website, it’s even more important to make sure photos are high quality, that they load correctly, and that they are placed in the right places. 

Some customers will base their entire purchase on a photo alone. Make sure that photos are optimized for loading speed and that you test each page before going live. 

Example of a website's product photo quality.
Some customers will base their entire purchase on a photo alone.

Final Thoughts About Ecommerce Website Design 

Designing an ecommerce website can be both easy, and fun. As long as you are able to strike a balance between functionality and consistent branding, you can create a beautiful site you’re proud of that also converts into sales.

Remember that making sales and getting conversions should come before complicated design. Don’t feel pressure to have a sleek, animated website – using one of the free themes with your own twist will do just fine for what you need.

If you do want some pointers on making sales with your ecommerce store or getting it set up, here are some more Quick Sprout articles you should check out next: 

Designing Search (part 3): Keeping on track


In the previous post we looked at techniques to help us create and articulate more effective queries. From auto-complete for lookup tasks to auto-suggest for exploratory search, these simple techniques can often make the difference between success and failure.

But occasionally things do go wrong. Sometimes our information journey is more complex than we’d anticipated, and we find ourselves straying off the ideal course. Worse still, in our determination to pursue our original goal, we may overlook other, more productive directions, leaving us endlessly finessing a flawed strategy. Sometimes we are in too deep to turn around and start again.

Collective #731



Codrops Collective 731 item image
Our Sponsor

Apple Device Management Made Easy

Managing your business’s Apple devices is time-consuming, especially when employees are WFH. Jamf Now is a mobile device management solution that simply sets up, connects, and secures your devices from anywhere; no IT experience required! Codrops readers can manage up to 3 devices for free today!

Sign Up Free Today


Codrops Collective 731 item image

The 2022 Web Almanac

A new edition of the Web Almanac, the annual state of the web report combining the expertise of the web community with the data and trends of the HTTP Archive.

Check it out



Codrops Collective 731 item image

Neodrag

Lightweight multi-framework libraries for draggability on the web. By Puru Vijay.

Check it out



Codrops Collective 731 item image

Learn HTML

The latest course in a series of courses on web.dev to help get you up to speed with modern web development.

Check it out







Codrops Collective 731 item image

figr.app

You can work together in real time with this simple and advanced calculator.

Check it out





Codrops Collective 731 item image

Enhance

Enhance is a web standards-based HTML framework. It’s designed to provide a dependable foundation for building lightweight, flexible, and future-proof web applications.

Check it out





Codrops Collective 731 item image

KREA

Explore millions of AI generated images and create collections of prompts. You can now also access the data they have built it with: Open Promts.

Check it out






Codrops Collective 731 item image

Hologram

Maxime Heckel is exploring Three.js render targets and layers in R3F in this remake of Patrick Schroen’s hologram scene.

Check it out



Codrops Collective 731 item image

Nightdrive

James Stanley made a JavaScript simulation of driving at night time on the motorway.

Check it out


UX Checklists For Interface Designers

Given just how complex the web has become, it’s easy to overlook some fine little details just before the big release. And sometimes it’s difficult to pick out just the right technique or strategy to address a particular problem. That’s where design checklists can help — and there a few new ones that you might find helpful, too.

Checklist Design

Checklist Design is an ever-growing collection of best design practices, all gathered in one single place. You’ll find pretty much everything from checklists for standalone pages to elements and flows, as well as topics and branding. A neat little resource created by George Hatzis.

Design System Checklist

Design System Checklist is an open-source checklist to planning, building and growing a design system. It includes the foundation of things to keep in mind for design language, design tokens, core components, tooling and project management. Beautifully created and maintaned by fine folks from reshaped. Also, you might want to check Design Systems Handbook as well and you can download the Design System Checklist in Figma.

Accessibility Not-Checklist

Accessibility Not-Checklist is a thorough guide through accessibility, with points grouped by topics and success criteria, with filters for WCAG 2.0 and WCAG 2.1 and best practice recommendations. You can sort the checklist by topic and by role. A fantastic tool by fine folks at intopia.

A11y Project Checklist

A11y Project Checklist is a yet another very thorough checklist for accessibility that goes into all the fine detail from forms and controls to video, audio and animation. It also links to specific parts of WCAG in every individual section with further examples and guidelines. Neat!

Design System Checklist Trello Template

You and your team are working on a design system? The Design System Checklist template for Trello is a great example of how to structure your work and keep everyone involved on the same page. Even if you're not a Trello user, the template provides some valuable ideas for creating your own checklist of things to take care of when working on a mammoth project like this.

Gov.UK Design System Components (Figma)

The lovely team behind Gov.UK has released a full collection of styles and components designed for UK Government services. During the design process, the team has tested and validated the design of the components, and we can use them to explore the states or conditions that we perhaps haven’t considered in our design just yet.

You can also check the GOV.UK Prototype Kit if you want to install all components locally, and GOV.UK Design System to explore how to use the styles and components in prototyping.

Complex Tables UX Tree

In his article on Architecting a complex table, Slava Shestopalov explores how to design and architect advanced tables — with a very comprehensive table tree checklist of all those fine details that are often forgotten or overlooked.

UX Project Tools Checklist

UX Recipe is a helpful little tool to discover and choose some of the UX project tools and techniques for your project. It also allows you to estimate the amount of time require for the work done. All tools are broken down into groups, and if you click on the hashtags, you’ll find plenty of useful resources for each category. Created and maintained by Alecsandru Grigoriu.

UX Research Methods Flowchart

How do you choose what UX research methods works best for you? There are at least 20 popular methods, and a handy UX Research Methods Flowchart by Norman-Nielsen Group helps you find the right one.

It provides an overview of common strategies, grouped into behavioral, attitudinal, qualitative and quantitative methods. Once you know what insights you are after, you can pick your strategy using the chart.

Form Design UX Checklist

With web form design, it can be quite difficult to figure out just the right component to use when asking a particular question. The team behind Lyft has created a flow chart to make it easier for designers (and not designers alike) to make decisions for their forms.

In an article about form selection patterns, Runi Goswami describes the struggles the team went through when designing a segmented control, and how they ended up with a form selection control flow chart as a result.

Decision Trees For Design System Components

Design systems often come in various flavors. Surely there will be basic components, color, typography and spacing, but often also more sophisticated components, usage guidelines, accessibility considerations and live previews. Additionally, Workday Canvas Design System includes flow charts for deciding what components to use, with examples of the outcome that designers and non-designers can follow to make their decisions.

Interaction Design Checklist

The IxD Checklist that Aaron Legaspi and Amit Jakhu created helps us form a better understanding of interaction. Whenever you're building some kind of interaction — be it a control, navigation, or an entire interface — you can use the checklist to evaluate your design against affordance, simplicity, structure, consistency, accessibility, tolerance, and feedback to ensure it is easy to use for everyone.

Bonus: Text-To-Timeline Tool

Markwhen: Text-to-Timeline is an incredible little tool to generate timelines, e.g. for project planning or life timeline! You write markdown-ish text and it gets converted into a nice looking cascading timeline. Also available as a VS Code Extension.

And That’s A Wrap!

If you are looking for more gems like this one, we’ve published a few UX guides with checklists over the last few years, so feel free to continue exploring there. Happy checklisting, everyone!

Implementing A Reset Password Feature With Next.js Dynamic Routes

In a general sense, authentication poses itself as a roadblock to many people when they are trying to get started with a particular framework, and Next.js isn’t left behind.

Although, there are lots of resources around building authenticated applications with Next.js. Well, there’s even an open-source project that literally handles authentication from the ground up.

But, the scope of this article doesn’t revolve around the whole concept of authentication. We’re only picking a specific pattern of the authentication process: the “reset password” flow and how it can be implemented on the client-side — frontend — of a web application.

In this article, you’re going to see how this feature can be implemented by using the common data-fetching tool, Axios — the built-in dynamic routes feature of Next.js and the useRouter hook.

An Overview Of The Reset-Password Flow

Since the advent of the web, Engineers have always strived to provide solutions to the problems that arose during the early days of the web — and the security of software on the web is no exception.

There’s this popular saying that goes thus: “Users will always forget their passwords,” and that is the absolute truth. A lot of people even dread the “reset-password” page because, come to think of it, after spending a lot of time trying to guess their passwords — all to no avail — they’re either frustrated or angry as they land on this particular page.

As we create user interfaces, we should also try as much as possible to make the experience enjoyable for the users. As much as we’d love to just get over the flow of the reset password process, the UX of that flow should be prioritized too.

The common flow of the password reset process can be seen below.

  • The user is frustrated after trying to sign without success. They click on the “password-reset” link, and they’re redirected to the corresponding page. The user interface that they see is the typical web form that’ll take in either their email address or username.
  • When they type their email address or username into the input field, they click on the button which has the common “email me a recovery link” text.
  • They get a confirmation that a secure link has been sent to their email. Sometimes, this confirmation text can be displayed in a card-like component or a modal that fades out over time.

Note: For security purposes and good UX, it is good to use a text that is quite similar to this: “An email has been sent to your inbox. Please click the link when you get it.” You can construct this sentence anyhow you deem fit, as long as it does not reveal that the email or username they entered exists in the database. This approach prevents attackers from knowing if that email exists at all, thus sabotaging any phishing attempt they may want to try with the said email address. As for the UX, the text doesn’t assure the user that the credentials they’ve entered are the correct ones. This, in turn, allows them to double-check whatever credentials they’re submitting.

  • The link that is sent to their email address contains a JWT and their user_id, or in this case, their email address.
  • Upon clicking on that link, they’re redirected to the route/page where they can input their new password. The route that the user will be on may be of the form below
https://localhost:3000/reset-password/user-email/JWToken
  • The last part of the flow is to verify if the JWT that is generated is associated with the user’s account. If not, we throw an error by rendering the error message that is obtained from the backend.

Now that you’ve seen how the “reset password” flow is structured, let’s see how it can be implemented with Next.js.

Understanding Dynamic Routes

In this section, we’ll go over the concept of dynamic routes by illustrating it with the folder structure of a Next.js project and see how we’ll integrate it into the “reset password” feature. But first, let’s set up a Next.js app.

npx create-next-app app-name

The command above does that for us. The Next.js team has already shipped a new update to the framework, and they’ve also introduced a couple of new folders and features in the default project structure. However, we won’t be covering much on that aspect, as it is out of the scope of this article. You can read more about the updates here if you want to.

In the snippet below, you’ll see the basic structure of the files we’ll be interacting with in this article.

└── pages /
    ├── forgot-password/
    │   └── [token]/
    │       └── [email].js
    ├── _app.js
    └── index.js

Above, you’ll see that the files in the folder structure are quite small. That’s because I want to be concise as much as possible in this article.

And since the implementation of the “password reset” flow is our utmost concern, I think it’ll be best if we have less clutter. Now, let’s get a bit of an understanding of this structure.

You’ll notice that we have the forgot-password folder in the pages directory, which contains some files. But the naming convention of these files is quite different from the way other files are named. The name of the files — token and email.js — are wrapped with a pair of square brackets.

Folders and files that are named like this are referred to as dynamic routes, and since they’re in the pages directory, they automatically become routes that can be accessed by the browser. They are dynamic because the values that these routes take are not static, which means that they change over time.

This pattern of naming files is commonly seen in action when you decide to build a blog or when you’re interacting with data that changes based on the type of user that is logged into an application. You can take a look at how I utilized this feature of Next.js when I was building my blog. You can also learn more about it in the Next.js docs.

In the forgot-password folder, the path to where the UI containing the forgot password form can be accessed here. Take a look at it below.

http://localhost:3000/forgot-password/token/email

Since it is a dynamic route, the token and email URL parameters will always change based on the user that is trying to reset their password. The token and email for user A will be different from that of user B.

Reading Url Parameters With The Userouter Hook

The useRouter hook in Next.js can be used to achieve a lot of practical frontend UI implementations — from the common idea of implementing an active navbar item with the .pathname key, to more complex features.

Let’s see how we can read the URL parameters from dynamic routes with the useRouter hook now, shall we? To do that, you’ll have to import the module into your page/component first.

import { useRouter } from 'next/router'
export default function PageComponent({ children }) {
  const router = useRouter()
  return (
    <React.Fragment>
      {/ page content falls below /}
      <div>{children}</div>
    </React.Fragment>
  )
}

The snippet above shows the basic usage of the hook. Since we’re interested in the query parameters of the URL, it’ll be best if we destructure the query method of the hook instead of doing something like this: router.query. We’ll just do something similar below.

import { useRouter } from 'next/router'
const { query } = useRouter()

We can now go ahead to create variables that’ll store the URL parameters that we want. The snippet below shows how you can do that.

const token = query.token
const email = query.email

Note that the query.token and query.email values are a result of the name of the files. Recall from the folder structure in the forgot-password folder where we have the [email].js and [token] files. If you rename those files to [userEmail].js and [userToken] respectively, the pattern of assigning these variables will become something like the one below.

const token = query.userToken
const email = query.userEmail

You can always log these variables to the console to see the result.

Now that you’ve gotten an understanding of how these parameters are obtained from the URL, let’s get started by building the structure of the forms.

Building The Forms

In this section, we’ll walk through the process of building the form and how you can use Axios to perform data fetching via the arbitrary API endpoint. We won’t be focusing on the styling of these forms and the explanation of the structure. I’m assuming you already know how to structure and style a basic React form. So let’s get started with the form layout on the forget-password route.

import React from 'react'
import axios from 'axios'
import { ErrModal, SuccessModal } from '../components/Modals'

export const DefaultResetPassword = () => {
  const [email, setEmail] = React.useState('')
  const [loading, setLoading] = React.useState(false)

  const handleForgot = () => { } // we’ll see this later

  return (
    <div>
      <form onSubmit={handleForgot} className="reset-password">
        <h1>Forgot Password</h1>
        <p>You are not alone. We’ve all been here at some point.</p>
        <div>
          <label htmlFor="email">Email address</label>
          <input
            type="email"
            name="email"
            id="email"
            placeholder= “your email address”
            value={email}
            onChange={(e) => setEmail(e.target.value)}
            required
          />
        </div>
        <button name="reset-pwd-button" className="reset-pwd">
          {!loading ? ‘Get secure link’: ‘Sending...’}
        </button>
      </form>
    </div>
  )
}

The snippet above shows the basic structure of the UI that you’ll see when you get to the forgot-password route. You’ll notice the text in the paragraph tag below the bold “Forgot password” text.

<p>You are not alone. We’ve all been here at some point</p>

With a type of text like the one above, you are improving the user experience of people who get to the forgot password page of your app. You are assuring them that it is not a big deal that they forgot their password(s), so there’s no need to feel bad about it.

You don’t necessarily need to use the exact text above. You can just make sure that whatever text you are using has a tone of empathy.

Now, let’s move on to the important part of this form, which is where we need to declare a function that’ll send the email that the user enters in the input field to the backend.

import { authEndpoints } from '../endpoints'

export const DefaultResetPassword = () => {
  const handleForgot = async (e) => {
    e.preventDefault()
    try {
      setLoading(true)
      const response = await axios({
        method: 'POST',
        url: authEndpoints.recover,
        data: {
          email,
        },
        headers: {
          'Content-Type': 'application/json',
        },
      })
      setResestSuccess(response.data.msg)
      setLoading(false)
      setResetError('')
    } catch (error) {
      setLoading(false)
      const { data } = error.response
      setResetError(data.msg)
      setResestSuccess(null)
    }
  }
  return <div>{/* ...previous form component */}</div>
}

From the snippet above, you’ll notice that we’re importing the API endpoint that we’ll be sending a POST request to — and that’s why we’re passing it as a variable to the url key in the Axios method.

The POST request receives the user’s email address as payload, which in turn will be validated at the backend, and a JWT will be generated for that email address which will be used to authorize the password reset process of the user.

setResestSuccess(response.data.msg)
setLoading(false)
setResetError('')
catch (error) {
  setLoading(false)
  const { data } = error.response
  setResetError(data.msg)
  setResestSuccess(null)
}

When you take a look at the snippet above, you’ll notice that we’re using some already-declared state callback functions of the state variables.

An example is the setLoading function which has its value set to true in the try block. Then, its value is set to false when the data has been successfully sent. And if it doesn’t, we have a catch block that will “catch” the error and displays the error message that we’ve destructured from the endpoint.

You’ll also notice that there are a couple of state callback functions in the snippet above, like setResestSuccess and setResetError.

The setters are obtained from the declaration of the state variables. See them below.

import React from 'react'
import { ErrModal, SuccessModal } from '../components/Modals'

export const DefaultResetPassword = () => {
  const [resetSuccess, setResestSuccess] = React.useState()
  const [resetError, setResetError] = React.useState()
  return (
    <div>
      {resetError ? <ErrModal message={resetError} /> : null}
      {resetSuccess ? <SuccessModal message={resetSuccess} /> : null}
      <form onSubmit={handleForgot} className="reset-password">
        {/* form content */}
      </form>
    </div>
  )
}

The error or success messages gotten from the backend can be rendered in the UI to let the user know the status of their action(s).

You’ll notice that we’re using custom modal components to render the message. These components receive the message as props, and they can be reused across the codebase. Take a look at the structure of the components below.

export const SuccessModal = ({ message }) => {
  return (
    <div className="auth-success-msg">
      <p>{message}</p>
    </div>
  )
}
export const ErrModal = ({ message }) => {
  return (
    <div className="auth-err-msg">
      <p>{message}</p>
    </div>
  )
}

You can style these components uniquely so that you can be able to distinguish the “error” modal from the “success” modal. The common convention is to use red color for error messages and green color for success messages. How you choose to style these components is completely up to you.

In addition to all that has been said, we need a way to verify that the correct data type is being passed as a prop to the modal component. This can be achieved with the “prop-type” module in react.

propTypes.ErrModal = {
  message: propTypes.string.isRequired,
}
propTypes.SuccessModal = {
  message: propTypes.string.isRequired,
}

The type-checking process in the snippet above ensures that the data the component receives must be a string, and it is required. If the component does not receive a prop with a string value, React will throw an error.

Now that we’ve covered the important aspect of the first form and the building blocks of what we’ll be replicating in the reset-password route. Let’s get started by taking a look at the layout of the form below.

import axios from "axios";
import React from “react”;
import Head from “next/head”;
import { useRouter } from "next/router";
import { SuccessModal, ErrModal } from "../components/Modals";

const ResetPassword = () => {
  const [newPassword, setNewPassword] = React.useState("");
  const [loading, setLoading] = React.useState(false);
  const [resetPasswordSuccess, setResetPasswordSuccess] = React.useState();
  const [resetPasswordError, setResetPasswordError] = React.useState();

  const { query } = useRouter();
  const token = query.token;
  const email = query.email;

  const resetPassword = () => { } // coming in later...

  return (
    <React.Fragment>
      <Head>
        <title>Reset your password</title>
      </Head>
      <div>
        {email && token ? (
          <div className="auth-wrapper">
            {resetPasswordSuccess ? (
              <SuccessModal message={resetPasswordSuccess} />
            ) : (
              null
            )}
            {resetPasswordError ? (
              <ErrModal message={resetPasswordError} />
            ) : (
              null
            )}
            <form onSubmit={resetPassword} className="reset-password">
              <h1>Reset Password</h1>
              <p>Please enter your new password</p>
              <div>
                <label htmlFor="password">Password*</label>
                <input
                  name="password"
                  type="password"
                  id="password"
                  placeholder="enter new pasword"
                  value={newPassword}
                  onChange={(e) => setNewPassword(e.target.value)}
                />
              </input>
              <button
                name="reset-pwd-button"
                className="reset-pwd"
              >
                {!loading ? "Reset" : "Processing..."}
              </button>
            </form>
          </div>
        ) : (
          <p>The page you're trying to get to isn't available</p>
        )}
      </div>
    </React.Fragment>
  );
};

Since we’ve gone through the rudiments of the first form in the previous section, the snippet above contains almost the same thing in the previous form.

You can see how we’re reading the parameters from the URL and the declarations of the password reset error and success variables too.

const [resetPasswordSuccess, setResetPasswordSuccess] = React.useState()
const [resetPasswordError, setResetPasswordError] = React.useState()
const { query } = useRouter()
const token = query.token
const email = query.email

You’ll also notice the way we’re conditionally rendering the reset password form by checking if the email and token variables are present in the URL; if these variables are false (i.e., they are not in the URL), we render a text that says that the page they’re looking for isn’t available.

{
  email && token ? (
    <div className="auth-wrapper">
      <FormComponentt />
    </div>
  ) : (
    <p>The page you’re trying to get to isn’t available</p>
  )
}

Now, let’s take a look at the handler function that we’d use in sending the new password of the user — coupled with the token and the email for the purpose of verification — to the backend through the API endpoint.

import { authEndpoints } from '../endpoints'
const resetPassword = async (e) => {
  e.preventDefault()
  try {
    setLoading(true)
    const response = await axios({
      method: 'POST',
      url: authEndpoints.resetPassword,
      data: {
        token,
        email,
        password: newPassword,
      },
      headers: {
        'Content-Type': 'application/json',
      },
    })
    setResetPasswordSuccess(response.data.msg)
    setLoading(false)
    setTimeout(() => {
      router.push('/')
    }, 4000)
    setResetPasswordError('')
  } catch (error) {
    setLoading(false)
    setResetPasswordError(error.response.data.msg)
    setResetPasswordSuccess(null)
  }
}

The snippet above is an asynchronous handler function. We’re using it to send a POST request with the user’s new password, the access token, and the email address — which we grabbed from the query parameters at the URL segment.

setTimeout(() => {
  router.push('/')
}, 4000)

When you take a look at the snippet above, you’ll see how we’re using the setTimeout method in JavaScript and Next.js’ useRouter hook to redirect the user to the home page — which is the login page in this case — after four seconds (you can reduce this time frame if you want to), so they can log in again.

Doing this also adds to the good user experience metric, as it prevents the user from looking for a link or a button that takes them back to the login page.

Final Thoughts

There is a lot of information about the best practices and awesome password-reset design patterns out there. This article is just a frontend implementation of a password-reset flow which also factors in the issue of user experience. It is not enough to just create a password reset feature without considering the UX of the people who would use this feature.

Thank you for reading. I hope this article has been helpful!

Further Reading On Smashing Magazine

Rethinking Authentication UX

This article is part of our ongoing series on design patterns. It’s also a part of the upcoming 4-weeks live UX training 🍣 and will be in our recently released video course soon.

Authentication is a tricky subject. There are so many terms floating around us, from 2FA to MFA to OTP — and it might be difficult to make sense of what we need and when we need it. But authentication is everywhere, and sometimes it’s extremely frustrating, and sometimes it’s seamless. Let’s explore a few patterns to create experience that are a bit more seamless than frustrating.

Now, nobody wakes up in the morning hoping to finally identify crosswalks and fire hydrants that day. Yet every day, we prompt users through hoops and loops to sign up and log in, to set a complex enough password or recover one, to find a way to restore access to locked accounts and logged-out sessions.

Of course security matters, yet too often, it gets in the way of usability. As Jared Spool said once, “If a product isn’t usable, it’s also not secure.” That’s when people start using private email accounts and put passwords on stick-it-notes because they forget them. As usual, Jared hits the nail on the head here. So what can we do to improve the authentication UX?

1. Don’t Disable Copy-Paste For Passwords

It appears only reasonable to block copy-paste for password input to avoid brute-force attacks. Yet when we do so, we also block users who copy-paste passwords from password managers and text documents. As a result, they need to repeatedly retype complex, lengthy, cryptic strings of text — and it’s rarely an exciting adventure to embark on.

In fact, that’s slow, annoying and frustrating. In her talk on Authentication UX Anti-Patterns, Kelly Robinson explains that this is a common anti-pattern, often causing way more frustration than remedy, and hence best to be avoided.

Also, double check that your password fields include the attribute autocomplete="new-password", so browsers can prompt a strong auto-generated password. And the best bit: users without password managers don’t have to come with a password of their own — because usually that’s a recipe for disaster.

2. Don’t Rely on Passwords Alone

Passwords are problematic. For example, only 34% of users in the US use a password manager, and everybody else relies on their good ol’ memory, sticky notes, and text files on the desktop.

Good passwords are hard to remember. As a result, users often choose easy-to-guess passwords instead, including names of their pets and loved ones, their birthdates, and their wedding dates. That’s far from secure, of course.

Still, we often forget our passwords, sometimes recovering passwords 4-5 times a week. So no wonder many of us still reuse the same password across multiple accounts, often favoring convenience over data safety. In fact, allowing users to choose their own passwords is a recipe for trouble. To fix that, what if we nudge users away from passwords?

Any kind of 2-Factor Authentication is better than passwords, and ideally, we could use a cookie that users can opt-in for to avoid frequent log-ins. Data-sensitive sites might want to log out users automatically after every visit (e..g online banking), but simpler sites might be better off avoiding aggressive log-outs and allowing users to stay logged in for 30 days or even longer.

3. Drop Strict Password Requirements

Since users are very good at twisting and bending password rules (just to forget them shortly after the task is done), what if we change our strategy altogether? What if we do support lengthy and complex passwords with all the special characters unique delimeters but keep rules relatively friendly?

This surely would come at the cost of security, of course. So to protect user’s data on their behalf, we use new-password to prompt secure passwords to be generated during sign-up, and nudge users aggressively towards a 2FA setup, e.g., providing 30% off for the first month for turning 2FA on.

The only thing required would be to connect the account with a mobile phone or Google Authenticator, type in a verification code, or verify with a Touch-ID, and that would be it. Thus, we avoid endless and expensive password resets, which often cause abandonment and frustration.

4. Social Sign-In Isn’t For Everyone

The more sensitive the data stored, the more attention users expect from the interface to security. Usability sessions hint that log-in hurdles seem to be accepted as long as they are considered to be “reasonable”. But what’s reasonable to us, as designers, isn’t necessarily what’s reasonable to our customers.

Social sign-in is a good example of that. Some users love it because it’s so fast, yet others are generally opposed to it due to privacy concerns. Plus, we need to comply with GDPR, CCPA, and similar legislation when using them.

Also, remember that some users forget what they signed up with last time, so it’s a good idea to indicate their previous choice based on their previous log-in (as illustrated above). Essentially, social sign-in is a great option for people who just want to get things done, but it can’t be the only option that we provide.

5. Replace Security Questions With 2FA

In an ideal world, security questions — like the ones we are being asked by a bank on the phone to verify our identity — should help us prevent fraud. Essentially, it’s a second layer of protection, but it performs remarkably poorly both in terms of usability and security. Questions about favorite pets, maiden names, and the first school can easily be discovered by scrolling a Facebook stream long enough.

Knowing that, users sometimes reply to these questions with the very same answer (e.g., their birthday or a location of birth) and sometimes even use the same password that they’ve entered initially. This isn’t really helping anybody. Magic links and push notifications are much more secure, and there is no need to memorize the answers at all.

6. Users Need Options For Access Recovery

Nothing can be more frustrating than being locked out at just the wrong moment. As designers, we can pave deliberate ways out in our interfaces with multiple alternate ways to restore access (access recovery stacks) and avoid these issues for good.

We often think of password recovery to help users restore their access, but perhaps thinking about recovering access is a better perspective to look at the issue. If a user can’t log in at a given moment, they aren’t really interested in defining a brand new secure password, or finding an email or special characters that they haven’t used before. They just need to log in. And we need to help them do just that.

Of all the techniques for access recovery, surely, magic links will be a part of the access recovery stack. Users seem to appreciate just how fast they can get back in once they are locked out. Usually they work flawlessly unless the email doesn’t arrive, or the account is linked to an outdated email, or the email inbox or phone aren’t available.

Still, to use magic links, users need to switch context, jumping from browser to the mail client and then back to the browser. It might have been faster to prompt users to type in a code on their phone to get in instead. One way or the other, to avoid lock-outs, we provide multiple options to guarantee a speedy recovery, and a mix of options works best:

  1. Send a magic link for log-in via email.
    Don’t require users to retype a password, or set a new one. Users might not have access to email, or it could be hacked.

  2. Send a magic link for log-in to a secondary email.
    Unfortunately, the secondary email is often outdated, or the user might have no access to it.

  3. Send an SMS verification URL/code to a mobile phone.
    This option won’t work for users who have purchased a new phone, or don’t have access to their SIM-card (e.g. when travelling abroad).

  4. Send a push notification via OTP/2FA.
    This option won’t work for users who have purchased a new phone and haven’t set up OTP/2FA just yet, or don’t have access to their old phone.

  5. Biometric authentication via a dedicated app/Yubikey.
    This option won’t work for users who don’t have an OTP/2FA setup yet, or have purchased a new phone/Yubikey.

  6. Type backup recovery codes.
    Not every user will have backup recovery codes nearby, but if they do, they should always override account lock-out. Sometimes backup recovery codes are sent via a postal service, but they could be lost/stolen.

  7. Phone call verification.
    Users could be called on their (new) phone, and they’d need to answer a few questions to verify their idemtity. Ideally, it would be something that they know (e.g. latest transactions), something that they have (e.g. credit card) and something that they are (e.g. face recognition via a video call).

  8. Customer support inquiry.
    Ideally, users could restore access by speaking to an agent via live chat, WhatsApp/Telegram, video call or email (which is usually the slowest).

It’s not a good idea to send randomly generated passwords via email and require a new password setup when a user finally manages to log in. That’s not secure, and it’s always a hassle. Instead, yet again, nudge users towards a 2FA setup, so they can recover access by accessing a code from the app installed on their phone or SMS (which is less secure, however.)

Wrapping Up

Authentication is always a hurdle. Yet when the interface is difficult to deal with, users become remarkably creative in bending the rules to make it work and forget the password the moment they complete a transaction.

Perhaps we should give our users at least a chance to get to know our website or app before creating too many barriers for them. Ideally, we need a 2FA setup for everyone, but we need to get there first. And a path there is paved with a seamless, good authentication UX — without complicated rules and restrictions, and preferably the one that users won’t even notice.

Meet “Smart Interface Design Patterns”

If you are interested in similar insights around UX, take a look at Smart Interface Design Patterns, our shiny new 7h-video course with 100s of practical examples from real-life projects. Plenty of design patterns and guidelines on everything from accordions and dropdowns to complex tables and intricate web forms — with 5 new segments added every year. Just sayin’! Check a free preview.

Meet Smart Interface Design Patterns, our new video course on interface design & UX.

100 design patterns & real-life examples.
7h-video course + live UX training. Free preview.

Useful Resources

Related Articles

If you find this article useful, here’s an overview of similar articles we’ve published over the years — and a few more are coming your way.

Resolving Conflicts Between Designers And Engineers

In software development, UX designers and software engineers can get locked in verbal combat, which feels like a chess game of debate and wordplay. I’ve been there too many times and have the battle scars to prove it. If there has been anything I’ve learned from conflicts in the software development process, it’s that it’s not exclusively a cultural phenomenon, and obviously, it’s not productive.

The people involved in the conflicts generally react to a negative state of the world that no one wishes to be in. Sometimes it says more about a particular culture than us as individuals. Regardless of the reason, it’s not a good state for the organization or company to be in and will rob you of productivity, team cohesion, and focus on delivering customer value. Every company and department has its own challenges. In this article, we will go over some areas where you might find the challenges manifesting, what some of the contributing factors are, and strategies to work through the challenges.

I used to see the conflict between design and engineering in the software development process as annoying and an impediment to software design. When I began to see patterns in people and organizations involved in the conflicts mentioned above, I started to lean into the conflicts and see them more as an opportunity. I want to highlight some common contributing factors to design and engineering conflicts and lay out some strategies to work through them.

While engineers hold the keys to feasibility and how the technology works, designers hold the keys to the customer/market need and principles toward a delightful user experience.

If the two sides (design and engineering) don’t come together in perfect harmony, it could result in a functional feature that customers don’t enjoy or a good experience that’s not efficient and/or expensive to build. It’s not an either-or but an “and.” The design and the tech have to come together in harmony to balance the feasibility with aspects of a delightful experience.

I have found that, often, it’s easier for an engineer to see the aspects of a good user experience than for a designer to understand the technical aspects of how something functions, let alone how feasible it is. Regardless, the two sides work best when both lower their guards and reach across the aisle. Only then are your teams truly committed to delivering a great customer experience.

Assessing The Chasms

There can be several contributors to the aforementioned dissension. From an organizational structure standpoint, contributors to the chasm could be boiled down to the following categories: culture, teams, roles, and individuals.

A review of the literature in saylor.org’s course lays these categories out in a bit more detail, and they note that “sometimes the structure of the organization itself can directly lead to conflict” whether that be based on the organizational structure or the authority provided within the structure.

I’ve seen these categories manifested in several ways. You may be able to relate to some of them. Let’s discuss them below.

Culture

People do what they get rewarded for. If your organization incentivizes teams based on productivity, they will get good at cranking out widgets. Even if those widgets fall short of the customer expectations, the teams will become good at delivering what you asked for. Their focus becomes output over outcomes. This can cause teams to cut corners and produce “good-enough” solutions that miss the mark once released to customers. This is largely driven by the culture within the organization and can permeate the management hierarchy.

Teams

Similar to what I mentioned regarding culture, a team, while aligned with the larger culture, typically has a team sub-culture. Sometimes a team culture can be seemingly at odds with the corporate culture. For example, a corporate culture that is collaborative and open can have teams that are hyper-focused on metrics and productivity that misconstrue the intent of the culture to meet productivity metrics. This is generally done to reduce uncertainty. I’ve worked with teams that became so hyper-focused on themselves that sizing a single user story practically took up an entire meeting.

Roles

Staying in our lanes as designers and engineers. Personally, I couldn’t be more opposed to people staying in their lanes. I recognize that designers and engineers fulfill specific business needs, but we should be a unified body when it comes down to delivering outcomes. Engineers should have opinions on design, and designers should have opinions on the applied technical solution. The cross-pollination of views should support one another, which almost always leads to a better outcome.

Individuals

I can be a contributor or a hindrance. I can become so focused on myself and my desires that I close myself off to others’ views. Rather than focusing on the outcome and the team, my views are forced on others, including the customer. I have seen this causes engineers to be entirely focused on output, “Just tell me what you want from me,” rather than collaborating on the outcome.

United We Stand Or Divided We Fall

Let me provide a few examples from my experience. I worked at one company where I tried several experiments to work more effectively with engineering. At a certain point, a prevailing schism was entrenched and a rather strong engineering-focused culture of “let us build it, get out of the way, and we’ll let you know what we need.” This tension had created an “us vs. them” mentality.

For this same company, I was brainstorming with a team for an upcoming project. As we started to get into sketching, I was met with blank stares followed by a litany of technical constraints. It was awkward, to say the least. Reflecting on it, I don’t think it went well because there wasn’t Product Owner buy-in, nor the proper context was set. I realized from that experience that when we are entrenched in a particular culture/team mindset focused on output for an extended period of time, it can be poisonous and entrench not only our behavior but also our mindset.

Last but not least, while working at a different company, I noticed a middle management cultural problem. The senior leadership spoke about collaboration, great design, and high quality. The agile teams executing on work agreed with this philosophy and were trying to work towards the leadership vision. However, middle management was making decisions that conflicted with senior leadership. The engineering manager would tell engineers to build things that completely excluded design. When designers tried to engage in the process, the engineers were just following orders. There were engineering building and shipping things with little to no Product Management or UX Design input, which showed in the product.

For an organization to be successful, they need to be united. We need to balance our thought processes and cross-pollinate our skills for our organizations to thrive.

It is wise to give the organization and teams the benefit of the doubt. Too often, we’re all just caught in the middle of what appears to be dysfunction. That dysfunction can be an opportunity for change if we learn to navigate the distraction that leads to conflicts.

Distractions

Several studies have dug into this problem space of conflicts with teams, specifically UX designers and software engineers. A 2002 study by Dejana Tomasevic and Tea Pavicevic found that “tasks conflicts are the most common type of conflict. A 2019 study by Marissa Wilson also found that “100% of conflicts reported were task conflicts”.

After being in the trenches for a while, I’m not surprised by these studies, so I’d like to add some color to the study findings directly from the trenches. From my experience, most of the barriers to engineering and design collaboration are simply distractions. Although cultural issues can be barriers to collaboration, if people really want to bring about a positive change, they will find a way.

Let’s review some distractions that you’ll likely need to overcome:

  • Timing
    Designers generally build up ideas (induction) while engineers break them down (deduction) to chunk out building the solution. While there is time to build up ideas and time to break down work, getting the timing right for either of these is important to avoid conflicts. Too often, we’re trying to build up ideas, and our partners are trying to break down the work.
  • Miscommunications
    Designers and engineers have different skill sets and backgrounds. As a result, both groups come from different perspectives, speak different languages, and use different terms. This can lead to tremendous frustration, as Ari Joury points out in his article on designer and developer clashes.
  • Mis-alignments
    If you don’t have the same frame of reference, you will have disagreements. It might be impossible to share every detail at every moment with everyone on the team, but there must be a shared understanding of the problem and the value the team is targeting. Misalignments can cause teams to pull in different directions.
  • Role factions
    Sometimes teams get too focused on who’s responsible/owns what part of the solution. In a truly collaborative environment, the team owns the solution they’re working toward. Designers should get comfortable leaning into the engineering space, even if it’s to learn more about it. Same for engineers, lean into the design space and learn.
  • Metrics
    Metrics help teams to be more focused on the outcome. They also help us be more incremental in our approach. You definitely want a healthy balance here because metrics on value delivery vs. metrics on team productivity can sometimes feel at odds. This can lead teams to focus on getting all the details right, which robs time away from delivering an outcome. Winston Churchill once said, “perfection is the enemy of progress.”

Though the list above is not exhaustive, there have been common themes in the various companies and teams I’ve worked with. The teams you work with within your company may be experiencing one or multiple of these distractions. Hopefully, not all of them! Regardless, designers and engineers will have conflicts if they work together. It’s our job as business partners to lean into them and work through them for teams to be successful.

Striving For Unity

I think it’s crucial to understand that trust has to be the cornerstone of any team unity. In an article by Built In in 2021, they provide a variety of examples for uniting teams. In it, Jillian Priese, Engineering Manager at Granular tells us that for her teams, “When trust is present, it makes all the difference in the world.” And that without trust, it’s “easy for engineers and designers to question one another’s motivations and abilities.” Whatever the barrier, we must employ strategies to close the gaps and bring unity to the team.

Here are some tips that I’ve found to be effective:

  • Discover together.
    While the design team is in the discovery phase of a project, make a point to include the engineers. In the research stage, they can be observers while hearing from actual users of their code. Don’t forget to include them in the ideation process as well. Give them room to fall in love with the problem space. As you discover, iterate, and refine, pull in engineers to get their input, particularly in areas where you want special interactions to take place. They can help you balance the approach to provide more value and be more feasible.
  • Be curious.
    Try not to assume too much and be prepared to learn. Designers have a lot to learn from engineers, and engineers can learn a lot from designers. Cross-pollination of skills strengthens teams. You don’t have to be a designer or engineer, but you should spend some time learning a little about your partner’s role and their work. Exercise empathy and keep each other honest.
  • Speak their language.
    As Ari Joury notes in his article, designers and engineers speak different languages. Designers and engineers sometimes assume they’re speaking the same language and using the same terms only to find that when the wires get crossed, they are talking about different things. Sometimes you will learn to slow down for clarity and shared understanding. Engineers need to be willing to patiently translate foreign technology to designers. Designers need to be ready to patiently sketch and use visuals to translate concepts to engineers sometimes.
  • Be together.
    I literally mean that you sit with each other when you can. As a designer, I have learned a lot from sitting with or in near proximity to engineers about their work, each of them individually, about myself, and the need to modify my work behavior to be a better partner. If you happen to be remote, make a team commitment to be available whenever needed, and be sure you follow through on that commitment to help build trust.

It’s really powerful and rewarding when engineers are more aligned with UX designers because they can elevate good designs to be great designs when they’re fully engaged. I like to believe that engineers breathe life into UX designs through the power of technology.

Practical Examples

As noted above, no company is the same, and different tactics should be used depending on your team’s challenges. Here are some practical examples of how I have put the tips above into practice.

Growing By Learning

At one organization, I came in as the lone designer being dropped into an existing team. It was awkward because the culture had generally been tech-centric. I was the outsider and struggled to make headway. Over time, I realized that the team was open to more design collaboration but was a bit new to working with a designer. The team was in another country, so I petitioned to spend a few days working with them.

Part of my plan was to focus on our epic, which has a lot of frontend work; the other part of applying some design exercises. Since the team was new to design thinking, we did a lateral thinking exercise and UI pattern workshop. After that, things began to gel with us. The team became more user aware and empathetic, and the team started to come to me with UI defects and great ideas for solutions. I enjoyed working with that team.

Make Yourself Available

At another smaller organization, the UX team was positioned with the Product Management (PM) department. The PM and Engineering departments were located on separate floors in the same building. It didn’t take long to realize that the barriers to collaboration while manifesting in several ways, were rooted in physical separation.

To start working to resolve this, I set up shop in the engineering space a few times per week. A sort of “UX Help Deck,” if you will. At first, I think they thought it was weird, but eventually, people began to open up. It facilitated many opportunities to better understand the team’s needs, educate them on the users’ needs, learn about their tech stack, and find in-roads with Product Owners and Engineering Managers. Fortunately, much of the engineering team appreciated it. So, we built great relationships and made a lot of progress in a short amount of time.

Playing To Their Tune

At a much larger organization, I worked against a heavily entrenched engineering-centric culture. I made quite a few mistakes in that environment, such as not seeking more clarity on the authority of roles for the project, not pursuing more clarity in the project direction and priorities, and pushing back more against unreasonable hot-headed stakeholders.

I gained a lot of patience working with architects that had little experience working with UX designers. We were speaking different languages at different levels about different needs. They had a ton of domain knowledge from years of experience. So, they would pull these obscure edge cases out of thin air in conversations as a sort of trump card to any reasonable design recommendation. It was frustrating and humbling. To them, UX was all about “looking pretty” (the visceral aspects of the user interface). Sigh.

From my end, they saw UX as the lipstick they could just apply to the pigs they wanted to build. The in-road there was playing to their mindset. The architects fundamentally wanted to build a system that was robust, scalable, and easy to maintain quickly. The system being user-centered was the least important in their mind, and even that was generally boiled down to “looking nice,” which is not user-centered.

However, I believed we could build user-centered solutions and teach them along the way, but I had to think more modular and scalable. We needed to establish a frontend framework quickly and lay down some foundational guidelines we could build upon. We used that as building blocks that engineering could buy into. That helped them see UX as an ally to their goals rather than an adversary. We created a design system that helped us focus on user needs yet efficiently design at scale. While we got buy-in pretty quickly with engineers, we eventually began to see traction with the architects as the slow, grueling process slugged on.

Conclusion

Finding the impediments that are preventing the unification of the clan is important. It’s essential for your organization, your customers, and your sanity. It does entail effort but is well worth it. Experiment with your teams to find what works for them. The same strategy might not work for every team. When you meet resistance, don’t pull away, but lean into it and be patient.

As a reminder of the things we covered:

  • Assess the level at which you’re finding the biggest chasms;
  • Identify the distractions you’re seeing in your teams and what might be contributing to them;
  • Take action and experiment with different tactics to establish unity.

Challenge the status quo when appropriate. You may ruffle some feathers at first, but sometimes disruption is needed to get to a better state.

You may not make friends at first, but you will get respect. You may find that thirty percent of the people are on board with you. Another thirty percent are interested but not yet sold. The remaining percent of nay-sayers who want to continue with the status quo will eventually come along as the rest of the clan unites around them. Fight the good fight, my friends, and unite the clans!

Further Reading on Smashing Magazine

UI Interactions & Animations Roundup #25

University Website Faculty Page

by tubik UX

ui Animation Anzo Clothing – Landing Page

by ©mAnOff

Aesthetica Magazine

by Evgeny UPROCK

Quiosque Lisboa

by Ruslan Siiz

GUUULP! Landing Hero Animation

by Margaret Lunina

Plain – swapping interaction

by thrc.eth

Scroll video

by Slava Kornilov

Annalisa – Web Design

by QClay✌

skye // /

by Andrew Baygulov

XPeng Motors

by Evgeny UPROCK

Apartment Booking Website

by Dmitry Lauretsky

Anime // E-Commerce

by blacklead studio

Travel Istanbul city Icons

by Musemind Branding

Resonance exploration animation

by Resonance Studio

Le Labo Another 13/ Product landing page

by Tien Anh Dang

NFT Space // Website

by blacklead studio

Re←Born – website concept

by Vice Rukavina

Cuberto Development Dept

by Cuberto

Landing Skyrent

by Desire Creative Agency

Temple – The future of Web3 Creator Economy

by thrc.eth

Seagulls 22

by Elegant Seagulls

The post UI Interactions & Animations Roundup #25 appeared first on Codrops.

Boosting UX With Design KPIs

Imagine that you’ve just received an invite to a new meeting. The description is a bit vague, but the title is sitting right there, with its heavy weight, making you a bit worried: design KPIs. Now, what do you think the meeting is going to be about?

It wouldn’t be surprising to hear about conversion rates, new A/B testing results and bounce rates; perhaps exit pages and SERPs and funnel drops. We might expect data from Google Analytics, and perhaps a report about generated leads.

What we expect to see are data points scattered across charts. Each of the data points represents a unique experience, and when put together, they represent an average behavior in our products. The average user doesn’t exist, of course, but the data helps us identify trends and changes over time. These trends are indeed valuable insights. But they also are only one part of the full story.

Hidden Costs

Over the decades, we’ve become remarkably good in digital design. We’ve learned how to craft truly beautiful interfaces and well-orchestrated interactions. And we’ve also learned how to encourage action to meet project’s requirements and drive business metrics. In fact, we can make pretty much anything work really.

For example, in the mock-up above, the option "Add to basket" is beautifully highlighted in green, indicating a way forward, with insurance added in automatically. That’s a clear dark pattern, of course. The design, however, is likely to drive business KPIs, i.e. increase a spend per customer. But it will also generate a wrong purchase. The implications of it for businesses might be severe and irreversible — with plenty of complaints, customer support inquiries and high costs of processing returns.

Many organizations focus on a few selected business metrics, mostly leads and conversion; yet they don’t have a holistic overview of all key metrics that have an impact on the entire business. In fact, as Paul Boag explains in his recent book, there are plenty of hidden costs that often stay in the shadows of business KPIs. This usually leads to short-term improvements with expensive long-term implications.

A healthy business metrics mix usually includes KPIs that go a bit beyond data from Google Analytics. We also need to consider life-time value, time to first purchase, time to upgrade, loss in processing returns, cost of support, sales, marketing, customer acquisition and ratio of negative reviews, to name a few. That’s also where another significant set of metrics comes into play — design KPIs.

Design KPIs

How can we speak objectively about a particular design? It appears to be such a subjective thing, with plenty of personal opinions and individual experiences that flow into every individual design process. Yet ultimately design solves problems, and we surely should be able to measure how well a particular problem is being solved.

In fact, just like we define performance KPIs or business KPIs, we can also establish design KPIs and track their performance over time. Design KPIs are key attributes that capture customers’ experiences for top tasks that users frequently perform in a product.

Recently I’ve started setting up dashboards of design KPIs in organizations that I work with. Together, we decide on key attributes that are important to provide a better UX, and then we track them repeatedly over time, very much like we would track other metrics in the organization.

One thing that I learned quickly is that these metrics can’t exist in isolation; they need to be connected with the business goals, e.g. describe the accuracy of submitted data, or the quality of leads, or error recovery rate. While organizations often focus on end goals alone (leads, for example), we try to discover all key attributes that contribute to reaching these end goals. These, in fact, are design KPIs.

There are, as it turns out, plenty of helpful design KPIs, but these are the ones that usually deserve special attention:

  • top tasks completion rates,
  • top tasks completion times,
  • accuracy of data submitted by users,
  • ratio of content vs. navigation (mobile/desktop),
  • error frequency,
  • error recovery rate (= quality of error messages),
  • quality of leads,
  • time to publish,
  • time to release,
  • time to first purchase,
  • time to upgrade,
  • conversion rate,
  • carbon footprint impact,
  • System Usability Scale Score (ideally over 75),
  • accessibility score,
  • web performance score.

Obviously every organization will have their own set of design KPIs. To establish them, we need to understand what attributes have an impact on business goals. One strategy that seemed to be working for me is to explore the pain points and slowdowns that the organization is aware of. This usually requires a few rounds of interviews, starting from customer support and service desk to design and engineering teams.

The metrics listed above are much more focused around the actual user experience and user behavior, rather than ambiguous data points in analytics that represent an average behavior. Of course, we also need to keep track on these KPIs as time evolves. And this requires measurements.

Measuring Design KPIs

Once we have defined the KPIs, how do we measure them? We can rely on Gerry McGovern’s Top Tasks approach and identify the most frequent tasks that users complete in a product. We conduct research to discover the most important tasks. We study search queries and server logs, run user interviews and workshops with stakeholders.

Once we have that list, we bring users in to vote on the tasks that they consider to be important for them. Then we write down task instructions for each top task. These instructions will be handed to users in usability tests to validate that they can actually complete these tasks successfully. Usually, you might not need more than 20-30 people to participate in each test.

Finally, we run tests with the same task instructions to the same segments of users, repeatedly, every 8–12 weeks. Based on these tests, we measure and plot success rates and completion times over time. As long as we improve our design KPIs, we should be on the right path. And we have data to prove it!

Design KPIs help us stay on track in driving metrics that actually matter. With them, we can gradually improve UX over time and gain evidence that our design decisions are actually effective in practice.

Wrapping Up

It’s worth noting that the definition of design KPIs should have a significant impact on how the quality of work is measured. Rather than focusing on the amount of produced pages or websites, bounce rates or click rates alone, we should be aligned towards producing quality content that is useful for people consuming that content.

Next time you are working on a project, consider establishing design KPIs alongside business KPIs and create a more holistic and healthy mix of metrics that capture user experience and business goals. In the end, both sides will only benefit from it, with a sustainable and effective strategy that keeps users and business stakeholders happy.

One More Thing

If you are interested in similar insights around UX, take a look at Smart Interface Design Patterns, a 6h-video course on UX and interface design, from accordions and dropdowns to complex tables and intricate web forms. Check a free preview.

Meet Smart Interface Design Patterns, our new video course on interface design & UX.

100 design patterns & real-life examples.
6h-video course + live UX training. Free preview.

Preventing Bad UX Through Integrated Design Workflows

Let’s take a moment to think about the time you’ve spent navigating intranets, password resets, project management software, or government websites. How many moments of technological frustration can you add up in the last few days when you think about them? Some of these websites and platforms are too important to avoid — they enable us to fulfill fundamental human transactions and operations. In today’s world, it’s become common to feel our energy is depleted by this steady stream of digital experiences.

Given our increasing dependency on digital interactions, advocating for good UX will become increasingly necessary, as our reliance on digital tools continues to grow. A new canvassing of experts in technology, communications, and social change by Pew Research Center presents a universal view that “people’s relationship with technology will deepen as larger segments of the population come to rely more on digital connections for work, education, health care, daily commercial transactions and essential social interactions.” As this shift toward what is dubbed a tele-everything world continues to unfold, the people who work in tech hold an incredible responsibility to ensure that their creations make life simpler, not more stressful or more time-consuming.

As a designer, I feel a sense of responsibility to dig deeper into why it’s so uncommon to encounter digital tools that are straight-up simple, empathetic, and helpful. In this article, we will explore the causes, as I’ve seen in my practice, look at the effects this can have on the team, and finally propose some actionable solutions that don’t just say: convince people to increase the budget.

Common Sources Of Bad UX In Your Product

If good UX has been a hot topic in the industry for years, then why is bad UX still so common? The easy answer points toward product designers and developers as individuals who create the UX itself. However, if you believe that, then your bad UX problem will persist despite hiring the most competitive talent on the job market.

Based on my experiences as a UX Designer and Design Manager, here are the top four underlying reasons why your tech product might be experiencing Bad UX:

1. Under-Resourced Dev Teams For The Size Of A Company’s Goals

These conditions place the team in a ‘starvation mode’ where delivering anything on time is already difficult enough; the steps required for quality UX are extremely difficult to prioritize. The issue here is that company leadership views Good UX as luxurious (which is quite hilarious, because UX is often a key differentiator in the most competitive products out there), even as a hindrance to velocity (which is equally hilarious, because of the disastrous impact Bad UX can have on velocity in the long run, but whatever, leadership).

“I encounter under-resourced dev teams constantly, and it’s disheartening every time. Usually, quality is the first thing to go, even though most professionals know it should be scope. Decision-makers in these contexts have a very hard time imagining scoping down, so they consistently push the team to move faster instead.”

— Aidan Gordon, Technology Lead

2. Under-Resourced Design Teams For The Number Of Developers

A recent survey of 377 professionals by Nielsen Norman Group revealed that about a third of designers are outnumbered by at least 10 developers. Imagine the pressure on designers when there’s such a skewed ratio like this. They need to pump out screens and logic for devs (short for developers) to work on every week. The team’s production velocity is wrongly measured by its dev power, and because the design bottleneck is so strong, devs have to wing it and just kind of ‘figure out’ UX independently. Thoughtful user testing falls by the wayside, as designers’ workloads are unmanageable.

3. Misunderstanding “Agile” As “As Fast As Possible”

Agile workflow tactics gained popularity without paying enough attention to the underlying rituals that enable them to be successful. According to Atlassian (the creators of Jira) and Confluence)), Agile calls for “collaborative cross-functional teams, open communication, collaboration, adaptation, and trust amongst team members.” Each and every one of those key aspects are easily deprioritized when a team’s strategic goals force them to operate in starvation mode in the first place. Agile, as it was designed, recognizes that good UX is the result of navigating continuous dependencies between all branches of the product team. In other words, Good UX requires a lot of back and forth, which is a kind of collaborative and communicative mode that immediately falls to the wayside when we are in a rush.

“I’ve observed companies that aren’t committed to an iterative mindset and process, but use “Agile” as a bandaid for quicker releases. Sometimes, there’s a fear coming from leadership that we might never return to fix something, or a fear that we won’t be able to sell version 1 without a fully functional feature X. Unless the whole company embraces iterations, the product team will either struggle to release quickly, or to release quality… the concern is if we release a v1 with less than perfect scope we will never go back to fixing it.”

— Jill Hesse, Director at Genomics Data Management

4. Misunderstanding The Meaning And Purpose Of UX

Often, when I’ve been hired to work for teams, I have observed that the main issue was simply a mild and widespread confusion about what User Experience really is, both in the tech crew and the business crew. Misunderstanding the purpose of UX is akin to misunderstanding its value. If this happens on the business side of the company, then the product team will likely be under-resourced in the design department. If this misunderstanding happens on the product team level (perhaps due to a lack of designers in strategically influential positions, or lack of designers altogether), UX winds up being disregarded or thought of as just UI, which is to say: “something that can be added later.”

This summary is meant to offer a view of the operational and cultural forces that bring about UX failures. If you’re a leader in tech, I hope you draw the essential link between the happiness of your product team, the quality of the User Experience, and your business’ revenues. Your product team knows what conditions they need in place for them to produce a high-quality UX. They have some of the answers to your Bad UX problem, and they might be a heck of a lot simpler than you think.

The Impact Of Bad UX On Your Team And Company

In organizational psychology and modern ways of viewing work, like Officevibe’s Employee Engagement Guide, there’s often a theme that comes up: happier employees make more productive employees/better work. I’d add users into this cycle somewhere because creating excellent experiences creates a virtuous cycle into revenue and solidifies the meaning we find in contributing positively to others.

On the flip side, when bad UX has lingered in a product for so long, it can feel like a mountain to overcome, and it grinds down the talented and passionate humans on your team.

The effect can play out on teams in a few ways I’ve seen in real life:

  • Long-term ‘UX bugs’ harm team morale.
    Over time, the glaring UX issues product can force a continuation of being caught between a rock and a hard place, where a revamp is increasingly needed, but would require more and more resources. In this kind of scenario, you might see designers regularly churning out band-aid features instead of creating elegant solutions. The team can still produce new, innovative features, but more slowly and with more mental (dare I say emotional) labor than is necessary. It basically just gets harder and harder to create stuff that you could be proud of. It can get demoralizing over time.
  • Lack of opportunities to create Good UX wears down confidence.
    As a designer (or other people on a product team), your job, your portfolio, your sense of credibility in the space, sense of confidence — and I’ll even go as far as saying your self-worth — are directly affected by the impact you feel from your work. You know you are talented, interested and capable enough to produce great things, but anyone caught in a Bad UX situation for a long time will see those joyful and creative feelings start to dim.
“As a designer, working in a user-driven product culture is so important for your own satisfaction. If you’re working within a company or team with a weak UX culture, you can get stuck meeting one or a few people’s biased preferences instead of hundreds or thousands of users’ real needs. You know you’re letting users down. In some cases, you’re even adding more friction and frustration into someone’s life… Over time, your confidence in the quality of your designs diminishes, and, eventually, so does your overall engagement at work.”

— Erica Gregor, Head of Design & Product at Penrose Partners
  • Bad UX hinders a team’s growth and strategic value.
    When Bad UX pervades in such a way that it causes your team to lose time or motivation, under-delivery becomes the norm. It starts to seem like, from the outside lens, that your team isn’t relevant or competent. When it’s hard for a team to demonstrate its strategic/business value, investment in the team’s growth can slow down, and they don’t get to benefit from the innovation power of a more diverse range of skills and talents.
Solutions For Preventing Bad UX

The discussions I’ve had in the industry about the causes of Bad UX always revolve around too little time or resources to achieve the elegant and empathetic design-dev workflow proposed by experts in Agile, Design Thinking, etc. But notice the irony of some of the biggest, most funded teams still producing Bad UX. Have you ever tried joining a Microsoft Teams call as a ‘free’ user? Not only is more time and resources a false solution to Bad UX, the very focus on “more resources as the solution to Bad UX” makes Good UX seem like a privilege that only the most funded projects can access.

“I am not sure if I have got stuck in Groundhog Day, or have become the center of the universe. I try to log in… It says I am not on Teams yet, and asks me to “Sign up.” I am taken to the Teams home page, where I click on “Sign up for free.” It says, I already have an account setup... So I click on “Sign in.” Now it asks me to open the app... And then it says that I am not on Teams…”

— Sumit Anantwar, on being stuck in a login loop on Microsoft Teams

Enterprise Case: How Design-Dev Collaboration Identified A Dealbreaking Project Barrier

We were tasked with redesigning a command-line tool for an enterprise product that required the download and upload of an XML file. The weakest point in the tool was the lack of guidance and feedback people received as they used the tool. When we showed the wireframes with new error messages and guidance to the developers, they revealed to us that the tool already had problems parsing errors in the right order because of the nature of the XML file and the underlying database.

Once everyone realized that the main purpose of the redesign would be impossible to fulfill within the scope of work, we decided to scrap the project until we could fix things properly.

Biotech Case: How Design-Dev Collaboration Maintains A Healthy Project Scope

We were designing a custom field configuration interaction and had designed a lot of cases as we went. Users of this biotech platform could create their own: number field, text field, multiline text field, radio button dropdown, toggles, and so on.

Thankfully, we had two developers review the design team’s wireframes and logic early on. One dev pointed out way more logic that needed to be defined because this scientific software had requirements that were buried deep in the code like the number of decimals to show, the maximum possible value, etc. This prevented a major scope creep during implementation and prevented users from being blocked at migration time.

Hopefully, these examples allow you to imagine just a small glimpse into the potential that these workflow improvements and collaborative culture can generate.

Conclusion

Our work in the tech industry can feel like a grind at times: fast deadlines, rushing, redoing work you’ve already done, and pushing sub-par final implementation out the door. This, in part, is because a company’s strategy or a team’s workflows don’t help catch complexity early enough, so devs and designers have to respond by patching in weird UX solutions just to get a thing out the door.

Here’s a recap of some actionable steps that are sure to improve the UX culture in your team:

As a product leader:

  • Open a discussion with your team: What needs to be true in order to deliver higher quality user experiences? This question should help you notice frictions in their team structure and their workflows.
  • Offer the whole team (including developers, researchers, managers, and quality analysts) a learning experience about UX like this introductory course. Celebrate the end of the course (and put it into practice) together by designing and implementing a new feature.
  • Same goes for working in Agile: get everyone on the same page through a common learning experience like through this book and put it into practice together through a shared project.
  • Implement new, quick rituals that gather your whole team during the design process, especially in its early and messier stages. Your developers, managers, and QA people might feel out of place at first, but that’s only because the world has taught them to feel that way. This simple exposure to design will grow to influence what they care about in their work and eventually shift everyone’s sense of responsibility for good user experiences.

As a product team member, do what’s in your power about the recommendations above:

  • As a designer, invite a developer to a 30-minute meeting showing them a new feature you’re conceptualizing or some fresh research insights you are working with.
  • As any team member, host a discussion with your team about how you might deliver higher quality design without needing new resources. Test it out and share your learnings with your Manager.
  • As a developer, get a sense of some tactical UX/UI basics with this course and try using some of the principles next time you work on a feature, note the most seamless pieces you implemented and share with your team.

All in all, we want all levels of a company and all members of a product team working with the same definition and values around UX. In companies where there’s shared responsibility for the quality of a product, collaboration flows organically and frequently. This constant meeting of perspectives and skills is our way forward if we want to honor the idea that tech should help people save time and effort in as many ways as possible.

Resources

How To Use Storytelling In UX

As human beings, we love stories. And stories come in all shapes and sizes. Children love fairy tales; teenagers ask “and then what happened?” when their friends recount gossip; history buffs explore biographies for insight into famous personalities; science lovers enjoy documentaries that offer explanations of the world around us; and everyone likes a satisfying conclusion to a good workplace drama or romantic exploit — be it fiction or fact.

We tell stories in our day-to-day lives. In fact, according to Scientific American, 65% of the conversation is stories! They’re in commercials to grab attention, in nonfiction books to make learning more personal, and in meetings — think of how storyboards help sell management on new product features. Magazines and news shows also tell stories rather than simply listing facts to make readers and viewers care about the information.

This is why, to quote Conversion Rate Experts on websites:

“You cannot have a page that’s too long — only one that’s too boring.”

We use storytelling skills to create positive user experiences as well, though it looks a little different when a story is a part of a product. Learning how to tell a good story with a digital experience will help people care about and engage more deeply with the experience. What’s more, using the same concepts that help create a good story will help you build a better product. A good story will influence marketing material, create a product that fits into the user journey, and highlight the opportunities that need more descriptive content or a more emotional connection to the end-user.

In this article, we’ll go over five steps to building a good experience using the steps an author uses. For consistency’s sake, we’ll also look at a single product to see how their choices can be evaluated through the five steps. I’ve chosen Sanofi’s Rheumatoid Arthritis Digital Companion, an app I helped to build in 2017. This product is a beneficial example to follow because it followed best-in-class storytelling practices, and also because it is no longer available in the app store, so we can look at it at a moment in time.

But before we get into any of that... why does storytelling work?

Why Does Storytelling Work?

In “Thinking, Fast and Slow” (Ch. 4, The Associative Machine), psychologist Daniel Kahneman explains how our brains make sense of information:

[…] look at the following words:

Bananas Vomit

[…] There was no particular reason to do so, but your mind automatically assumed a temporal sequence and a causal connection between the words bananas and vomit forming a sketchy scenario in which bananas caused the sickness. As a result, you experience a temporary aversion to bananas (don’t worry, it will pass).

Kahneman refers to the mind “assum[ing] a temporal sequence and a causal connection” between words. Put another way, even when there is no story, the human brain makes sense of information in two ways:

  • Temporal Sequence
    Assuming things happen linearly, or one after another.
  • Causal Connection
    When one thing causes another to happen.

Hubspot’s “Ultimate Guide to Storytelling” says the same thing as Kahneman, in a more readable way:

“Stories solidify abstract concepts and simplify complex messages.”

Our brains are built to find and understand stories. Therefore, it’s no wonder that a story can improve UX. UX is all about connecting an experience to a person’s mental model.

Learning how to tell a good story with a digital experience will help people care about and engage more deeply with the experience.

But writing a story is easier said than done. A story is more than just a list of things. It requires the “causal connection” that Kahneman referenced, and it must be emotionally charged in some way. Let’s review five steps that authors use which will also help you build a story into your user experience:

  1. Choose your genre;
  2. Create context;
  3. Follow the hero’s journey;
  4. Revise, revise, revise;
  5. Write the sequel.
Step 1: Choose Your Genre

Let’s forget about UX and digital products for a moment. Just think about your favorite story. Is it a murder mystery? Is it a sitcom? A romantic comedy? It’s probably not a murdery-mystery-romantic-comedy-sitcom-movie-newspaper-article. That’s because stories have genres.

Before beginning work on a product, it’s important to identify the genre. But where an author calls it a genre, in UX we might call it a “niche” or a “use case”. This is different from an industry — it’s not enough to be creating something “for healthcare” or “for finances.” Your product “genre” is the space in which it exists and can make a difference for the target audience.

One way to determine your product’s genres is to create an elevator pitch. The team at Asana suggests that the core of an elevator pitch is the problem, solution, and value proposition.

Another way to find the “genre” of your product is to fill in the blanks:

“We want to be the _____ of __________.”

Next, write a sentence or two explaining what that means to you. The key is specificity: the second blank should specifically describe what your organization does. This is your genre.

Here’s an example:

“We want to be the Amazon of find-a-doctor apps. That means we want to be known for offering personalized recommendations.” or “We want to be the Patagonia of ticket sales. We want people to know us for not only what we sell, but the ways that we care for the environment and the world.”

When my UX team worked on Sanofi’s Rheumatoid Arthritis (RA) Digital Companion, we took this approach to identify what features to include, and what a “digital companion” should do for someone with RA. We knew our audience needed a simple way to manage their RA symptoms, track their medication, and exercise their joints. But they also needed to feel supported.

Thus, the genre needed to reinforce that mentality. Internally, our UX team chose to focus on being “the Mary Poppins of medication adherence apps. That means we anticipate what the patient needs, we’re generally cheerful (though, not cheesy), and we focus on what works — not what’s expected.”

Step 2: Create Context

Step two is to add context to the experience. Context is everything that surrounds us. When I use an app I use it differently if I’m sitting at home giving it my full attention than if I’m at the grocery store. The noise, the visual stimuli, and the reason I’m logging in are all context. A UX designer also creates visual context by including headers at the top of screens or breadcrumbs to show someone on a website where they are in the grand scheme of things.

In Lisa Cron’s book Story Genius, she has a section called “What Kindergarten Got (And Still Gets) Very Very Wrong.” In it, Cron explains that too many people mistake a list of things that happen for an actual story. The difference is this idea of context: a good story is not just a sentence, but a descriptive sentence: the descriptors add the context.

To give a product context, it needs to be developed with an understanding of what the background of the audience is and the context in which they’ll be using the product. For UX, some of this comes from personas. But there’s more to it than that.

In storytelling, Cron believes the problem starts in kindergarten when students are given “What ifs” like these, which are used in a school in New Jersey:

  • What if Jane was walking along the beach and she found a bottle with a message in it? Write a story about what would happen next…
  • What if Freddy woke up and discovered that there’s a castle in his backyard? He hears a strange sound coming from inside, and then…
  • What if Martha walks into class and finds a great big sparkly box on her desk? She opens it and inside she finds….
[…] The problem is, these surprises don’t lead anywhere, because they lack the essential element we were talking about earlier: context.

[…]Because so what if Freddy discovers a castle, or Martha finds a big box on her desk or Jane finds a message in a bottle? Unless we know why these things would matter to Freddy, Martha, or Jane, they’re just a bunch of unusual things that happen, even if they do break a well-known external pattern. Not only don’t they suggest an actual story, but they also don’t suggest anything at all, other than the reaction: Wow, that’s weird!

— Lisa Cron, Story Genius

Cron suggests amending a “what if” to have a simple line providing context for the character. Joseph Campbell would call this “equilibrium” or “stability” in his well-known story structure, the Hero’s Journey (more on this in the next section). Both Campbell and Cron are saying that an author must show what stability looks like before the hero receives their call to adventure (or “what if”).

For example:

  • What if Jane, who had been waiting for years to hear from her long-lost father, was walking along the beach and she found a bottle with a message in it? Write a story about what would happen next…
  • What if Freddy, who dreamed of adventure in his small town, woke up and discovered that there was a castle in his backyard? He hears a strange sound coming from inside, and then…
  • What if Martha, who believed she had no friends and hated school, walks into class and finds a great big sparkly box on her desk? She opens it and inside she finds…

For your product, context means going beyond the moment someone uses your product. The UX context includes the problem that someone has, what prompts them to find the product, and where they are when they use the product. Simply having a new tool or product won’t help someone to use it or feel connected to it.

Make sure to ask these questions instead:

  • Who is my audience?
  • Where do they spend their time?
  • What were they thinking, feeling, and doing before seeing my product?

These questions will start to create a context for use. For the RA Digital Companion, we began by creating a journey map to pinpoint all the things someone with RA experiences in their daily life. We sketched out the steps of the journey map on a storyboard, focusing on moments of pain, frustration, or concern. These became the areas where we thought our app could have the most impact.

For example, we wrote the story by starting with Grace (our person with RA) waking up in the morning, her hands already hurting. We hypothesized that she reaches for her phone first thing, maybe turning off the alarm on her phone. This became an opportunity to suggest a quick “game” on her phone which would challenge her to exercise her fingers. While we might have thought of the game without the journey map or storyboard, we also might have missed this opportunity to connect to a moment in Grace’s life.

Step 3: Follow The Hero’s Journey

As exciting as a story that goes on forever might seem, ultimately it would bore the audience. A good book — and a good product — has a flow that eventually ends. The author or UX team needs to know what that flow is and how to end the experience gracefully.

In his book, The Hero with a Thousand Faces, Joseph Campbell outlines 17 steps that make up a hero’s journey (a common template of storytelling). While the hero’s journey is very detailed, the overarching concept is applicable to UX design:

So, where does your story end? At what point will your product’s story reach its climax and successfully allow your end-user to be a hero? For a tax accounting software like Turbotax, the climax might be the moment that the taxes are filed. But the story isn’t over there; people need to track their refunders. Even though Turbotax doesn’t have that information in their product, they still help set expectations by creating infographics and other content that benefits their users as an “offboarding” process. In other words, where some products would leave users on their own as soon as they don’t physically need the product anymore, Turbotax offers materials to benefit users even when they’re done using the Turbotax product.

Designing for this type of offboarding is just as important as designing for onboarding. When someone uses TurboTax, they don’t want to feel harassed to come back to the app long after tax season is over. TurboTax is better off letting users stop using their product and return on their own when they need to. That’s how they keep their users happy.

When your design team identifies your offboarding point, you might try creating your user’s Hero Journey. One way to do this is to literally write a story about the user’s hero journey. Feel free to be silly, and position the user of your product as a knight in shining armor. Use the Hero’s Journey template to think about the emotional, mental, and physical state of the person using your product (remember your context from before!).

For example, let’s take a closer look at the well-known laundry detergent brand Tide and one of their commercials, “Princess Dress”:

We could break it down like this:

Step Observation
Call to Adventure Lily’s princess dress getting dirty.
Refusal of the Call Lily’s procrastination: she doesn’t want to change out of her princess dress.
Road of Trials The father collecting the dress and giving Lily her sheriff’s costume, plus her accompanying power trip (a true trial for every parent).
Apotheosis When the wash is dry and can be worn again.
Refusal of the Return The parent wanting to leave everything nice and clear in the basket.
Crossing the Return Threshold When Lily gets her princess dress back.
Master of Two Worlds Lily is wearing clean clothes that are not yet dirty and having to be washed.

Important note: Notice where the product is used and where the user steps away from Tide and continues on with their life.

Ideally, with an app like the Digital Companion, a user could use our app for years. But there will be ebbs and flows. Building off our storyboard we created numerous vignettes for our user “Grace”.

When Grace needs to take her injection, we knew from user research she would be worried, uncertain, and even likely to skip the medication. Instead of seeing this as a static phase in her life, we imagined her on the “Road of Trials” in the Adventure of the Hero. This imagery became a part of the language we used to encourage users to overcome their fears and bravely give themselves their injections. Over time, as the app encouraged “Grace” to build a habit of taking and recording her injections, our app copy treated her like a conquering hero, moving through the Hero’s Journey to become a “Master of Two Worlds”.

Step 4: Revise, Revise, Revise

“Good writing is good editing,” so the saying goes. The same is true with UX. For an author, finishing the story is only the first step. They then work with an editor to get more feedback and make numerous revisions. In UX, we rely on user research, and instead of “revisions,” we have iterations. Usability testing, A/B testing, user research, and prototype testing are all ways to get feedback from the target audience.

But in UX we have a major advantage. Once a book is published, the feedback can’t be acted on. But digital products can be adapted and improved even after launch. Websites get redesigns, and apps get bug fixes.

For example, when healthcare.gov launched, it immediately crashed. Harvard Business School reported:

“The key issues discussed above resulted in the rollout of the healthcare.gov website ballooning the initial $93.7M budget to an ultimate cost of $1.7B. It is easy to observe that the launch of healthcare.gov was a major failure.”

Yet healthcare.gov didn’t fail. The website still exists, and in 2021 alone more than 2.5 million people gained health coverage during the special enrollment period, allowed by the website. A failed story is simply a failure. A failed product can be iterated on.

In some cases, even a physical product can be updated to succeed. Consider a product like the Garmin watch. Even within one year there are multiple designs and styles. Some are flops, and others are major successes. The product designers learn from the flops and improve on each watch style every few years.

Although the Digital Companion is no longer available on the app store, we did have multiple releases after the initial launch. Even before that first release came out, we had ideas about how to build on the product and expand its capabilities. For example, we were able to start desirability testing on having multiple “finger stretching” game options and A/B testing video instructions for taking injections. These concepts didn’t need to wait on results from our initial release — such is the way of UX work!

Step 5: Write The Sequel

Once a product is out in the world, it’s time for the sequel. Many great stories have excellent sequels. Sometimes it’s a planned sequel like adding a new beverage to the Starbucks line. Other times it’s more of an add-on based on demand or need. A good sequel either completes a planned series or builds off the previous story. Think of these like the Star Wars trilogies versus the movies labeled “a Star Wars story.” A trilogy is a planned storyline. A one-off film may be built on the previous story and add to the world.

But some sequels do a bad job of building on the original story. Specifically, they erase characters or facts. Many Game of Thrones fans, for example, were furious with the last few episodes of the series. They saw the episodes of ignoring a key character’s growth, ignoring the rest of the series to create a nice ending.

This can happen to products as well. The tobacco industry had to find a new story for the problem their product solved after the 1964 Surgeon General’s report labeled smoking a health risk. It wasn’t the sequel they had planned, but in the words of their fictional ad man Don Draper:

“If you don’t like what people are saying, change the conversation.”

Mad Men: Change the Conversation

As a result, they changed the product itself (adding filters to more cigarettes) as well as the advertising around it, to claim that filters were healthier and protected the smoker from tar and nicotine (they do not). And it worked!

According to an article in the medical journal BMJ Journals:

“The marketplace response was a continuation of smoking rates with a dramatic conversion from “regular” (short length, unfiltered) products to new product forms (filtered, king-sized, menthol, 100 mm).”

Each UX designer, UX writer, and engineer on the RA Digital Companion product has gone on to make our own sequels. What I learned from the RA Digital Companion — about user needs, rheumatoid arthritis, and behavior change — has played into my work, most recently at Verily. That product created a story to be shared with the end-user, but the sequels may affect health-tech as a whole.

Tell A Story And Connect

Ultimately, telling a story is how we connect to one another as humans. Whether you use Lisa Cron’s Storygenius, Joseph Campbell’s Hero with a Thousand Faces, or simply the mindset of Daniel Kahneman, you can use storytelling to adapt your product to your user’s needs and wants.

As a Forbes article stated back in 2018:

“As human beings, we’re often drawn to the narrative; in part, because our complex psychological makeup wires us for the sharing of information through storytelling and in part due to our natural curiosity.”

Products are no exception: a good user experience takes the form of a story. The IA feels familiar and gives context and flow. The product itself will fit into a user’s sense of their own life story, and users are drawn to that.

To tell a story, you need to focus on a genre or a type of product and audience. You need to build out a world or context for your audience. Limit your scope to where you can have the most impact, revise with user feedback, and then think about the sequels. All in all, storytelling is a powerful tool for any UX designer. It will help you to create your product and understand the people who use it.

Related Reading on Smashing Magazine