Ask "Why?" for Stronger Requirements

In a recent post, I listed a few ways that you can accidentally end up with a bad user experience. But there's another way to add bloat to your design: failing to ask "why."

The other day, a business analyst asked me to add a checkbox to one of my screens so that an administrative user could indicate, once every 6 months, that someone reviewed the screen for errors. Yet, we already have proof that the screen's data is being maintained because it's in the change log.

On the surface, adding a checkbox is an easy update to make. But, we don't know why we're being asked to make this update, or how this feature is going to be valuable to users. Simply put, our customer is requesting a solution without indicating what problem it solves. Though it might a good solution, how do we know it is the BEST solution?

Why ask why?

The next step isn't to drop the checkbox onto a wireframe, write up a few requirements, and head home for the weekend. The next step is to call up the client and ask "why."

  • Why does the client need this feature?
  • What information is the client hoping to collect via this feature?
  • How does the client plan to use this information?
  • Does the client know about the information we're already collecting?  

Once all these questions have been answered (and maybe a few more), we'll know how to proceed.

Needs vs. design

Good requirements describe a user need, but the need is never a "checkbox." The need is bigger. In my example's case, maybe the need is reporting for an audit, or maybe that checkbox is really supposed to notify someone of something. But we'll never know unless we stop and ask why, and solve the real problem.    

How Bad UX Happens

And now, a note about imperfect user experiences and how they happen. 

The late-breaking requirement

The UX is perfect, things are going great, and you just finished usability testing. Then the client calls and asks you to add something. It's not a problem, it's just a small tweak. Easy! 

A few weeks later, you're looking at your screens and wondering how things went so wrong.

Daniel Kahneman would blame it on a lazy controller. Basically, your instinctual mind makes a snap decision based on previous experience and your analytical mind blindly follows. Most of the time, this works well. Other times, not so much. Maybe you were rushed, or didn't quite understand the full impact of the change. Either way, once you look at your design change with a fresh mind, you can see what you would've done differently.

The early design that overstays its welcome

The other good time to unwittingly make a mistake is early on. You make a solid choice based on the information that you have at the time. But as you refine the design and learn more about the project, this "solid choice" becomes irrelevant or even totally unnecessary.

You, and probably the larger team, have gotten used to seeing it, and you have a type of "banner blindness" to your own work. And maybe it's so irrelevant that usability testing won't uncover it, because it literally is useless and unremarkable.

Much later, you or someone on your team notices it and you see it for what it is - clutter.

How to fix it

These types of unitentional mistakes get shipped to customers and handed off to clients all the time. Sometimes, you only notice them after your engagement has ended. If you're still working on the project, offer to clean it up as part of a larger group of updates - they can only turn you down. There is rarely a good argument against continuous improvement.

If your project is still underway - just suck it up and admit that a part of your design needs rework! Maybe your team will have a better idea, or maybe they will remember something about the requirements that you've already forgotten. Most people understand that it is hard to self-critique, and I think they'll appreciate you more for your willingness to make a change.

How to keep it from happening

Don't work in a silo! Ask for opinions from other smart people as you're designing, whether they are on your team or not.

For those small late-breaking changes, it's tempting to do something quickly, call it done, and post a file. Instead, make the change and let it rest a few hours. Then you'll be able to review it with a more critical eye.

Everyone Is a UX Person

“All the design jobs are for UX.” Someone said that to me today. My response?  

Good! They should be. 

Forget the ancient argument that web designers should know how to code. There’s merit there, but what good is a code-enabled designer who overlooks usability and function in favor of....god knows what. Pretty colors and great type? Melding UX and visual design makes sense--more sense than mandating that all creatives learn how to generate orderly, functioning code. When I hear that more and more interactive design positions are becoming hybrid UX/interactive design jobs, I want to stand up and cheer for the evolution of the web. 

Cheer myself out of a job, because I’m not a visual designer. 

Anyway....lately I’ve been thinking a lot about the future of UX, where the jobs are, and where they should be. 

I’ve come to a shocking conclusion: UX needs a dance partner. 

Visual design has to include UX. UI developers (aka front-end coders) have to be able to elevate code into graceful, usable experiences. Web copywriters are often really content strategists, who are siblings of the information architects and incestuously close cousins to those wireframe-wielding UX architects. Those business analysts/requirement jockeys? They’d have an easier time if they could sketch their own visions. Then there are UX researchers, whom I’ve yet to meet in the wilds of digital, because in the web industry they always seem to be doing something else (like your wireframes or IA). 

Where does this leave the person who only does wireframes? Who lives in a grayscale world? Whose prototypes don’t include “real” code? Or weirder yet, the mysterious “UX strategist” who...strategizes? 

I’m not sure. 

But what I’m not saying is that UX people should know how to code. Or that UX people should know how to design. Or know how to design, code, be UX, be IA, write and be totally comfortable with the research component. You know, a unicorn. That’s just not realistic. But what is realistic is expecting that all players in the web space contribute something to the usability of the product, and take user behavior and needs into account. 

An ugly story about the corporate web experience

Ever wonder who the people are who still use IE 7, or Firefox 11? Or who in their right mind is using IE 8 when they could be on Chrome? Do you assume that everyone sees beautiful Typekit and Google Fonts? Are you totally sure that you aren’t serving up your mobile-scaled responsive website to a person using a 20-inch monitor? Heck, how do you even know if anyone is seeing your PNGs and videos? Your social media sharing inputs?

I can tell you who isn’t seeing all this: me at work. And millions (billions?) of employees all over the world whose corporate jobs are such that the open Internet is a security risk, and every download, upgrade and software request is vetted and deployed by an internal IT group.

So what are all those lunchtime web surfers missing when they visit your website? Do you ever think of them? Are they your audience? Forget progressive enhancement for your website—when I'm at work, I’ll take graceful degradation any day because frankly, websites barely offer that.

Here's a sneak peak at what I see on my PC running IE 8 at work, and then how the world looks on my Mac running Chrome. You be the judge. 

Fonts gone bad

What Happy Cog and Delaware Valley College want you to see: 

What I saw at work: 

I'm not joking. I really only saw that much of the screen. The Arial replacement font sure is huge, and yes, it overlays the navigation in an odd way! No emphasis on "Our Programs" either. Is this what the desginer planned for me to see? I surely hope not. 

You call this responsive?

Here's how Smashing Magazine's Fixing a Broken User Experience article looked at home. 

And at work: 

Gak! Smashing is about design and UX and coding, right? I guess us corporate fools don't deserve your love. Though, on the bright side, this is actually an improvement. For a few months I could only get the mobile size of their RWD website on my laptop and my giant monitor. I never wished for a "full site" link with such longing...

You better have a transcription for that video. 

Luckily, TED does. But do you? Ideas worth spreading, indeed! 

You guessed it, the video quality never optimizes. 

What social media?

Now, for fun, a roundup of broken social media:

officeflickrwork.png
slateonfacebook.png
Screen Shot 2012-12-19 at 9.51.52 PM.png

I'll give you a hint as to how this ends. Nothing loads. And yet, I miss nothing!  

So what's my point? 

Funny you should ask.

Old screens don't suddenly get massive resolution upgrades. Crappy browsers don't die....possibly because some company's suite of web apps don't run reliably on anything but that old miserable browser. I'm actually happy to have IE 8....because I had IE 7 until September 2012. I'm not even supposed to use the ancient Firefox 11 on my laptop for browsing (but goodness knows what else I'd do with it). And plenty of people are being blocked from social media and multimedia every day at work and school. It's the way of the non-agency, non-web start-up, "uncool" places to work.

I implore you: design and code with us uncool kids in the back of your mind---because the web doesn't look like you think it does. It's uglier.