BACKGROUND IMAGE: iSTOCK/GETTY IMAGES
It's hard to deny that mobile technologies are causing work life and personal life to bleed together. Because we have so much technology available to us almost anywhere, they're practically inseparable. Check your bank account while at a work meeting? Why not? Read email when your spouse wants to talk? People do it all the time. Respond to LinkedIn messages and Twitter postings during office hours? Of course.
This merging of personal and work computing on a mobile device has changed our mobile app development process. To make a compelling, killer mobile app, we need to recognize that we are competing against the best mobile apps in the combined work/personal marketplace. Our mobile app might look great compared with its in-office, PC-based alternative but pale in comparison with the innovations from the best technology companies in the world.
To address this new reality, I had to learn to walk in my customers' shoes and think about how my products and services touch the broad aspects of their lives. I needed to think about processes, tools, use cases, analyses and ripple effects far beyond the specific use of our app. What are my customers – either internal or external -- trying to accomplish? What barriers are in the way? What opportunities can we provide that they don't yet recognize themselves?
Now, to be honest, my IT background has not really qualified me to answer such deep questions about mobile (and all other) app development. Fortunately, I have found another way to get the answers, a solution derived from two harsh lessons I learned years ago: No one knows what they want until they see it, and, once they see it, they want to change it.
To address this new reality, I had to learn to walk in my customers' shoes and think about how my products and services touch the broad aspects of their lives.
With those lessons in mind, I developed a mobile app development process that I believe produces a more successful -- and more frequently downloaded -- app. I start by interviewing a small number of my internal or external customers and asking them to describe the work they do. I ask pretty broad questions like, "How do you spend your day? As you think about how you spend your day, what are the best things about your work? The worst things about your work? If you could change anything about the work you do or the tools you use, what would you change?"
I bring a designer with me during these interviews because I want to confront the first lesson -- no one knows what they want until they see it -- as early as possible. As the interviews continue, the designer creates low-fidelity pictures of what we learned. These pictures depict what we heard about opportunities and issues. We then show the pictures and the flow of the application to those we interviewed. Seeing the results of their feedback represented visually helps them imagine using what we created.
We then confront the second lesson I learned: As soon as they see it, they want to change it. But, at this point in the app development process, design changes cost almost nothing to make. So we collect feedback on the pictures and make revisions. This is much better than investing early in software engineering only to find out we missed the target and have to redo the work.
As we progress through the design/feedback loops, we improve the quality of the experience by creating clickable prototypes that replicate the experience (the prototypes can be created in any number of ways, whether using images on a webpage or using prototyping tools). Once we've worked out the kinks in the design phrase, we start the software development and testing phase. In this approach, the software development has lots of advantages over the approach in which we write requirements documents and even over the traditional Agile user story approach: The engineers build to a known design, which reduces errors, bugs and rework. We will continue to use iterative methods with the iterations delivering phases of something we know will be a hit – we have already collected input and feedback from actual, live customers.
I have been using this approach for the past several years, and it rarely results in a "miss." Projects go much faster and have higher initial adoption. In one case, the pilot version of our mobile app was so good that we moved immediately to full release. No matter how mundane my application functionality, the app benefits from user feedback during the initial design phase.
Planning is the key to mobile UI development