Mobile app development is more expensive, time- and money-wise, than developing web apps or mobile websites. Reasons include device constraints, multiple device connectivity options and input methods, and device diversity.
On the web, you can change fonts and font sizes thrice a week if you fancy. On mobile, you must carefully choose your design elements before going to development. What looks great on one device might be too hard to read on another: You need to look at screen sizes and resolutions. User expectations in a jam-packed app marketplace make it even harder on the mobile app developer. And with mobile technologies and devices constantly evolving, you also need to think about your app’s shelf-life vis-à-vis business strategy.
So what goes into building a marketable app? Here’s what you need to know about resources, roles, and the development cycle.
How many developers / designers?
Your budget, and how complex your app is, should help you decide this one. While it’s possible for a one-man team to develop an app, it usually takes more than one man (or woman, and that’s assuming he/she has design skills and UX sensibilities as well). A development team includes front-end developers and UI/UX designers. Larger projects involve a creative director to guide the wireframing process. They may rope in a business analyst to gather perspective on your app from the technology, business, release cycle, and market angles.
If your app sends and receives data that needs to be stored and processed, you’ll need a backend — and a backend engineer to set up and maintain servers and other equipment. Then of course there’s the project manager to make sure everything hangs together: Project plan, adherence to cycle times, resource allocation…
…And with all of these roles, the app development cycle moves along fixed steps across app releases: Defining requirements, design and development, and testing.
The app development sequence
On the front end, the development sequence typically goes from wireframing to UX design, on to UI blueprinting and UI design, followed by visual design and then development. Putting the wireframe stage first streamlines development: It makes it clear upfront to your client how the end product is going to look, feel, and work.
If you go with a bare-bones wireframe, your client won’t know what the app will look like until after the visual design. But that’s often a good thing. Mockups — with visuals of all of the app’s screens, including colors, icons, and scrollbars — can sway decisions, overriding more important considerations such as content placement. But to see why wireframing should come first, we need to take a look at UX and UI.
UI / UX
The UX design dictates how your app will feel. Good (or bad) UX appeals to the user’s emotions, while the UI dictates how the user interacts with the device. So the UI drives the UX to a good extent.
Assigning project roles more granularly means different UX and UI designers. The UX folks look at the app from the user’s viewpoint, and also evaluate user feedback. UI designers relate UX inputs with hardware aspects such as screen size, placement of visual elements on screen, physical buttons, and on-screen clickable areas.
Good UI and UX are harder to achieve on mobile devices than on the Web: The screens are small, so it’s inherently more difficult to get things done than on a desktop. And with so many apps out there, you need to provide superior UX to make yours stand out.
With different devices (smartphones, tablets, phablets), platforms, screen resolutions (Android phones chalk up 16 screen types with four screen sizes and four pixel densities), and orientations (portrait or landscape), designers have a huge number of screens to play with. They need to figure out what will work in each case.
So after it’s clear how the app will work, the wireframe is signed off. But before development comes…
Visual design
Clients often don’t understand how difficult it can be for a developer to change things. Just two extra menu items can make the menu fall off the screen — which means designing and coding another screen. A font change might make text unreadable on 10% of Android devices, and so forth.
What platform will the app run on? Will it be used on a tablet? Can we design for all possible screen types? Is the proposed look and feel acceptable / appealing? Your client must be able to answer these questions before the development phase.
Development and testing
It’s best to hire a developer who has extensive experience on the platform(s) or device(s), so they’ll be able to advice you about how best to use the features of that platform or device. After development comes testing for functionality, for performance, for optimization — and back to defining requirements for v2. The same factors that make app development challenging make comprehensive testing difficult: Device diversity, a multitude of platforms, user expectations, and so forth.
Here’s what IBM Distinguished Engineer Leigh Williamson had to say in 2013 about why development and testing for mobile is more complicated than for desktop: “…Because of the variety of device types that have to be supported. There’s all these different mobile operating systems … the range of human interaction to provide input for mobile applications is a whole lot wider … The breadth of functional capabilities that you have to test and also support in the code … is … at least one or maybe even two dimensional order of magnitudes greater than for most typical desktop applications.”
That’s a lot. Two orders of magnitude? Bottom line: It’s hard to make a good app. Perhaps that’s why we have close to 3 million — on iOS, Android, and Windows Phone combined?
