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 Practical CSS Grid 50% off!

Practical CSS Grid 50% off!

Whether you're new to CSS Grid or have played with it, finding practical examples of this new layout mechanism is the best way to learn it's power. Sign up below to learn more about my Practical CSS Grid course and get 50% off when it comes out!

Sign Up 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

2019 The Year of Markup-First Development

The state of the web in 2018 has been heavy into the world of JavaScript. We've made amazing advancements in the way our sites work. Every site has the ability to feel like an application. Without HTML, though, our fancy future may have a dystopian layer right beneath the surface.

Refactoring CSS into a Sass mixin

It struck me recently as I was writing a new Sass mixin that there may be designers and developers out there that haven't translated vanilla CSS into a Sass function. In this article, I want to show how to take often-used CSS and convert it into a DRY (Don't Repeat Yourself) Sass mixin.

Starting a new journey with Code Contemporary

I'm beginning my new journey as an independent creator. I've left the comfortable confines of agency life to see what I can do creating resources for designers and developers. I'll be writing, recording, speaking and consulting. Much of this will be under the heading of my new company Code Contemporary

My Side Projects

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