Stories in the world of Featurism
Until recently, products have changed focus from a problem and proposed solution to a tool that does all this cool stuff, that you have to find a use for it. This shift has changed our focus as designers and product developers from a world of “must have” great products to a world of “nice to have” superfluous items. The result is “featurism” — the belief that a product, app or website is a bunch of features, and not a solution to a problem.
The “Why” Factor
In his book called Start With Why, Simon Sinek goes into grave detail about the fact that “People don’t buy what you do, but why you do it.” He goes on to describe the “feature” mentality discussing brands like Motorola and how the Razr lost its market share to products like the iPhone rapidly because of a focus on features. The Razr had a focus on speed, size, colors and materials versus with the tag line “thin.smart,strong” and in the end failed to create any sort of loyalty because it was just fluff. Sinek’s argument is that people buy your philosophy, your belief system, your world view, and THEN what you do. He uses Apple as an example of his theory:
“In everything we do, we believe in thinking differently. We believe in challenging the status quo. The way we do that is by making our products beautifully designed, simple to use, user friendly. We just happen to make great computers. Wanna buy one?”
as opposed to:
“We make great computers that are simple to use, user friendly and beautiful. Wanna buy one?”
The difference of starting with the “why” is much more compelling It goes much deeper than just the description of product and the features. In a world of featurism, I would like to propose an amendment to the maxim of “People don’t buy what you do, they buy why you do it:”
“People don’t buy what you do, but how and why you solve their problem.“
Why don’t you have a nice tall glass of Kool Aid?
It was a slow transition from a world of challenges, problems, needs and solutions to a world of products and features, but the advent of new digital devices and the internet, companies now tryi to sell us on this new cool feature and that cool new feature without directly speaking to the actual need the of the consumer. We often neglect how this new feature actually fixes their problem We, as a society have drunk the featurism Kool Aid.
And developers, and especially product people are drinking the Kool Aid too. As a result, designers are often put in the position of adding features at will without putting the features in context, and helping the team to understand why x,y, and z features are the right solution to the problem.
A Battle of the Superheroes: Features vs. Narratives
As a designer, you are in the trenches everyday of design constantly solving problems, either visually or functionally, or both. Seeing as there is precedence and convention for solving problems, we can often cut right to the chase, and offer a solution without thinking of the need we are fulfilling. A need to share something I find online turns into “social features.” A need for me to choose a product to buy that meets my needs turns into “reviews, descriptions, photos and videos.” While all of these features solved their respective problems, all the “features” seemed have skipped the vital step of understanding the users needs, putting down the “usual” or “conventional” methods of meeting those needs. But, here’s the issue:
They are just one way to solve the problem.
In a world of tons of products, innovation in design means solving the problem better than our predecessors, be it incrementally or dramatically. But true innovation gets to the solution of the problem, without giving a bunch of ideas to cover it up. As UX designers, our job is to help everybody take a step back and help our team members understand the application in context, and educate them and solve the problem with new eyes,
While there may not always be budget or time to truly innovate, as UX designers, we need to consider first and foremost “What are the problems this product is trying to solve?” rather than “What set of features does the product I am designing need?” and lead our teams with that frame of mind. We are there to serve the user, by understanding where he is, what he needs, and help him get it. We are the barrier between where he is (disgruntled, and insecure about his situation) to where he wants to be (secure with a solution, and knowledge about how to solve his problem in the future). With our unique knowledge of design, computers, the internet, database systems, programming languages and API calls, we create a tool to solve his personal problem. In doing so we solve a problem for thousands or possibly millions of people with the same problem (and hopefully we retire to Aruba, but that is the subject of another article).
In this feature laden war-zone, what is the Kryptonite for Feature Man:
Using narratives to describe user scenarios
User scenarios are what tie the feature to the problem, and get our user started off to where he wants to be. If the business that you are working on truly provides value, there WILL be a narrative. A narrative of what information the user needed that our system provided, and what the system did. For instance, if my problem is that I need to transfer money between my two accounts, the system told me how much I have in each account, indicated to me what I needed to do to transfer the money and then performed the transaction finally letting me know at the end that the transaction was complete, Voilå … narrative.
The best way to create a product is to figure out all the user scenario narratives you want the app to cover, and then figure out what features are needed in order to solve the problem. In the above example we know we are going to need a balance check, a list of accounts, a date of transfer and an amount of transfer at the very least. We may want to add a “transfer later” feature, or possibly a “transfer to an account at another bank” feature, but we will need to write the story and the situation that our user finds himself in before assessing if those features are needed, and if the business wants to meet those needs. If the philosophy of the business is that they are a full featured brick and mortar bank, they may not want to give the user that option. If they are an internet bank, it may be integral to completing the task.
Going from features to narratives takes a change in perspective, but in the end it will allow you to:
- Create new solutions without being boxed in by previously conventional solutions to the problem.
- Quickly assess the effectiveness of the solution
- Create a rich narrative by including persona development and research findings on behavior
- Create a more useful app that was designed for real people
I would like to suggest that as a part of any application or website, even an informational marketing microsite or landing page, that you create a story. Storyboarding as long been a tool for creating scope on projects and helping to visualize products, and I what would like to offer is an approach to storyboarding that is less drawing for those of us a little less sketch inclined. At the same time this approach will clearly define a use case for business people and product managers, as well as giving us UX designers the freedom to dream, to innovate, and to boldly go where no application has gone before… or at least make one that doesn’t suck like the other competitors.
A Great Story
In creating a useful story, you will want to tell the story of a person in a situation, and how he used our product/app/website to get from point A to point B. Describe the problem, and a step by step account of what happened when to solve the users problem. In the case of an informational site, this may be something a little simpler, such as “a consumer wants to find out what ingredients are in our products and what each of them do.” It can also be more detailed including buttons, gestures what they see on their screen, and data transfers between their machine and the server. The main idea is to show how this app is to be used in real life.
Another thing you will want to do is to use your personas, and attach them to their story. Your personas are the characters in your story. With your persona document, you have set the stage for your team to know who we are talking about, what motivates him, what are his tastes, where does he live, etc. It is the background on the character you would expect to find in the first few chapters of a book, but for our purposes, we are going to sum up with bullet points to keep it short and sweet. Each of your narratives will start with whichever persona needs to accomplish something, and will end with them riding off into the sunset, fait accomplI.
Defining all your narratives
The first step in creating the narratives is figuring out all the use cases for each of the personas. I usually end up with 5 to 10 narratives, but on a large site it could be as many as 20 or 30. Remember these are going to be used to create product requirements, which you will turn into wireframes, but for now you will need to brainstorm with your team all the things you hope for someone to do on your site [epics]. For instance on a banking site, you would include:
- Transfer money
- Pay Bills
- Check balances.
- Download transactions
- Download statements
Once you have all the items compiled, group items that might go together such as check balance, transfer money, and pay bills, All those three items can be put into one story. It is a real example of what a person would do in one session on a banking site. You can use your research interviews to put these together from real life situations. If a participant told you that they often download transactions and statements prior to reconciling at the end of the month, then you can confirm that a real person actuality did these items.
The other part of the definition that is often neglected is the internal story. There is a story inside the walls of your organization. The site usually doesn’t just magically create new content, manage itself, and answer customer concerns., your organization does that. You’ll need to create narratives that explain internal procedures from the point of view of the administrator/customer service people, It may include how support is handled, and how that shows up on the front end, It may include what happens to your personas request for help, and how they answered it (email, call back, etc). The people at your organization are personas as well.
Sometimes there are several points of view for an app, and you will have several “consumer” personas, but you may have secondary personas as well. I was working on a consumer app, but we had businesses that were using the admin on the app, as it was a tool for consumers to find businesses who give a portion of their sale back to charity. The businesses needed to record transactions, create reports and make payments themselves, so we created a story for each. Don’t neglect these narratives. If you have a product that a customer is an admin, but not the “consumer,” you will want to storyboard those out as well.
Creating Your Narrative:
Once you have everything defined, you need to put all your actions into a narrative. Most sites have a 3 step process for interaction, kinda like a movie. It has a beginning, a middle and an end. Again, good enough for Grandpa… you know. So break the lifecycle into at least three parts, and tell the narrative of each of our personas at that point. In our bank example. There will need to be a discovery or marketing phase where our persona is in the process of figuring out what services the bank offers in order to open account. This may end with her opening her account online. The next phase might be administration, where she checks balances, manages her portfolio, etc. Then the last phase may be support. In the case of an e-Commerce company, it will be product discovery, purchase, support and returns at the very least. On a larger site, such as Yelp or Yahoo, this will need to be done in digestible pieces, so break the stories into themes (not the SCRUM kind), and then do them one section at a time.
Next write the narrative like you would any other story. A couple things you can include:
- What has previously happened to get the user to where they are
- How much time they have? Are they relaxed or harried?
- What do they want to do? Where do they want to be?
Each narrative should be broken out into steps. Once I have written the narrative I break it into steps. You can use bullets or a comic style (if you are adding visuals) which breaks each part of the narrative into smaller digestible pieces. Here is an example from a narrative for a site that conducts online conferences:
Christina has heard about the Smithsonian conference on climate change from a colleague. While at her office, she visits the site. She browses the speaker lineup, and the sessions. Next she looks on a calendar view to get a sense of timeline, then she looks at the content in a list view to see the topics. It looks good so she decides to register. Christina fills out the registration form, then is taken to Paypal to complete her payment. Upon completion, the system takes her back to The Smithsonian site and logs her in. The conference topics are held over the course of a week, so she wants to make sure to doesn’t forget. She RSVP’s and downloads the ..ics file that adds it to her calendar, and then clicks the “Add Reminder” button, which will send her a notification in her email box. The system marks her RSVP and shows her as attending that session
From the narrative, you will want to create a feature list. In the first paragraph above, we see we will need:
- Speaker lineup
- Session list and calendar
- Payment module that accepts Paypal, (and probably other types of payment methods too)
- Registration module
- A reminder system that sends an email
- An RSVP system- that allows users to see who is attending which session.
Now that we have a list of features, we can start design, but this came from a real life story of how people are using the app. We have a context of what the app will really be used for, which type of person is using it, what they hope to do, and where they want to be. In the above, Christina wanted to attend a seminar. She needed to browse the speakers, sessions and topics, register and finally pay. We know that a standard e-Commerce workflow will work for this, but that wasn’t the point on this. We can make advances to the process because we can evaluate competitors based on Christina’s needs, see what they did well, and what they didn’t, and what we could do better, ultimately improve the product. Without the narratives, we would have created features for an online conference, just like the others. As I wrote in another article its all about perspective, and ultimately narratives help you take each user’s perspective, and let you decide on how that problem is to be solved.
And scratch their itch.