Mobile app development process: Saving time, money

Learn about one approach to mobile app development that cuts the amount of resources that go into expensive software development and testing.

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.

Next Steps

Planning is the key to mobile UI development

This was last published in January 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Essential Guide

Essential guide to mobile application platforms

Join the conversation

6 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

What tricks have you developed to save time and money in the mobile app development process?
Cancel
Hi Niel, we are able to produce a fully working native-code app (iOS and Android) using a modularised app construction approach that "all but" does away with the wireframing stage. We can deliver 'Over The Air' this fully working app without needing to go to the Appstores - you can iterate this way for as long as required (change done in minutes, literally) - however from prototype to MVP is only the difference between tuning the already in-hand prototype. 
Cancel
One thing that I’ve seen work very well is to have the conversation about quality up front, when the development starts. I think this is extremely important in mobile application development because many people are still unsure about how exactly they are going to test a mobile application. So, having the quality discussion up front not only gets people to start thinking about how they are going to test the application, but it helps to make sure that design, development, and test are all on the same page, which saves a tremendous amount of time and money.
Cancel
Is it possible to talk about any specific apps that this process has helped create?
Cancel
I'm curious to see if the dedicated model fore apps is going to remain, or if we will ultimately transition over to apps build with JS or equivalents. I'm curious to see what Appcelerator Titanium can do, as it looks to be a JS framework development environment for mobile apps.
Cancel
I think this approach would do well in most development processes for almost any application, not just for mobile applications. Shortening the feedback loops seems to be key to saving time and money in development, whether it’s in the design process, development with coding and testing, or on the operations side of the house (hence the popularity in DevOps).
Cancel

-ADS BY GOOGLE

SearchCompliance

SearchHealthIT

SearchCloudComputing

SearchMobileComputing

SearchDataCenter

Close