Designers put the user at the center of everything we do. We interview them about problems they need to solve, try to step into their shoes when making design decisions, and test our assumptions when we put a product in their hands. In the constant feedback loop of concept > prototype > testing, it’s easy to start taking user requests at face value and design solutions “straight from the horse’s mouth”.
The challenge is interpreting what your users are asking for. Even seemingly straightforward feedback may be a symptom of a larger design issue, and you need to make time in the process to discover what that might be. Unfortunately, taking that time to interpret is easier said than done. When users are clamoring for something, there can be pressure from project managers, developers and higher ups to treat it like a simple bug fix to be pushed out with the next release. This is where being the advocate for the user gets tricky. How am I an advocate when I’m arguing that we shouldn’t necessarily do what the user wants?
A real-life example
Believe me, I’ve read the design advice blog posts. And the books. Aaaaand even the tweets. What I’m saying in this post has been said over and over in many different forums. The thing is, when confronted with interpreting what users want vs. what they need, the answers don’t always flow out of you effortlessly like a glorious design wisdom fountain. In real life, I’m sitting in a meeting, halfway through a bite of a bagel probably, when the moment to analyze a user request appears.
Product manager: “So a lot of users in the beta are saying they really want ‘x’. ‘X’ would make their lives grand and magical.”
Developer: “Yeah, that seems simple enough to build. I think we can probably fit it into the next release even! Can we get some quick mocks for that?”
*All turn to me as I slowly chew on my bagel, trying to think of what to say next.*
I dealt with this exact situation recently after my team released a new feature into beta. For context, I work on an online community/forum for people in the IT field. They use the community to post technical questions, musings on IT topics, memes, and pretty much anything else they want to share.
Much like other social media sites, we have a place to view a “feed” of recent posts from the people or groups you follow. In it’s original form, it looked like this:
As you can see, the page is pretty out of date and bloated with information tacked on over the years. Metrics showed us that only our most dedicated visitors even used it at all. Thus, a feed redesign!
The new feed
The new design seemed like a strict upgrade. Gone were the pixellated and outdated icons! No more over tight text! Bye, Felicia, to that overstuffed sidebar! The new feed was in a fresh and clean card-style, taking cues from Facebook and Material Design. We were all very excited about the new era our community would enter and opened the redesigned feed up to a beta group.
The feedback was not what we expected. Some users liked it and commented the feed did look a lot better than the old one. But we also heard many complaints about too much vertical space and that the new layout didn’t allow them to read the posts quickly.
Lots of users said they much preferred the old feed and would not welcome the change permanently. WTF?
The most common solution requested was to create a ‘compact view’ that removes the lines of text under the title so they could see more posts at once. After hearing so much feedback asking for a compact version of the feed, it seemed like an obvious enough solution. It was added to the roadmap, and a design was requested. At the same time, the original lead designer on the project left the company, and the feed fell solely to me. Under the stress of added work, I quickly mocked up a few cards with the text removed, an arrow control to switch between the versions, and went on my way.
Wants vs. needs
In the next meeting, our team looked at the compact view prototype pulling in a real feed. A QA engineer on the team broke the silence with, “Is it just me, or is that even harder to read now?”
It struck me then that I failed to separate what our users really needed from what they said they wanted. My initial assumption was that they were just whitespace haters that wanted a dense UI, but, of course, that isn’t the full story. The actual problem was this: the new feed wasn’t as easy to scan as the old one.
“Can we push this back a little bit?” I asked. “I need time to figure out what to do here.”
After doing some research, I stopped thinking of our feed as a languorous “Facebook” reading experience. What our users really needed was an interface where the headlines are quickly scanned like Reddit or Designer News.
Despite it’s aesthetic faults, our “old” feed had a layout that made it easy to move across and down more smoothly than our new cards allowed. In the next round of mockups, I took that concept and came up with a new layout for the cards, both full size and compact, that better solve that problem, seen below.
Hey, it worked!
We released the newest iteration to our beta group and got a much more positive response. Users appreciated that we listened to them and commented that the readability had improved. We saw an uptick in users switching over to the new feed from the old. Some even commented that the new feed made them spend more time on our site than before (YAS!)
What seems like a trivial or simple change made a big difference in the usability of our product, and, for me, reinforced the lessons from all those design blogs, books, and tweets about interpreting user requests. When caught up in the grind of feedback and revision, it’s important to step back, put down your bagel, and figure out the needs behind the wants.