🎉 Looking to get started with Grid? Download my free ebook! Get into Grid Now »

Build Trust on the Web incorporating User Worries with your User Stories

The web is suffering from a crisis of trust. Every week there’s a new story posted about a data breach or untrustworthy practices (I’m looking at you, Facebook).

At the height of the Facebook-is-giving-away-your-data controversies, Dave Rupert shared this “user story” tweet:

While Dave’s post is the height of Twitter humor about this topic, it got me thinking: When we create user stories for new features, shouldn’t we also create user worries about them?

What is a user story?

To the uninitiated, user stories are a technique popularized by Agile development practitioners. They are a way of breaking up products and features into discrete pieces to be created.

There are as many ways of being Agile as there are companies using Agile methodologies, but the general take on user stories follows this pattern:

As a < type of user >, I want < some goal > so that < some desired result >.

To take an example from Dave’s tongue-in-cheek tweet, the following user story could be real for Facebook:

As a < Personal User >, I want < my news feed to have the most relevant content based on my interests > so that < I can prioritize what items to read >.

This is a big feature for one user story. Big user stories are called “epics” and are broken up into multiple smaller stories.

That’s the general flow. It helps create requirements documentation based around potential user needs. Read more about user stories here: https://www.mountaingoatsoftware.com/agile/user-stories

Enter user worries

One thing that user stories don’t account for is user stress. Our products on the web have the ability to touch a wide range of people. And the web is a diverse and hopefully inclusive place. So, it follows that every feature we write will be used by drastically different people with different experience levels and thus different stress points.

People’s anxiety regarding a new technology can vary based on many factors. Have they had their identity stolen before? How long have they used a computer/smartphone/web browser? Did they have a stressful day at work? Do they have a screaming baby in their arms? Not everyone will approach your new feature from the same starting point.

Promo Image for Free ebook - Common CSS Grid Patterns

Free ebook - Common CSS Grid Patterns

CSS Grid is a revolution in web layout. With this ebook, I cover 3 design patterns that Grid solves easier, better and more creatively to help push our designs in better directions.

Download Now!

How can we mitigate their concerns?

I propose taking all your user stories and creating a list of potential user worries. You get bonus points if you are able to talk to users and find out their worries firsthand.

Let’s take a look at corresponding user worries for our user story example above.

“Interests”

“Most relevant content”

Many users struggle with the concept of algorithms and data sorting. Many more struggle with big tech companies knowing what they like.

If you prioritize these worries along with your features, you’ll discover additional features that can offset the worries. You may also find potential ethical concerns.

While this example is obviously fresh in everyone’s minds from the recent Facebook scandals, let’s take a look at something that’s a little less loaded with security concerns.

User story: As an author, I want my work saved regularly so that I cannot lose work if my application crashes.

This feature can be best described as an “autosave.”

Let’s outline some user worries that go along with this feature:

These worries may not seem as earth shattering as those in the Facebook example, but to your users they may be very important.

How do you create a user worry?

Like most things that have the word “user” in their title, a user worry will come from one of two places.

The best source of user information: User research

If you’re doing user stories properly, they’re probably stemming from some form of user research. Finding user worries is just another step in compiling your new features.

You shouldn’t feel like user research has to have a large price tag attached. These can be simple conversations with your users. To gather user worries, simply ask your users a few additional questions.

“Do you have any questions about < feature > ?”

You’ll notice a pattern in my user worry examples above: They’re all questions. I find that most worries in life stem from unanswered questions. So, make sure your sample users ask you any questions they have.

The second-best source of user information: Empathy

There’s no question that primary user research is the best way to get good user data. If for whatever reason you’re lacking research, empathy will win the day.

If you have personas built, put yourself in those user mindsets. What are they thinking as they use your feature? What outside stressors could be weighing on them? When are they using this feature? How technologically savvy are they?

In our autosave example, we probably are dealing with users from a wide range of tech backgrounds. If a particular user just got accustomed to saving his work often, it’s a new mental model for them to “not worry” about saving anymore. Often, less tech-savvy users view technology as an abstract “magic.” It was already magical enough that they could write on a machine; now they have to trust in that magic to keep their work safe. That’s a big leap for some.

Utilizing user worries

A comprehensive list of user worries will give you more features and design elements to build. Let’s take a few our worries from our autosave example and find some new features or ideas that will address those worries.

How do I know my document is saved?

As a user, I want to know that my document is saved.

How often is “regularly”?

Adding a timestamp to the most recent save could help put a user at ease. If I can see that the last save was 2 minutes ago, I can gain more understanding of how often this feature works.

As a user, I want to know when my document was last saved.

If I come back to a document, can I undo changes I made previously?

This could be solved in a few ways. First, we could add a manual undo/redo button near the save notification. This would show users that undoing is possible outside Cmd/Ctrl+Z.

As a user, I want a graphical representation of my undo/redo options.

Next, we could provide a user with a version history.

As a user, I want to be able to view and revert to previous saved versions of my document.

Is a manual save handled differently from an autosave?

We could provide an annotation for each save, whether it was manual or automatic.

As a user, I want to know if a previous save is the result of a manual save or an automatic save.

Why user worries?

We already have a lot to think about when we develop applications. Why would we voluntarily add more steps and more writing to that process?

In the end, the applications whose developers show the most empathy and compassion for their users will win the day. The more you do to make users worry less, the more they’ll use your application.

You May Also Enjoy

Grid vs. Flex: A Tale of a "Simple" Promo Space

I love the new layout modes in CSS. Grid and Flexbox are both amazing features. They each have their place. What if I told you that if you used the "wrong" one, you could double your CSS and HTML? Let's take a look at what appears to be a simple promo grid.

Using Eleventy's JavaScript Data Files

I enjoy building workflows for pure static sites. I enjoy ingesting data into my build process instead of loading my client-side with fetches. In this example, we'll use Eleventy's ability to use a JavaScript file, to execute code to fetch data on site build, negating the need for task runners like Gulp.

The Tech Barrier to Entry

I'm grateful for my unique journey to find my professional niche. It's taken a lot of twists and turns. Is my journey replicable in this era of developer tooling and convenience?

My Side Projects

Web Workers Logo Web Workers Logo Web Workers Logo Web Workers Logo