Julie's UX Blog


Not asking "why?"

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.    

Mistakes were made.

And now, a note about imperfect user experiences and how I think they happen. (Think! Ha. This is how I know they happen, at least on my projects.)

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.


An argument for ubiquitous UX 

“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 being cross-functional in SOMETHING. And I bet you all are. It’s just not in your job description, or you haven’t realized that it’s a part of you (or you mistakenly think everyone else has your mad talent).

So, can anyone teach me how to be a visual designer? Anyone? 


Take your fancy fonts and shove them: 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:

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. 


Prototyping with Axure: Why not just learn to code? 

Prototyping. I had never done it before, so I was excited when my new project required me to learn Axure and make real, fairly comprehensive prototypes for a web app. I read Prototyping: A Practitioner’s Guide by Todd Zaki Warfel to prepare, and I started to believe that prototyping was the solution to every problem I’ve ever had communicating wireframes. 

And in a way, prototypes do just that. After a couple months in prototype land, I think clients who can’t grasp wireframes---who are overwhelmed by what they are seeing (and what they aren’t)---may be more comfortable with a mockup that they can take for a test drive. I also believe that prototypes can be good for killing bad ideas before they make it to coding. 

But prototyping in Axure? For me, the jury is out. 

Why am I fake-coding? 

First, there’s the problem of Axure. Building interactions in Axure is fairly complex. Not only are you doing simple things like linking up pages and adding list items to dropdown menu controls---but you are also writing conditional statements and managing tons of visible and hidden layers. This left me wondering WHY. Why not just learn how to code? Writing a condition with a fill-in-the-blanks style builder in Axure is only slightly less confusing than learning how to program conditions sloppily in JavaScript. Why learn a uni-tasking fake programming tool when you could just learn how to code? I’m terrible at coding (and not very fond of it, either), but Axure had me convinced that coding would be faster and more fun. 

What, this visual representation isn't a visual representation? 

The second thing that bugs me about prototyping is how it makes wireframes--formerly known as “not a visual representation”--into visual representations. When you show a lo-fi black and gray line drawing, no one actually believes the final product should be black, white and gray. Also, in most of my circumstances, wireframes were not pixel-perfect. Yeah, they might be based on a 960 grid, but wireframes are an artifact that people print or tape up on a wall. Show a prototype? You are showing a website. You are one step closer to fidelity, and if you start introducing graphic design elements like logos, images and colors---man. You are no longer not a visual representation, are you? 

And if you’re no longer “not a visual representation,” then are you really rapid and iterative? I’ve worked on plenty of savvy teams where my partners could look at wireframes get the concept. See the problems. Grasp the possible solutions. I didn’t need to make accordion panels unfurl or fake-program conditions onto a submit button. I could’ve just shown the wireframes in a sequence. 

So, in the end, I’m sure prototyping is valuable and helpful in many contexts. I’m just not sure the way I’m doing it with Axure is worth the trouble.


How to Ride the T: a Users Guide

I’m taking a break from my usual subject matter to write about one of the mysteries of Pittsburgh: the Port Authority’s mass transit line commonly referred to as the “T.” It has several aliases, so you may know of it as the trolley, the subway, or the light rail. It only serves the South Hills neighborhoods, downtown, and now the North Shore, so if you don’t frequent those neighborhoods, it’s entirely possible that you’ve never seen it or ridden it—you may not even believe it exists.

I am uniquely qualified to lecture on this topic—I never saw the T until I moved to the South Hills. Then I lived a few houses down from a T stop. For 4 years, I never rode it more than a couple times a year, and it seemed like every time I rode it, I messed something up. Now I ride it every day and hope to save you the annoyance of making mistakes I made.

How to pay the fare

Headed toward the city? Pay when you get on. Leaving the city? Pay when you get off. If you get on the T anywhere between First Avenue and Allegheny Station on the North Shore, it’s free. It’s weird, and even a little different from the bus. That’s life.

If you don’t have a pass, use exact change or tickets. Using tickets will save you from paying rush hour surcharges on cash—it’s the cheapest, easiest way to ride the T. You can buy them at your local grocery store. However, there are 10 tickets in a pack, and the Port Authority raises fares constantly. If you don’t think you can use all 10 in 6 months, or you’ve heard that fare hikes are in the offing, don’t buy the tickets. You get a short grace period to pay the additional cash fare with the ticket, but after that, who knows. I read somewhere that you could turn them into the main PAT office downtown (don’t quote me on this!)…but will you do that? No. You’ll just end up throwing the old tickets away.

One final note about the tickets: you hand them to the fare booth worker or the conductor. Don’t try to stuff them into the bill slot!

High-level vs. low-level stops

During peak times like rush hour and heavy downtown/North Shore entertainment traffic, the trolley will have 2 cars. The doors to the second car of the trolley only open at high-level stops. So, if you are getting off at a low-level stop, you MUST get on the first car or else you won't be able to get off at your stop.

How do you know you’re at a high-level or low-level stop? High-level stops are bigger and in bold on the map. In the suburbs, they generally have a fare booth. All downtown and North Shore stops are high-level. When you get on or off the trolley at a low-level stop, you usually have to take a step up or down.

The phantom fare booths

High-level T stops have a staffed fare booth during peak hours; this is where you pay. They won’t make change for you. Off-peak, you pay the conductor as usual. 

Sometimes during peak hours there is no one is staffing the booth. It happens semi-frequently. Why ask why? Sometimes this means everyone gets a free ride. Other times, the conductor makes an announcement and takes the fare. As best I can tell, here is what should happen so that no one gets a free ride:

  • Inbound: The conductor will announce to the waiting platform that people with cash or tickets have to board the first car to pay.
  • Outbound: After you’re already on the T, the conductor will announce which stop is unmanned, and will request that all those in the second car move to the first car at the next high-level stop, where they will pay the conductor upon exit.

Closing notes

  • The perpendicular seats by the doors are for the handicapped or elderly. If there are other seats open on the T car, don’t sit there. If the car is full, go ahead and sit, but be prepared to give up your seat to someone who needs it.
  • Morning rush hour is crowded. Be prepared to stand if you are getting on the Red Line at Dormont or after. Evening rush is less crowded. Most people get on at Wood Street and Steel Plaza. If you get on before that, you’ll almost always have a seat.

Disclaimer: As you can guess, all this is subject to change by the Pittsburgh Port Authority. Check their website for the latest information. I am not a Port Authority employee, and I may not update this post to reflect any changes made by PAT. Use your best judgment. 


Does your mobile app work offline? 

Check out my latest post over at Elliance's Aha Blog. It's part vacation brag, and part advice on making your mobile apps valuable in any context. Read it here.