AppZone: The Designing of an App
Introduction
Design a mobile app. This is the capstone project, spread out over 10 weeks, for the Interaction Design Specialization certificate program that I’ve enrolled in. [The program was created by University of California, San Diego and is administered through Coursera.] We’ve been preparing for this assignment for months now, through 7 other courses, covering the details of interviewing people and gathering needs, of considering the challenges of social computing and designing for people to interact with each other as well as with our software. We’ve learned about what makes for good design, objectively, based on physical capabilities and cognition and perception. We’ve learned about design precedents and standards, about the history of design and about current designers. We’re ready.
Design a mobile app. That’s the simplified version of the project. We’re given more specifics, and some suggested directions to go in, but the end result is very much up to us, the students. I choose the “Glance” design brief, based on how people use their mobile phones. The end result, I think, will be to redesign a mobile dashboard. I’ve used an Android phone for several years now, and I like what they’ve done with the notification panel in version 6 and with the recommended apps and the quick settings buttons, but I suspect I could do better — or at least different. After all, that’s part of design, experimenting with new and different ideas, to see what works!
Disclaimer time: I work in the software industry, and have spent the last 4 years or so thinking about the design of the products I’m involved with and trying to improve the user experience and the product effectiveness. I’m taking this certificate to improve my skills, and to bring some foundation and formalization to what I’ve been doing. Some of my classmates are in a similar situation, I know, whereas this program has been an introduction to the field for others. My experience helps, I’m sure — and it also makes it easy for me to find research victims! Ahem, participants. Research participants. None of my colleagues were harmed in the designing of this app.
Step 1: Need Finding
The first step in design, I know, based on my experience and my education thus far, is to discover and understand what people need. To start this process, I observe and interview several colleagues, watching their mobile phone usage, and asking them about the best parts and worst parts of the experience. I could just ask them about mobile dashboards, but that would get us into a discussion of features — what they want, rather than what would actually be useful. It’s better, I think, to start off with a bigger picture and then zoom in from there.
My approach pays off, because what I find is the recurring theme that smart phones are a blessing and a curse: we’re never out of reach, but we’re never out of reach. This is news to no one, I’m sure, and equally true for me — but now I’m in a position to do something about it. The need, then, is to make our phone work for us, and not the other way around. When our phone is always with us, how do we separate our work life from our personal life and keep one from intruding into the other? The design question is still how to ensure our phone shows us relevant info at first glance, but it has become less about designing the dashboard and more about how to control the internals themselves.
Step 2: Putting Pen to Paper
The next step, after understanding the need, is to come up with the rough idea of the design. We sketch out some storyboards — and this is the hardest assignment for me, because I cannot draw. Exhibit A:
After the storyboards, we design paper prototypes of our apps. Paper prototypes are great — a step up from the white-boarding I do in the office — because they’re so easy to make and can be iterated and improved quickly. I’m too much of a technophile to like this method — I’d much rather use anything where I can make straight lines and perfect circles and legible text — but it does keep the emphasis on getting the ideas out rather than on making everything look nice.
My prototypes aren’t pretty, but they get the job done:
Step 3: Designing and Refining Working Prototypes
I’ve used Axure RP design software before, and I’m comfortable with it — I have an idea of what it can do, and what I can do with it, and so I’m ready to dive in. My first iteration is very much like my paper versions, but I’ve defined how the Android Back button will work (sorry, iPhone users: I’m focusing on what I know!), and I’ve made the check boxes bigger:
Working prototype in hand (well, on screen), it’s time to test! I go back to the folks I interviewed before to find out what they think. Feedback is good — since, after all, I’m sitting right there and because we work together — but they do point out things I could do better. The check boxes here are okay, but the grid is a little confusing. The location screen allows for selection by one method, but what about selecting by more than one, a sort of “any of the above”? Ditto for the schedule: If I’m home from work in the evenings, and on weekends, and in the morning, that’s three different schedules, all for the same settings.
These changes are no problem; I can do that. The next version is improved:
This seems like a minor change, perhaps, but it might make for a better user experience. Also, it’s more in line with Google’s design standards, so it will be a more familiar interface for everyone.
To determine whether the changes were effective, I put the revised version through another round of testing. (I owe a big thank you to the 20 colleagues who participated in this.) I compared the old and new versions to each other, A/B style, with each tester getting a URL chosen at random and Google Analytics keeping track of their clicks and whether more people were “successful” at following the test steps with the old version or the new version:
The results were inconclusive — no statistical significance — which isn’t a surprise, given my small sample size. However, going through the process itself was enlightening: learning what could be measured and what couldn’t, learning how to add the Google Analytics codes to the prototype so that it could be tracked and how to define events, and working through the resulting reporting. This experience, certainly, is something I can see myself applying in my day job.
Conclusion
After 9 weeks of work, observing and interviewing people, creating storyboards and mock-ups and paper prototypes and working digital prototypes, and running several rounds of user testing, I have a prototype I can be proud of and some formal knowledge and more practical experience. I watched my design go from “Build a better dashboard” to “Give people more control” and iterated through versions of what was simple to design (single-select) to what was needed (multi-select) and what made sense to be (a grid of check boxes) to what made sense to everyone and was a design standard (groups of boxes, with text).
If you’d like to see the final prototype, go here: http://x2jozq.axshare.com/home.html
There’s also a marketing video for the prototype here: https://www.youtube.com/watch?v=PqcQddXVFy4
If you have any feedback, I’d love to hear it.