When to “Ask”

The UX field is naturally focused on the user’s experience and that means that we sometimes identify conflicts between user needs and business needs. There was an anecdote floating around not too long ago that one of the Facebook redesigns improved the experience so much that people were able to get what they needed faster and spent less time on the site. Facebook is providing their product for free to its users, thus it makes all of it’s money off of advertising revenue. Therefore, people spending less time on the site translates directly into Facebook making less money. They quickly released another update that was “even better”, but looked a whole lot like the original newsfeed. I’m not a heavy Facebook user, so I couldn’t tell you if this was true from my personal experience and I have not seen any data–though I doubt they’re keen on releasing that.

As someone who cares passionately about the user’s experience, I really dislike when the business gets in the way of good product design. Most often, this happens when there is a specific behavior that the business must see (e.g. session duration or ad exposure for Facebook). The trick is to find the right way to present your value, so that when you do ask for the behavior, users are more than willing to comply.

How do we ask for the behavior without sacrificing the user experience?

The answer to that question is driven by these:

  1. What problem is this user trying to solve with the product?
  2. What behavior does the business need to see in order to make money?
  3. When have we sufficiently proven the product’s value through the experience to justify the ask ?

Continue reading “When to “Ask””

Scenario-Driven Design

We will sometimes get hung up on labels, but whether you call them scenarios or journey maps, or user flows; what I’m referring to here is the situation in which someone is engaging with your product.

Kim Goodwin had a great conversation with Jared Spool on scenario-driven design here. It’s only 30 minutes and well worth listening to, but here is the transcript if you prefer the written word.

Why should you care about scenarios?

Moore’s Law is still holding and as technology is rapidly advancing, we cannot accurately predict how tomorrow will solve today’s problems. Therefore, it is unrealistic to expect everything we build today to work for tomorrow’s users.

This is where I feel like scenarios can give us an edge in our design: by increasing the time to obsolescence.

If we design for features first (without considering the scenario), then we’ve really only addressed the symptom of the user’s true problem. That means all someone else has to do is actually solve the problem and their product will be superior, even if we have the better features. Users don’t want features, they want solutions to their problems.

Continue reading “Scenario-Driven Design”

UX Strategy Blueprint

UX Strategy Blueprint

Originally posted on Experiencing Information:

How do we consistently create UX strategy? Tough question.

Part of the problem is in the fuzziness of the term “strategy” itself. Many people blur it with detailed planning. Others consider strategy to be in-depth investigation, such as market research or competitor comparisons. Or, it gets conflated with vision or ambition.

None of these is strategy.

Strategy is about uncovering the key challenges in a situation and devising a way of coordinating effort to overcome them for a desired outcome. It’s an interlocking set of choices that aligns activity and shows causality: if we do this, then we expect to see that.

Analysis and planning, while necessary inputs and outputs in the strategy creation process, are not the core of strategy. You can’t analyze your way to strategy: the answers don’t magically emerge from data. And detailed roadmaps don’t provide the rationale for the activity they organize. Strategy does. It connects analysis and planning with an intentional logic that guides decision making.

Continue reading…