If at first you don't succeed…(with wireframes)
“So you made a thing…”
We’re only three months into our program, and many of the things we’re making right now are not very good. Jon Kolko frequently uses the above phrase to preface a longer statement about how it’s important for designers to externalize concepts, design ideas, and propositions. Sketching, building, and prototyping ideas make it possible to poke and stretch them in ways that make the resulting product or service much stronger.
Which brings me to our Methods class for quarter two: Rapid Ideation and Creative Problem Solving. For our first assignment, we were tasked with developing wireframes* for an interface that helps students to plan their class schedules online.
To tackle the project, I started with a scenario about a student who wanted to plan her schedule on the go from her iPhone, but I quickly realized how challenging it is to design a system for such a tiny screen. (Especially with very limited wireframing experience!) So I shifted to developing for an iPad version.
Here are the wireframes I developed after multiple iterations. (Click link or image to download a full PDF with annotated wireframes.)
My process started on paper with scenarios, storyboards, and rough sketches. Through Sharpie drawings on copy paper and conversations with classmates, I tried out different configurations and got feedback on what was confusing. After sketching over 30 or 40 screens by hand, I started turning my hand-drawn interfaces into digital ones (using Keynote Kung-Fu) and added links so my five users who tested using the a think-aloud method were able to click through like they were operating a real app.
So what have I learned so far?
- Start with fewer details. I tried to draw in a lot of detail in my storyboards and the first round of iterations, which made it harder to throw out some of the pieces that weren’t working well.
- Play with more iPad apps. Through my testing, I discovered some of my layout choices didn’t fit with iPad conventions or users’ mental models for how the interface should work. I’m going to adjust these in the next round of iterations, but I also need to spend more time exploring apps to see how other developers handle similar issues.
- Don’t make people read. I had some messages on screen to help users know the next step, but the testers tended to experiment rather than read. My future iterations need to make the steps more obvious without the explanatory text.
- Provide feedback. “Am I done?” was asked by more than one tester. I need to think through how to offer visual indicators so users know where they are in the process and understand the outcomes of their taps and swipes.
- Make decisions so the users don’t have to. My first iteration allowed users to choose class by setting their preferred times on a schedule. But they can also browse the full course catalog. This was unclear for most of the testers, so I need to resolve the conflict in approaches so the user isn’t confused. And more broadly, the designer should make intentional decisions that make the experience better for the majority of users rather than building in “flexibility” that just leads to confusion because the designer didn’t want to take responsibility for focusing the interface.
While this process felt overwhelming and tedious at first, it became more fun the further I got into the wireframes and testing. I guess that’s a good thing because we’ll be iterating this same series of frames five more times!
And maybe by the end of the quarter, Kolko will end his, “So you made a thing…” phrase with, “and that’s actually something someone might want to use.”