Stuart Silverstein Experience Strategist/Designer

back to all articles

Stories in the world of Featurism

Here is a great new smoothie I came up with

1 cup pineapple
1/2 banana
1 cup Kale
Juice of 1/2 Lime
1 teaspoon Flax seed
1 teaspoon spirulina
1/4 avocado
3/4 Fresh Apple Juice
3/4 cup Coconut Water

Stick it in a blender and blend until smooth. Enjoy!

 
I have officially closed Fetch! and started consulting. After 2 months of soul searching, this and a key partnership dissolving, remedy I decided it was best to do consulting until I get my next venture off the ground, so I started a new contract gig at Fandango. I’m working on the website doing UX design.

The new venture will be a software company. I have been bitten by the app bug. I admit it. A few months ago the idea of productivity, and the lack of visual productivity apps in the market got me to create a new app for you to visually create your action items, and keep inspiration and action items. It is called Wallboard. More details to come as well as the prelaunch beta site. Stay tuned!

Also, I will be at the How Magazine Interactive Design Conference speaking on Competitive Analysis. It should be a fun session. I will talk about the 3 different types of analysis, and how to create them in a way that you get insight, and how to learn from competitor’s mistakes. I am doing both East and West coast conferences.  Here is more information:
http://howinteractiveconference.com/ehome/index.php?eventid=39587& 
If you’ve been in the web business for long enough, search at some point you’ll have a story about the project that wouldn’t die. You know, drug the one with 20 rounds of revisions, features added in development that add a month to the project, and a feature set takes 3 months to agree on? I’m going to be honest and say that I have been a part of several.

At a certain point, these projects will wear on even the most perfectionistic and patient of us all. I mean, how much more juice will you have after the 23rd revision to the home page. It’s pretty hard to keep up your enthusiasm, and I’m a pretty damn enthusiastic guy. There just comes a point where enough is enough, and you just want to see something completed.

In my experience, most “designers” have a shelf life of about 3-4 months on a certain task, after which, they will need to have help to see things more clearly, pass their work on to production, or they will start to get cranky. 3-4 months is about what most people who focus on a certain project can effectively handle. By project I mean an end to end design of a certain piece of functionality or app, as larger sites may have multiple projects. So, for instance, I am a UX designer, my time intensive part of the process on a site happens to take about 2-3 months, and then tapers of to a few hours a week. If it goes on longer, I start to feel it. Once it is off my plate into visual design, the project has new life again and everybody gets excited to see the project alive as visual designers breathe new life into the wireframes.

Oftentimes, we don’t have a choice as to how long a project will take. There may be disention in the ranks,or people can’t agree, or you just haven’t got the right solution. These types of projects drag on, and you just hope for them to end. They loose steam, and creatively start to weigh on you. You loose your confidence in decision making as all options seem the same, and you slug it out until you can hand it off.

So What do you do?

There are some techniques that I use to maintain my own interest in a project, and boost the morale of the team, when everything seems to move at a snails pace. The trick really is to pace the energy of the project. If you get all excited at the beginning and discuss every detail at length in the beginning, by the 12th week, you’re going to be fatigued. I like to break a project into 3 phases – beginning, middle and end. Each phase has things that you can do to boost energy, and get everybody creatively energized about the project again.

Beginning

The trick with the beginning is to really set yourself up for the rest of the project. Pacing is important, and so is preparation and strategy.

Prepare your strategy well
One of the biggest things that stops projects is a long internal discussion on this feature or that feature based on subjective opinion. I find that it is due to lack of strategy. How many time has this happened: there are 3 ways we can do xyz feature/design, and all of them look good, yet it takes a 1 hour meeting to come to a consensus?

If you’ve done your strategy right, you should be able to refer to personas, goals, and research to make a best guess before yielding to personal opinion. These types of “my opinion is better than your opinion” conversations will kill momentum on a project faster than anything, have the highest potential to create animosity.

Establish your strategy process, make sure that it prepares you for the rest of the project and assists you in your decision making. If it doesn’t, do a post mortem on your next project, and try to figure out what information you were lacking that would have made decision making easier and more accurate. More user research? Usability studies? Feature prioritization? Messaging? How can you create a clearer strategy to help decisions next time.

Set your pacing
A web project is kinda like running a marathon. If you go too fast in the beginning, you’ll tire quickly. Go too slow, and you’ll have to rush to make up time at the end. The trick to keeping energy high is to pace it evenly.

Some projects that I have seen get tiring do so because of the old “sprint” methodology. It is usually impossible to foretell how smooth a project will run, and if it will run according to schedule, but having only short sprints to base timing on may make you spend too much time up front, which can make a project drag. If you set dates, and watch your pace, it will be easier to manage versus making up time at the end.

My philosophy is to do short sprints, being aware of the bigger picture timeframe. Give someone the responsibility of being a “timekeeper” who can push the project along if things get too drawn out. It can be a Project Manager, Creative Director, UX lead, Tech lead or whomever, just not the Product Owner. The Product Owner will inevitably want to tweak things forever. Agree to this up front, get buy-in and set some time boundaries for large sections (Strategy, UX, Design, Development, QA) and some firm deadlines.

Middle

The main challenge in the middle of a project is to keep things moving. Nothing destroys project momentum faster than long drawn out back and forth discussion. Back and forth discussion is good for the product, however, too much talk and not enough rock, will leave the key person drained and at worst, discouraged.

Meet frequently for short periods – 15-20 minutes – versus fewer long meetings
In the beginning when there are lots of ideas swimming, a short period of time to discuss a limited amount of items helps prevent long discussions on small topics. Longer meetings, can be very draining creatively, especially when you have a lot of ground to cover. Short frequent meetings are key. If you can’t come to a decision on something in 20 minutes, save it for the next meeting. Agile/Scrum teams already do this as part of their regimen. Making sure that decision makers are part of this will help maintain team morale, and keep the project moving.

When you’re stuck make quick easy decisions to get moving
When a team is stuck on something, it can be very draining to find an answer. For instance, I was on a project where there was research needed by the dev team on a payment system. There was several weeks of research and tested they had to do in order to give us an answer on what payment service we were using. This affected the energy of the team, and at the time, weighed down on the project. At that point, we focused on some other areas that we could get some quick wins on, and that got momentum moving again.

Grab a beer!
Never underestimate the power of good old fashioned bonding. Bonding is a great way to create empathy with your team and to have time to relate in non work mode. Let’s face it, sometimes, discussions can get heated, and if that heat is not tempered, you can start to villanize team members very quickly. Take one day every month to go to happy hour and grab a beer together, and talk about your kids, yoga, hiking, travel, technology, anything BUT your project.

End

At the end, everybody wants to see the project live already. You can feel the impatience brewing. Product Owners and Designers are pressing to see this live, but even with all the pressure to complete, the product has to be completed strong. I feel our job as Designers at this point is support to our other team members. Our job is “done” and the PSD’s are off our table, but we owe the rest of our team just as much support to make sure the project is completed successfully. I have seen and personally been a part of projects that have failed at this point, due to a lack of support and teamwork with the rest of the team at this crucial juncture.

Support your developers!
Those of us in the design process have long been finished with our portion of intensive work once the project reaches it’s final development stages. Our job in the development phase is to support the developers. Usually these guys get the raw end of the deal. They are the ones who are “pushed” to get a project done with an insubordinate amount of time when everything else dragged out.

How can you support your developers? First, encourage them. Give them praise when they get it right. All too often I see designers critical of developers work, simply because that is our job— to make sure that they get our “vision” right, and it performs as you intended. It can be a thankless job, so show these guys some love.

Get in the feedback loop in short sprints versus long detailed reviews.
The best projects I have been a part of had the design team reviewing small bits that take 20-30 minutes, versus, long detailed reviews. Going back to our “quick wins” this is a way to create quick wins, so when there is a snag, you all have brain space to dedicate to it.

Be very careful of major changes!
There is always the last minute idea that gets added to the pot that you didn’t think of in the design phase. It ALWAYS happens. When this happens (not if), be very aware of the impact of this. Minor changes are to be expected, but major changes often busts a team’s morale at a critical point in the project. Tread lightly. Product owners are notorious for adding things at the last minute, often unaware to the SNAFU that it adds to morale of development, design and production.

My philosophy is unless it is a major usability issue, save last minute ideas for the next sprint. Complete what you have, test it, verify your hypothesis, and get feedback. It can also lead to a “just get it done” mentality which gets it done half-a**ed. If you are going to add some major functionality or process change at the last minute, tread lightly and think through your decision. Is it mission critical at this point? Is it a nice to have? What are the ramifications of adding this in the grand scheme of the product. How will it affect morale?

If you you decide to move forward with a major change, drinks should be on the product owner— for real! If you are a Product owner and you decide on a major pivot, treat your production team very nice and be very appreciative of the work they do. It will help boost the energy and morale.

Whether or not you are a leader on a project, or a team member, you need to do what you can to help a project move along, and keep everybody engaged and energized over the course of a project. Nothing will ruin a project worse than a lack of enthusiasm. At the end of the day, every project is a team effort, and we owe it to our team to maintain energy and enthusiasm. Even the most engaging projects can be draining if you do not take some precautions along the way to maintain energy. It takes some planning and effort, but in the long run, the projects that keep energy throughout are the one’s we do our best work on, and the one’s we look back on with fond memories of.
In a recent article I did for Smashing Magazine, buy I discussed  a little Neuropsychology, approved and how your brain works. Essentially, ailment how your brain works is that the left brain engages until all your usual solutions have been tried and exhausted. At that point, when you have hit the “wall” and have sunk into a deep depression and are researching classes at your local community colleges on auto repair because you feel inadequate as designer, your relaxation causes the right hemisphere of your brain to engage. Your right hemisphere allows you to free associate and creatively assemble 2 things that have no relationship at all – gravity and an apple, gold and a bathtub, a kite and lightening, etc.

On my current project working for Fandango, I realized that this process explains my method for design. When I start working on a design, I find it essential to  get the obvious out first, so my first sketches are all the obvious ideas. The ones you know will work. The first thing that pops into your head once the direction has been defined. So I spend a certain amount of time, just getting the idea out of my head, and on to paper.

Now it’s pretty rare that this is a “winner.” It is often based off of the usual set of chops and techniques I have developed. These are pretty routine, at least to me, and are not usually acceptable work to put out. Occasionally, I am blessed with divine inspiration, and the first idea is so pure and so right, that anything else is just extra, but that is definitely the exception not the rule.

I have found that this process of sketching the obvious allows me to lighten my head, and get the obvious stuff out of my head. It also is very reassuring that I can let it go. I now have the comp on paper, and I can go back to it if I want to, or if I want to refer to it at any time.  It also allows me to hit the wall faster. If I don’t get my idea out of my head, it will haunt me and I will be unable to move past it.

Once I have got the obvious out, I get to a place where I don’t know what to do. I come with no further preconceived notions of what the project should look like, and I am open to explore new alternatives.

  • I often start looking at different layouts and design patterns on the web to see if I can use them as an inspiration to try something new.
  • I also talk with a lot of people. I try to have as many unstructured casual conversations with as many smart people as I can around the topic. I find that talking through the ideas, and hearing yourself talk through a problem often helps you arrive at new solutions without the pressure of stakeholders.
  • Then I sketch every different variable I can imagine – quickly
  • … and use my intuition on which idea to present or further discuss with others.

What’s your process?
I don’t know when it happened or how it happened, buy more about but it happened.  Everybody has stopped solving problems, cost and started using features.

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.

Why narratives?

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
  • Etc

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:

  • Location
  • 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:

 

Beginning:

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

Creating requirements:

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.