The User Experience (UX) Of Value In Web Application Design
This is a fairly vague title; but, it's for a topic that's fairly hard to articulate. Imagine that you are designing a web application and you have a user interface (UI) that you feel is complete. Then someone suggests adding a button "here" that lets the user perform some action. You, as the user experience (UX) designer, may feel strongly in your gut that the button should not be there. But, if the resulting click-action has some degree of value for the user, it's incredibly hard to explain to your graphic designers and your product team why the button shouldn't be there. This is because the user experience of "value" is complicated and multi-faceted!
On the surface, it's a losing battle. You want to create an experience that hold 7 points of value. Your product team wants you to create an experience that holds 8 points of value. If all you talk about is "points of value," you'll never win. You'll never be able to argue that 7 is "greater" than 8 (though any child can tell you why 6 is afraid of 7... because 7, 8, 9).
It necessarily has to be a discussion that takes a more holistic approach. Here are some of the questions that I like to bring up (when I'm actually included in the discussion):
Is this feature a fix for a different problem?
Sometimes, features are like medication. We take medication B to counteract the side-effects of medication A. And, we take medication C to counteract the side-effects of medication B. Sometimes, a feature or an interface element is added to counteract something else that's broken. Maybe we should be going back and fixing the core problem rather than trying to patch it with a new feature.
Is this feature actually a need for a different feature?
A slightly different take on the previous point, sometimes a desire to have feature X is actually a poorly articulated desire for feature Y. To me, this is often an "explicit" vs. "implicit" problem. Meaning, we sometimes try to add a feature that poorly does something implicitly for the user when it would actually be more beneficial to have the user do it explicitly for themselves. And sometimes, it's best to take the two concepts and turn them into two simpler features (rather than one overly complex and poorly designed feature).
Does this feature encourage a behavior that we want our users to have?
Just because a user wants something, it doesn't mean that it's a value-add in the context of the software. When you design a piece of software, you are doing so as a domain expert. And, as a domain expert, you get to craft an experience that encourages the "correct" behavior.
Does this feature detract from the goal of the software?
Sometimes, you get so caught up with adding value that you forget your purpose. This ties into the previous point. At the onset, your software had a purpose. This might evolve over time, it might even pivot; but, generally speaking, there is a mission. Does adding a feature support that mission? Or does it distract from that mission?
Does this feature make the mental model unnecessarily complex?
As user experience designers and domain experts we suffer from the "problem of knowledge." Our mental models are powered by years of experience and an understanding of the full breadth of the software. This allows us to keep, maintain, and consume very complex mental models. Our users do not have this ability. As such, an overly complex feature can lead to confusion and outcome-surprise, neither of which is good. Like a governor on an engine, sometimes making a feature less flexible actually makes it better for the user's relative ability.
Is this a "me too" feature?
Let's face it, in a competitive landscape, sometimes you have to build a feature for no other reason than the fact that your competitors have also built it. As a user experience designer, this makes me sad. But, it is a necessary evil. In such cases, I find it best to just "own" that fact and not try to sell it internally as anything more than what it is - a "me too" feature which may have no actual value.
Can we defer this feature until version 2?
My father used to say, "Sometimes you have to show people 'No.'" Meaning, sometimes you can't explain why something is a bad idea - a person have to see it for themselves. This question is a take on that thought in that if you can get your product team to agree to a moving the feature to a "version 2" effort, there's a chance that having a live system to play with will convince them that the feature is not necessary.
Does this feature have an unfortunate technical cost?
Here at InVision, we like to say that "Design makes everything possible." But, at the end of the day, our engineers have to fulfill that vision. This presents a very real cost. And, sometimes, the technical cost outweighs the value-add of the feature. Of course, that's heavily contextual and will depend on a host of other factors like the competitive landscape, marketing goals, burn rate, resource availability, etc. etc. etc.
Am I simply afraid of change?
This is the hardest question that you can ask because it is about your own biases and insecurities. Is it possible that I - as a user experience designer - am pushing back against a feature for no other reason than that I am afraid of change? This is a very real possibility (guilty!!!). But, asking and answering the previous questions will help you navigate the rough waters of personal bias.
I could go on and on. I absolutely love thinking about software design and user experience. But, I think these are the core questions that I ask when I'm trying to explore the feelings that I am having in my gut. The concept of value cannot be addressed in isolation. Value is always a matter of context and must be considered from multiple angles.
Reader Comments
Something this topic reminds me of is when a client requests a feature that, for lack of better terminology, just doesn't "smell" right. It's not a bad idea, per se. It solves a pertinent issue; it's not flamboyantly tacky; it's neither a bell nor a whistle. It just. Isn't. Quite. Right.
Anti-patterns or poor practices in code give off this same feeling. Your gut tells you it's wrong, even if you can't put your finger on exactly why. Maybe because you've forgotten the difference between a factory and a service, or you never fully [i]grokked[/i] closures, but you know damn well that the 15 if-then statements you just wrote can't be the best way to do this.
How do you tactfully convince a client to hold off on pursuing a feature until you have enough time to research, and ultimately denounce, their otherwise inexplicably bad idea?
@JC,
The simplest way is never, ever answer the question "how long will this take?" on the spot. The only correct response is 'I'll get back to you'.
This takes you off the spot, it gives you time to analyze the real impact. It will allow you to think of questions that need answers from the business on who what where when why or how.
If it's a half-baked idea, here is also your opportunity to offer alternatives or amendments to it. This allows you to have spent time coming up with reasonable estimates of time, resources (people), and cost. Then you're able to put the ball in their court and leave the decision up to the business.
The business gets to have everything. They must just have the willingness to pay for it and the opportunity cost it has on existing endeavors (delayed start to a separate project, extended completion date, etc).
@JC,
It's definitely a difficult question! And, I definitely know that coding feeling. While I love to pontificate on the merits of good UX, I spend most of time writing code (and putting out fires). I know that I'll often write a chunk of code and it's just _not right_. It's such a horrible feeling because that path forward feels so unclear. And, the worst part is that sometimes I get so stuck on that feeling that I fail to move forward at all. Not until I just say "screw it" and move onto the next piece of code.
Too much art, not enough science :D
@Chris,
Yooo, estimates - and the interpretation thereof - are like the root of all evil. I can't tell you how frustrated I get when you get 70% of an idea from the product team and then they want an estimate. But, then, when they deliver the other 30% of the idea, no one expects the timelines to change. The biggest problem with this is that it turns different teams against each other. Things get sad very quickly when timelines are too strict.