3 things that testing wireframes can teach us about design
This week, we took our wireframes out into to the field for user testing.
Wireframes are frame-by-frame representations of how a user moves through a digital platform in real time. Wireframes serve as a step from “information architecture” (how an app’s data all fits together in the backend) to real-world UX that we all see and enjoy.
When you’re designing an app, testing wireframes can uncover pain points and problem areas in the flow of an interaction…before you sink major resources into actually building the app.
Testing wireframes can also help designers get out of their own perspective—which is what happened for me this week! I’ve used my TD Bank app for years, and having spent 2 weeks mapping concept maps and flows, I created wireframes I thought were straightforward and user-friendly. They were, sort of. But they also created some confusion and frustration.
I took 2 redesigned wireframe flows to 4 people for testing: Check Accounts, and Deposit a Check. None of the participants use TD Bank, which was helpful as this meant they would lack familiarity and a prior sense of what they “should” do to go through the app. One user told me she is “not at all digital,” which yielded especially interesting and valuable feedback.
Here are 3 lessons I learned from testing wireframes:
1: Your audiences determine your design. Sometimes, these audiences are at war.
Right off the bat, users were confused by the large “Contact” button I’d added to the home screen.
I was surprised, because at a mentor critique in Chrissy’s class last week, a UX designer had liked this choice.
Eric: “Make it as easy as possible to get in touch!”
But in my testing, users were confused — or actively turned off.
User A: “Who would I be contacting?”
User B: “Is ‘Contact’ really used that often?”
User J: “I don’t want people to call me!”
I’d added the button throughout the app, in an attempt to create a sense of TD’s helpfulness and availability. But it was hitting a wrong note, which meant it actually interfered with interactions throughout each flow.
A client and a UX developer may have different opinions. An expert and users may disagree. In this case — since the users are my primary audience — I opted to just chuck the Contact button altogether.
2: Sometimes, less is less.
My Check Accounts flow hit a snag when users got to the Accounts dashboard. I’d included only a Checking account, in an attempt to streamline the process. I thought it’d be easier for users to go through a flow with only one account option and wanted to design for them to succeed. Instead, users were frustrated as to why they only saw one account.
User A: “Normally I have Checking and then Credit Card…why is there just one?”
User B: “Where is my Savings account? I would have both.”
In an attempt at simplicity, I’d sacrificed usability. I’d also overlooked the pride and sense of reliance people have on seeing their accounts represented in the place they expect. Design is about creating simplicity out of complexity…and that requires understanding which complexities to keep in.
3: Building to your outlier can uncover (and solve!) hidden problems.
User A, who had told she was digitally un-savvy, also hit another snag on the Accounts dashboard. She wasn’t sure what to do next, and didn’t know to click the Checking Account bar. Though I had assumed everyone I would be talking to would be very comfortable with apps, her confusion was eye-opening. If TD is making an app for everyone, how could it design its app to be truly accessible to everyone?
In my redesign, I included a “View” button below each account. I wanted to include a visual (or audible!) cue for people who may not have the sight, familiarity, or dexterity to navigate the app otherwise.
I hadn’t gone into testing considering the accessibility implications, but User A’s challenge helped uncover a whole other lens to consider in my redesign.
This week we’ll be continuing to refine our redesigns. For now, view my full collection of wireframes in this presentation deck.