June 2019
Volume 34 Number 6
[Don't Get Me Started]
Testing 1 ... 2 ... 3 ...
By David S. Platt | June 2019
.jpg "David S. Platt")
The single best way to improve your UX designs is to test them on live users before coding them. Strangely, I find almost nobody does this today. I think it’s because of the name, “UX Testing.” The “T” word implies something that you do at the end of the process, to ensure that you’ve satisfied the requirements. But UX testing needs to happen before coding, to generate the correct requirements for your coders.
I can’t pull a design out of my head fully formed, like Athena from the brow of Zeus. Neither can you. What we can do is generate mock designs to show our test users, incorporate their feedback (I like this, I hate that, and oh, wait a minute, I forgot to mention such-and-such) into improved mockups; iterating until they’re good enough.
Here’s an example from my book, “The Joy of UX” (Addison-Wesley Professional, June 2016). It’s a mobile app for commuter rail riders near Boston. Instead of overwhelming you with a full timetable, the app shows only the times for trains going to and from the station you specify.
On Monday, I generated mockups with an editor called Balsamiq. You can see three iterations of the app UX in the panels in Figure 1. The existing app had required lots of jumping around to find the train time you wanted, so I created a design with no jumping at all. I put everything the user needs on one page: inbound trains, outbound trains, next train arrival time, alerts, passes, the works. You can see this in the left-most pane of Figure 1.
.png "Commuter Rail App Iterations")
Figure 1 Commuter Rail App Iterations
I emailed my Harvard students, asking who rode commuter rail, and snagging three riders as testing volunteers. On Tuesday, I showed them the mockup via Skype, asking, “You want to find the train to take tomorrow. What do you do?”
They unanimously hated this layout. It was complex, cramped, hard to pick out what they wanted. I omitted the arrival times, figuring they wouldn’t care. They did.
I couldn’t have been happier. The mockup stimulated the users’ thoughts, encouraging them to speak out. I wouldn’t have gotten this feedback otherwise.
OK, back to Balsamiq. By Wednesday afternoon, I had the design shown in the middle panel of Figure 1. I used a tab control to separate the pass from the schedule, and expanded the schedule information on its own tab. I showed this new mockup to the same users.
They liked it somewhat better. The app now displayed the schedule grids as they appeared on the station monitors, so it felt familiar. They now told me that in the morning, they only care about inbound trains, and in the afternoon, only about outbound trains. Displaying both on the same tab was more distracting than helpful.
Additionally, these discussions triggered a key breakthrough. One user looked at the next-train countdown timer, now somewhat easier to see but still not great. She said, “That next train timer—I need it up top, easy to see quickly, so I know if I need to run.”
This is what I call a double-smack. You smack your forehead, saying, “I never imagined [whatever].” And then within 30 seconds, you smack your forehead again, saying, “What could be more obvious than [whatever]?”
Which led me to the right-most panel in Figure 1. Inbound and outbound trains each occupy their own tab, with plenty of space for easy reading. The countdown timer is at the top, the alerts visible in the middle. They liked this one a lot. It’s the one I coded.
It pays to do this exploration at the initial mockup stage. Coding each mockup would cost much more time and money. When I got the users’ feedback, I’d have to either a) throw my investment away because they didn’t like it, or b) keep something users hated because I wouldn’t throw away my investment. Neither choice leads to great apps.
So, why don’t more companies do this? I can only guess that it’s the “T” word. Consider the usual development process: You write the code, you ship the code, then you test the code. (Customers are a big help here.) What should I call this process to indicate its vital position in the earliest stage of the design, rather than at the end? Validation? No. Iteration? I don’t know. Use the comment board to tell me: What word(s) would communicate this vital necessity?
David S. Platt teaches programming .NET at Harvard University Extension School and at companies all over the world. He’s the author of 11 programming books, including “Why Software Sucks” (Addison-Wesley Professional, 2006) and “Introducing Microsoft .NET” (Microsoft Press, 2002). Microsoft named him a Software Legend in 2002. He wonders whether he should have taped down two of his daughter’s fingers so she would learn how to count in octal. You can contact him at rollthunder.com.