It’s easy to notice that people have a lot of ideas about how things should work, but it doesn’t always seem like a ton of people choose to go the route of becoming a product designer. It’s fun in many ways, but still a job in many others. I personally have worked on a wide variety of consumer products, electronics, and sports equipment for places like New Balance, Hasbro, and a lot of others. But now that we live in the burgeoning start of the mobile age “Product Design” can mean something else -developing apps. It has means more than that, though, just like a consumer product is more than just it’s physical form. You’re designing and developing interactions and experiences, and hopefully ones that help someone live their life better. After all, that’s what design is, right?
To answer that question and to broaden my skill-set after 5 years in the physical goods field, I decided to get my toes wet doing interface and interaction development. Taking a year-and-a-half long series of Human-Computer Interaction Design courses through UCSD and the MOOC known as Coursera, I put on my learning hat and focused on something new. In some ways just a refresher on what I already knew, and applying it differently. This article will explore the prototype development process for an app called FreeTime, and additionally will try to draw some comparison between mobile software product development and consumer goods product development.
Originally, the app was a concept created to deal with the design brief of “redesigning time.” As a practicing designer while also taking classes and having an actual life outside both of those things, I saw a window of opportunity when given the topic of time as a basis for my thesis. Many of my friends are in a similar boat with the bustle of their lives, yet I see quite a few of them waste time on small things, only to lament later that they wish they had done other tasks or gotten more completed. In fact, some of the woes I heard from friends became storyboards for the product, which we’ll look at in a little bit.
The first thing in the design process is to was go and look at how people use time. Sure, you can always draw needs based on conjecture, but that’s not very good design research. Design research being something which is taught in ID (industrial design) but sometimes sorely lacking in the professional field, is important because it gives you an understanding of what people need. Going and seeing people “do their thing” and work their lives around a schedule is the best thing you can do regardless of whether you’re building a watch, or a schedule app, or a personal assistant automaton. What do people need? I don’t know. You might not know either. So go out and find people who are different from you and find out what design opportunities their habits and routines present. In this case, we started with a tour operator in Hollywood, CA, who managed a constant flow of people and multiple employee’s schedules. He is a great candidate for exploring design opportunities based on time.
From this observation session and a few others, we are able to begin breaking down time-related challenges that we saw people run into. Below, each of the post-it notes is a “how do we” statement. After combing through them all, four solutions are created that focus on addressing as many challenges as possible.
At this time, a point of view is created which describes the design direction for the application and its experience:
Everyone has free time, they just can’t always see it or use it correctly.
Let’s help people get their tasks done by optimizing scheduling.
From all of our developed design priorities and the chosen point of view, we now begin to make storyboards to imagine experiences that would act as these solutions. When doing storyboards for the app’s use habits, a clearer and clearer idea of the user interactions begin to form. Interestingly, I think a lot of physical product development could benefit from more storyboarding — while sketches and use drawings deal with physical interaction, the IxD (interaction design) habit of storyboarding allows for better consideration of the entire phase of use between a user and the product. Below we have one sample storyboard from this process — please excuse its rudimentary nature.
After storyboarding, we begin to draw out interactions that would satisfy the situations we had illustrated. The clear focus of FreeTime is that it helps users make the most of their time during the day, be it reminding them to fit an extra errand in when they 30 minutes in the afternoon, or helping them find the best time to avoid traffic, or even helping them schedule time to do nothing. This is done through special features that make the app unique in terms of a solution to scheduling. Some of these which are drawn from our storyboards are implementing personal energy levels into scheduling (suggesting a best time during a user’s day to book things), and checking traffic data (either live or at-time-of data from Google) when a user is scheduling something in with a finite location. Little things like this equate to a more complete view of how people go about their day, especially in a packed city like here in Los Angeles where I live and work. In the end, it might just another tool to try to be more efficient and live in more of a flow state, but I want it to work well and solve a problem I see in people.
With all this storyboarding done it is time to make something we can use. Paper prototypes come first, something unpolished that would be “unimaginable” to show to a client. In physical product design we do often go through hacked-together, quickly assembled prototypes just to validate a function or user experience. These paper prototypes are exactly that but still do a very good job at providing development cues and simulating user interactions. It’s also an easy format for quickly iterating screens for best focal-point development, before even touching a computer. To the left is a paper prototype developed from a real problem mentioned by an actual observation participant. Though the app and the user’s gender have been changed, it’s a glaring opportunity for personal change.
Design decisions from here on out are executed just as you would in ID. Take three or five developed options, consult with a user/client/classmates. Considerations when reviewing each iteration; Are people getting where they’re going in the application? Are users inputting information without getting click fatigue? How many options are too many? You choose a direction, iterate that one again and repeat. Make each set of revisions nicer and more interactive than the last. Following this principle, we end up with a wireframe. From the wireframe, we started adding interactions.
All of the app prototype in this particular prototype is laid out in Illustrator. Then, individual screens are exported to InVision’s web platform, where interactive features are added. Eventually enough interaction is created to be able to use the application in usage scenarios. At this stage, making it pretty comes second to making it work. Design means making it work.
Of course, adding functionality to the brim is useless if people can’t find it or figure it out. In the HBO television series Silicon Valley, we see the Pied Piper team having a poor reception to their launch. According to the engineers, it’s a feature rich and efficient platform. But users are “totally freaked out” and don’t understand how it works. Why? No good beta testing or user testing. And just like the team on TV, my long weeks of testing contain differences in user experiences between friends and associates, and the user tests run “out in the wild.” There is something to be said for the disparity of thinking patterns between people who live somewhat similar lifestyles to your own, and random users off the internet whom you’ll never meet or whom you’ll never know much about.
This feedback and user testing leads to slimmed menus, quicker interactions, and more user testing. It also lead to something important, that we do try to consider when we’re making physical products. And that is if your product has a learning curve, or requires the user to adapt to new thinking or a new way of doing tasks — then for the love of god include instructions. Some apps do an okay job at this, and some do not. Some of my user tests at this point in time lead me to believe my prototypes were falling into the second category. This caused me to spend nearly the same amount of time I had put into the app working on tutorial screens. Creating new ways of looking at time isn’t useful unless people understand how to do it. Later user tests with better prompting and better instruction screens have gotten much better results and lower error rates.
Then, just before publicly launching the prototype, we begin to worry about color. This is similar to how CMF may wait in some sectors of product design until functionality has been fully developed. Color prototypes are released to classmates and professor for review, and feedback is wonderful. Testing is always best and this is true no matter what you’re making, designing, or engineering. Use by actual users is the best way to evaluate how you’re doing, and at this point it seems like FreeTime was doing well, and ready for completion.
Confident in our functionality, a promotional video is developed — available here — and then there’s this article. From here, there’s a lot that could be done if this project is continued. Will I code FreeTime into a full-functioning app, and continue working on it’s development? Probably not, at least not right now. Currently, I have other projects and responsibilities on my plate, but now that I’ve gone through this process of learning, they involve more IxD and user testing than ever.
So how do “product design” and “product design” stack up? Just about the same, really. The end product is different, and the tools and prototypes have a different set of skills to them, but the concerns and steps in thinking are the same. Designers of all trades end up using the Adobe Suite and this is still true for both IxD and ID. Both involve sketching, and talking with users. Where an industrial designer might feel more comfortable with 3D modeling software, interaction designers have prototyping software of their own. The iterative process, the form of research which focuses on finding problems and developing solutions, and the somewhat-circular yet progressive pattern of design refinement are all still in play and involve the same mindsets. Now I’m not saying consumer product designers should run out and make apps, I’m saying that they can. The point of this article was to explore the fact that design is design, regardless of the eventual output. It’s a process that can be applied to anything, and in this case the difference between ID “products” and app “products” ends up only being what’s made and how it’s distributed.
I would like to thank Professors Scott Klemmer of University of California San Deigo and Jacob Wobbrock of University of Washington for leading the classes which have comprised the past year and a half, all my classmates for their interaction and help, and my family and close friends who have been there for me. I’d like to especially dedicate all this work to my dad, who left this Earth before I got to graduation. And lastly, thank you for reading.
-Rob Dahm
