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:
As a Customer, I want to see relevant content and personalized advertisements using data siphoned from personal and private Facebook DMs without my consent.
— Old Guard Rupert (@davatron5000) December 19, 2018
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?
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
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.
{% include ad-space.html %}
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.
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.
Like most things that have the word “user” in their title, a user worry will come from one of two places.
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.
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.
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.
As a user, I want to know that my document is saved.
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.
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.
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.
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.
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。