The profusion of personal mobile devices has changed consumers' expectations about access to information. We expect to be able to find details on products anytime, anywhere. And we are as likely to get that information from some sort of social network as we are to go directly to a company's website. This is a challenge for businesses that are used to controlling the flow of information about their products—but it's also an opportunity.
I was a panelist Friday at the What's Next conference, sponsored by the Bangor Daily News, on just that question. Businesses want to know if they need a mobile app to reach their customers, or if a mobile optimized (responsive) website is a sufficient starting point. And they want to know what it will cost.
This first question is fairly easy. Keynote speaker Chris Brogan advised that if people do nothing else, they made sure that their website was responsive so it looked good on the phones their customers use to look for everything. Brogan went further to say that the home page of those websites, whatever screen they are displayed on, needed to have one clear action that they promoted. A button to push, a video to watch or a compelling demonstration of the value of the product.
The second questions is harder. The answer, as afternoon keynoter Marcus Sheridan explained in the unlikely context of selling fiberglass pools, is, "it depends." Sheridan made a great point, though, that explaining what it depends on is critically important.
With that advice in mind, I will try to scope out how you go about assessing your business's app potential and then turn that into an actionable plan you can afford.
So, what could an app do for your business? Even framing the question begins to raise the issue of how you think about what you are doing with your business. Unlike app shops, whose apps are their "product," the apps that a business makes are more likely "extensions" of their products—more efficient means to deliver existing goods and services.
This begins to get at app thinking 101: the app is the visible evidence of some data and/or content. It is one of many possible "front-ends" to the information on the "back-end." So the starting point of the discussion is not "do I need an app?" but "what data do I want to display, transform and/or collect through a mobile device?"
So we start with a strategic concept, some big-picture thing we want to be able to do to achieve our business ends. But before we let our pie rise too high in the sky, we have to consider where the data for our app is going to come from. Data, in most businesses, is the province of the IT department, and this is where, in firms of any scale, we may encounter our first road block. (If you are a sole proprietor, talk among yourself!)
The IT department's job is to maintain the company's computer systems and networks and to store and protect its data. Most good IT departments are inertial in nature because failure means loss of data, productivity and ultimately, money. But the frame of mind that makes for rock-solid technology infrastructure is starkly different than the entropic mindset required to make apps.
What you need to find out from IT is the format that the relevant business data is stored in and the means to access it. This could mean internal SharePoint services or Open Directory databases or third-party data stores like SalesForce or DropBox. What you don't really want to hear is that your content is locked up in one or more outdated and proprietary formats accrued through decades of mergers and acquisitions.
OK, you know where the data lives, now, can you find someone within your organization with the necessary skills to put an app together? Here's the second pitfall. Someone may know how to build certain types of apps—but how will you know if it is the right kind of app? This is where outside consultants come in.
The great advantage of being an outsider (the role I have played for most of my career) is that you have a wider perspective than your clients do. Because consultants are in and out of many companies on a regular basis they can develop forms of domain wisdom hard to find among a company's staff. It's like the sophistication you get from extensive travel (though the food is often not as good!)
If consultants are honest—and you listen to them—they can provide a reality check on the originality of your app idea and the value of your existing data to support it. They also may be familiar with the range of app implementations within your sector and the kinds of third-party data your competitors may be using.
What kinds of consultants you seek out has everything to do with what kind of app you are thinking of and what your internal resources and budgets are. (Remember, "it depends!") It is tempting to think that you can go right to a designer who can show you what this will all look like, but most likely this is jumping the gun.
Between having a goal and finding the data to support it, and the launch of a successful, effective app, there is an important tactical step that can get overlooked. Your app doesn't just need data, it needs specific bits of data, transformed into certain formats and refreshed with a certain frequency. Once you have specified these formatted bits, a user experience specialist can help figure out how your customers can best metabolize the information you want them to engage with and a user interface designer can brand the resulting screens and make their functions intuitive.
This specification process should not be overlooked, but it is important to point out that all of these roles are fairly fluid. On smaller projects with smaller budgets, many of these functions will be performed by the same person. Large app shops can afford to retain a plethora of specialists and can deploy them like the sub-contractors in a high-end home renovation.
Depending on how agile your company's processes are, all of these various steps may happen sequentially or in parallel, but the critically important point is that, somehow, they all have to happen. The missing tactical step that I referred to above is what is often called a "content model." This is often the job of content strategists, but it is not, in itself, strategic.
The content model is really the shape of what the database for your app will become. Before you even decide what elements might go where on which screen, you have to at least sketch out the universe of data you need to make available to the app. If you are making an app from scratch, this is just a matter of deciding what kinds of data you want to collect in which formats. You would then get a back-end developer to build it for you, or better yet, to find the best software as a service (SaaS) solution for your needs. Some great back-end resources to look at are Kinvey, Contentful and Singly.
This distinction between building and curating defines a difference between programmers and developers. If you take your problem to a programmer, they will quote you a price to build it. If you bring the same problem to a developer, they will likely find a few ready-made components that do 90% of the job and then write small amounts of code to stitch them together. Suffice to say, modern developers have the capability of doing things a lot faster and cheaper than old-school programmers. If what you are doing is genuinely custom, though, it will often be more efficient to build from scratch, or at least on top of lower-level software libraries the details of which will make your eyes glaze.
Before you start congratulating yourself for finding a great developer, it's important to consider "scope creep." I have never worked on a digital project that did not turn out to have more pages, functions or headaches than the client foresaw. So, if you're the client, do the best you can to be specific about what you want, but reserve a portion of your budget for the unintended and unexpected. You will need it.
It's also important to consider how custom your needs really are, especially at the beginning. There are some very powerful new app building platforms, like Appery.io, The App Builder and Codiqa that take a lot of the labor out of making production-ready apps. The tradeoff is that your app may look fairly generic and be limited by the functions supported by the platform. Appery has very impressive plugins that connect your app to "prepackaged REST API services, pages, and data binding that add powerful functionality to your app instantly" from SalesForce, ESPN, Aetna, AT&T and more. The App Bulider supports more traditional enterprise infrastructure and "can be integrated with Microsoft SharePoint and Active Directory to provide mobile apps that comply with your existing security policies, Mobile Device Management tools, and procedures." Both platforms have free starter plans, so it's no risk to try out. Codiqa is less focused on consuming APIs than in allowing designers to quickly prototype solutions with drag and drop components that write real (and production ready) web code for you. It has a 15-day free trial, but not a permanent free tier. (See Reuvan Cohen's post on app builders here.)
Part of the magic, and limitation, of these kinds of platforms, is that they produce hybrid apps. Unlike native iOS and Android apps (written in Objective C and Java, respectively) hybrid apps use HTML5 web code with standard CSS and Javascript for the design and functionality. This web code, that can also power a website or web app, can then be "wrapped" in native code and packaged for the app stores just like any native app. Hybrid apps do not have access to all device capabilities and are often not as performant as native apps. But, depending on what you are trying to achieve, these limitations may not really matter.
One of the great advantages of hybrids is that not only can you use the same code to make iOS and Android apps (and even Windows or Blackberry, if you need to), but they are also much easier to update and experiment with.
Even if you decide to go with a "builder" platform, you still need to have people involved who know what they are doing. Specifically, you need a project manager that can keep the process on track and make sure everyone has what they need and understands what to do next. That project manager, and the developer or designer that they are primarily working with, may or may not have experience in content strategy, backend development, user experience, user interface, front end development or performance engineering. All of these are important, but, again, some of your team can wear multiple hats and/or select software that addresses some of these issues.
Another important consideration is the need to maintain and improve these products, once deployed, over time. Apps are, in many ways, more processes than things. The most successful apps (Instagram, of course, comes to mind) are the product of continuous exploration and improvement. So you need to think of what you are doing more as "digital engagement" than simply as app making. If you are going to "Master the Digital Channel," as Chris Brogan advises, you are in for a lot of trial and error, abject failure and humility. Your first idea may be wrong. Your first idea will likely be wrong! Your data may not be doing what you want. Your users may not be cooperating as you expect. You may need to find ways to make your customers care about what you are trying to do.
Remember, people are not clamoring for another icon for their home screens. To make an app that matters it has to matter to your customers by giving them something they can't get elsewhere. In the end, native or hybrid, custom or cookie-cutter, that is where the rubber meets the road, where you deliver something of value. How you translate that value into increased sales is a whole other question. But as Marcus Sheridan showed with his fiberglass pool customers, the ones that had absorbed the most of his content on the product (at least 30 and in some cases over 100 individual web pages!) were the customers most likely to make a purchase.
Apps give you the opportunity to present your products as solutions to your customers' problems, even if only by suggesting that you are a master in the domain of that problem. The one thing you clearly don't want to do in the digital channel is sell too baldly. Nothing, except perhaps sluggish performance, will make a user exit an app and never come back than the feeling that they are being marketed to aggressively. Most effective are apps that feel like gifts that merely remind you of the giver in a light-handed way.
– – – – – – – – – – – – – – – – – – – –
To keep up with Quantum of Content, please subscribe to my updates on Facebook, follow me on Twitter and App.net or add me on Google+.
