If you haven’t heard the question yet, you soon will.
Business leaders everywhere are panicking to get that new iPhone app out the door and IT departments are being left with the task to manage the project. In order to deliver a stable, well-designed and effective smart phone or tablet app, IT leaders need to step back from the “we need an app now” hysteria and come up with a list of goals for the app in the early stages.
Only fools rush in
Nick Fotis, digital strategy manager at Chicago-based Leo Burnett Co.’s marketing services arm Arc Worldwide, works to develop mobile strategies for clients such as Purina, Whirlpool and Allstate. The key for him is an app project built around a strong consumer need.
Join us June 21st in Toronto for MobiBiz, our new enterprise mobility event.
“By developing an app, you need to reach an overall business objective,” he said. An app could be geared toward gaining more market research, boosting brand profile, increasing productivity, or generating new revenue streams from your customer base.
Prior to his current role at Arc, Fotis managed the launch of Cars.com’s native iPhone app and a redesign of the firm’s mobile Web site.
With its iPhone app, Fotis said Cars.com was looking both to take advantage of Apple’s App Store to build more customer awareness and to help existing customers gain easy access to the Cars.com platform when out visiting a lot. The app also had an unanticipated use as car dealers could easily keep tabs on how the competition is pricing its inventory.
Actually having a reason to build the app might seem pretty basic, Fotis said, but it is a stage that is often overlooked when app fever hits an enterprise.
All early design work should centre on your customer and how they will interact with the app, said Jeffrey Hammond, a principal analyst covering application development at Forrester Research Inc.
“When is your customer away from home and on the road?” he said. “What would they want to do with the app when they’re not on the road? What might they want to do with it when they’re in your competitor’s store?”
These are the things that need to be set forth early in the design stage, he said.
Not too big, not too small
Once these goals are in place, making sure the development process is at no risk of spiraling out of control should be next on the agenda.
Eric Knipp, a research director covering Web and cloud application development for Gartner Research Inc., said the biggest trap most companies fall into is trying to do too much with a mobile app. Pushing too many features and capabilities into an app, he said, often leads to a situation where “more becomes less.”
“A great example is Microsoft Office,” Knipp said. “There’s so much stuff that you can do in Word now that it can be very difficult for the non-power user to use that application in a non-frustrating way.”
A huge mistake for enterprise IT leaders starting down the mobile product road is to start shuffling features around during the early design stages as they would during some other type of enterprise app development project, he added. The more complexity added to the project, the greater the likelihood that the app will miss its delivery date or budget, Knipp said.
Hammond said releasing a “viable product” with just a few solid features is not necessarily a bad thing for a first release. Focusing on what the user needs to be able to do with the app initially is a best practice, he added.
Of course, that doesn’t mean organizations can overlook the fact that a first impression means everything in the app world, said Scott Michaels, vice-president of client services at Vancouver-based app development firm Atimi Software Inc.
“The first release must be substantial and must represent your brand properly,” he said, adding that it’s never too late to abandon and restart a project that appears destined to fail.
The idea of playing a game of “feature matching” with your competitor is a losing strategy, Michaels said. “A much better strategy is to figure out what your crown jewel is. You want to become the default app to do whatever it is you want the app to do.”
He advised companies to determine either what their competitors are doing poorly with their apps or what they’re not doing at all and use that to create the focus of their app project.
Take it outside
While in a perfect world your organization would be able to hire a team of developers, quality assurance testers and project managers to head up the project internally, Knipp said, very few companies are going to be able to afford to keep app development skills in-house.
“My recommendation is that you don’t necessarily try and do this yourself the first time,” he said, adding that many IT managers would be way out of their depth designing native mobile apps as opposed to Web apps.
Hammond agreed, saying that while he recommends organizations build up app development competencies for the long term, external talent is needed for almost every company heading into a project today.
For organizations looking to risk an in-house build, Hammond said, IT leaders will want to target developers with Objective-C and Java Client skills. The ability to design clean user interfaces on a small form factor is also a plus.
“Just because you can build an Android or iPhone app, doesn’t mean it’s going to look good,” Hammond added.
Knipp said form factor concerns can also translate to apps that are being ported over to the biggest tablet form factor and should not be dealt with lightheartedly during the design phase.
For organizations that choose to go the third-party route, vetting an app development shop is an important first step, especially with so many app development shops popping up to meet the demands of a desperate market.
Hammond said a tour of your vendor’s office and the working conditions of the developers can also help determine whether the app development shop can build you a creative and cutting edge piece of software.
“If it’s not a creative space, you may get a functional app, but that’s about it,” he said.
Fotis said that while reviewing the portfolio of app your vendor has created might be a no-brainer, digging deeper into their past projects and talking to their clients will also give you great insights into the development firm.
“It’s learning about how they did their project almost as much as it is about what they did,” he said. If the client did all of the creative work and simply looked to the app development shop for coding help, the company might not be a good fit for your project’s needs.
It starts at home
In the vast majority of these projects, app makers will be getting most of the data and intellectual property needed to create the app from your organization.
“This is generally some type of Web service layer,” Michaels said. He said IT leaders should work to present the data in the most lightweight way as possible so it is easily absorbed by the mobile product.
For Knipp, that means constructing a disconnected set of Web services and APIs that can be completely reusable across any number of Web or mobile interfaces.
“Once the APIs are in place, whether you go native or Web-based for your app, you shouldn’t have to do this twice,” he said, adding that mobile apps shouldn’t be treated as completely separate entities from your other customer-facing services.
Don’t go cheap
As for what an organization might expect to pay to a third-party app maker, Knipp estimated that US$200 per hour for resources that can deliver an iOS app is a fair price.
“A lot depends on how much work you’ve been able to do yourself in building a set of APIs that the mobile app can plug into,” he said. Knipp added that the least expensive consumer-facing app he’s encountered cost an organization $60,000.
For Hammond, a typical project would probably range from the low $100,000 range up to as much as a $1 million. Any less, he said, would result in cutbacks on quality assurance cycles and testing.
This is only the beginning
Google didn’t pick up huge traction in the market with Android OS by sitting idle after launching the platform. In fact, Android’s frantic upgrade cycle should actually inspire organizations to create a plan that covers application support beyond the initial release, Fotis said.
“Every time a new Android model comes out, new bugs are going to arise,” he said.
For Michaels, organizations should plan for multiple app releases right from the start. He added that each release should be built around a significant new feature that gives customers a reason to download the update.
Fotis said that the failure to understand that an app or a mobile site is a “long term consumer touchpoint” is a telltale sign that a project is on the wrong path. “It’s not about just building it and putting it out there.”
Mobile is the key word
But while you want to avoid putting every feature possible into the first version of your app, Knipp said, overlooking features that take advantage of the mobile form factor can hurt your long term success.
Forgetting the “mobile” aspect of a mobile app project is a crucial mistake not only from a design/interface point of view, but it can also limit the potential of your finished app. “The failure to take advantage of things like location and gestures is a failure to fully reframe the design process around the mobile device,” Knipp said. “You might just end up building the same old crappy app you could have built on a desktop browser.”
For example, if you know your customer is in a car near the location of your hotel chain, you might be able to proactively offer them a special booking price for the evening, Hammond said.
Apps are a social affair
The ability to interact with your customer through the app should also extend to listening to the feedback you get from the app store or other communication channels. “Mobile and social are so tightly linked in my view,” Knipp said. “Quite often you’re going to see apps being discussed on social media channels.”
The fact that most of the major app stores today do not allow the app maker to interact directly with customers should not stop your company from being proactive to negative ratings or constructive criticism from users.
“You can’t comment back to a bad comment, so you have to work hard to read into those and address them in the small amount of copy you get on the app store,” Michaels said.
He said the main outlets for addressing app feedback should be a dedicated portion of your company’s Web site and a Twitter account geared toward answering questions about the app itself.
In addition to reviewing the app crash logs and user comments for feedback, Michaels also recommended analytics software such as Adobe’s Omniture platform, Flurry Analytics or Google Analytics for Mobile to help organizations drill down into traffic reports.
But, he warned, just like using analytics on a traditional Web site, deciding to use these tools deep into the development process usually leads to failure.
“You need to define what you care about early on,” Michaels said. “Do you care when somebody uses the ‘click to call’ feature?”
“All that stuff has to be coded and thought about during the design process,” he added.
