Menu
Enterprise Software Development

News and Views - articles and case studies for better strategies

Mobile Software isn’t Designed on Paper

Traditional software design process, at least using the waterfall methodology, involves a lot of up-front requirements gathering, collecting these requirements together to create a workflow, adding a user interface that makes sense and putting it all together in a structured design document. The result is that developers can reasonably estimate the time it will take to produce the software from the fixed requirements, budgets can be pretty stable, and time frames are reasonable to hit. When it comes to mobile software, a number of problems creep into this process.

1. Mobile software isn’t designed for one platform, but many. Usually targeting only one is not a recipe for success. Even iOS is not really one platform as there’s significant differences between the capabilities and expected user experience on an iPhone 3GS and an iPad 2 or iPhone 4S. Each mobile platform has peculiarities and caveats which are difficult to fully capture in a long requirements list.

2. You can’t design a truly accurate mobile interface for all platforms in Photoshop. Ok, so what I really mean is you can’t do that cost-effectively. For simple apps, sure, but the UI is more difficult for complex applications and when you need to cross platforms and show multiple screen sizes… well, it can be done but all that time and money you spend worrying about having accurate mockups could be invested in actually producing the software UI (given a basic framework being designed) and then making tweaks.

3. You can’t replicate the experience of using mobile software in a simulator. Sure, the developers can code and testers can test in the simulators, but ultimately you need to try it out on the mobile devices you are targeting to get a true feel for how the interface behaves. Experience will allow you to get closer to what you know works and doesn’t with less iterations, but until the app is actually running and in people’s hands, there’s a good chance things will need to be tweaked.

Ultimately, a more agile development process tends to work better with mobile software development. The problem with that is that it’s very hard to estimate costs, timelines and effort in an agile process because you get a lot of “I’ll know it when I see it” when trying to figure out when you’re “done”. That can be good as you can cut off unnecessary features if you realize you are happy with where the iterations are headed but also means that you aren’t really sure if this iteration will be the last or not. This makes agile a challenging process if you are working with an outside company to do your development, and expect a high-accuracy fixed price on your development.

Working with an experienced mobile developer can help mitigate some of those risks as experience in mobile is critically important to foresee the various roadblocks, device issues, user-experience changes and implementation difficulties that plague mobile software.

Here are some tips to help smooth the mobile design and development process:

1. Use wireframes not mockups. Wireframes outline the functionality of screens in the application and general layout details. Mockups tends to look so good that people expect the end result to look “just like the mockup” which results in a lot of bugs near the end of the process that are “different than mockup” bugs. Better to spend more time outlining the interactions between screens than worrying about getting pixel-perfect mockups.

2. Develop for one platform at a time. Once you have an app whose functionality you are happy with, it’s much faster and cheaper for that to be replicated across different platforms than trying to do them all at the same time. Since, in theory, most of your apps functionality will apply to all platforms, if you try to develop all at the same time you often get into the process of fixing the same bug or making the same changes on all the platforms at once. There will always be arbitrary changes needed near the end of a app’s development cycle so getting all those done once and then replicating an app you are happy with on other platforms is cheaper. It takes more calendar time but ultimately less man hours.

3. Think about how your users will be using their mobile device. People get phone calls, calendar notification, they walk through tunnels, their battery dies, along with many other scenarios that don’t occur on a PC. It’s important to think about how you want your application to react to these events.

4. Don’t limit yourself to only a minimum viable product, but understand you WILL have to update your application after its release. If not for the inevitable bug or feature request that comes up after real users are using your app, at least because there are always new devices coming to market that will need to be supported. Make sure to leave a portion of your budget free for post-release updates.

There’s myriad other considerations when building a mobile app but those four basic tips will help the development process go smoother, keep your budget down and help you stay on budget for the duration of the project.

Enhanced by Zemanta
Stay tuned, or sign up for updates





Your information will *never* be shared or sold to a 3rd party.

Comments are closed