…..(with real life examples of glitches and success, to help you relate better)
Let us begin with the sorry story of pacing pilots of American Airline, who were all victims of a tiny fault in an iPad app. Well, the after-effect of the fault was quite big — unexpected take-off delays of 74 odd flights between 28th and 29th April, 2015.
An overview of what happened
American Airlines equipped its pilots with charts and maps, detailing runway traffic and navigation, all in hard copies — everyday, a new set….because everyday, navigation plans witnessed changes. Other than a cruel use of paper, it also resulted in an increase in the weight, being hauled aboard. Findings report, getting off with all that weight would save $1.2 m worth aircraft fuel.
AA wisely decided on replacing physical runway and navigation maps with their digital version, in 2013. So everyday, charts and maps would be fed into a database. And it was an aim to have all these charts/maps to be somehow made available to pilots while they were preparing for take-offs or landings. Jeppensen, the EFB software provider for American Airlines devised out an iPad app for this purpose.
The app was deployed on all iPad devices, being carried by AA pilots and co-pilots. Something odd happened on 28th April, 2015. The app crashed, causing it to become unresponsive and shut down.
1. Flight take-offs delayed
2. Confusion for pilots
3. A lot of to and fro, to the gates (that’s where pilots to uninstall and then re-download the app, or get maps printed)
4. A system shift to reading navigation maps in pdf formats, that ere pushed out by the authorities.
5. Frustration for thousands of passengers.
It later became clear, the whole problem was because of duplication of a chart from the Reagan National Airport. The app was designed to distinguish between 2 charts on the basis of dates. What happened to this particular case in question is, two charts of consecutive dates were allotted the same date extension in their file names, by mistake. This caused the app to detect a duplication.
The app was not able to reconcile the duplication and crashed.
Why did we talk about this story here?
Because it tells us, even the best apps, by the best makers might fail, causing horrendous effect on the enterprise as well as the end service availers.
Enterprise applications, no matter what device they are compatible with (it was iPad here, leading many people to question the vetting standards of Apple app store), need a lot of care as far as minor-far-fetched possibilities are concerned.
This app glitch could be avoided if
1. A proper testing had been done before rolling it out
2. All possibilities of issues, no matter how remote, would have been considered
3. File distinction and identification would have been based on a wider spectrum of factors, rather than just depending on dates.
4. Duplicate document reconciliation had been thought of as a part of trouble-shooting todo’s
5. A smaller scale pilot deployment would have been initiated
The most potent problem in enterprise level applications as this one —
Enterprise apps are not vetted by the app-store review committee. That is a process which is followed only for end user utility apps, that can be downloaded for app-store.
Enterprise applications are manufactured and deployed by private agencies (Jeppensen, in this particular scenario), in compliance with a few set guidelines for the OS and the hardware, these apps are being made for. They do not undergo a grilling review process, which sets in probabilities of potential failures, being overlooked.
As such, it becomes the prime responsibility of all the stake-holders involved, to delve in depths of
why an enterprise app is being made
who is it supposed to serve directly
which category of user is being affected indirectly
how deep is the financial contribution of those who are indirectly affected, to the institution (AA had to endure a lot of frustration and negative rapport from its regular flyers, because of an app, that was not even closely meant for their utilization…and it was this section of the indirect category which provided AA the main chunk of bread and butter!)
how will a crash, or a feature failure affect the stake-holders
How quickly can such a failure be reconciled without causing considerable damage
After one that went terribly wrong, let’s look at one that could not have been more perfect
Have you heard of Slack?
We have heard it and we have used it. It’s awesome! It is the kind of enterprise application, that feels like a personal utility app — just another happy app that makes your life easier. Just within less than a decade of its fortunate introduction into the corporate market place, Slack has become tremendously popular and has been evaluated at $1 billion.
Author Nir Eyal makes a prominent mention of Slack, in his book, Hook. And there’s good reason, why.
The makers of Slack describe it as a complete informal toolbox for formal communication, just without the email part.
It is amazing, how an application, that eases work life for millions across the globe…something that serves a totally corporate function….something that is targeted to be used only within teams, can be so personal, so informal, so creative, so thoughtful, yet, so professional.
When you start using slack, it would look like any other team collaboration application to you. But the magic starts once you begin using it regularly. You get habituated to it gradually, so much so, you start thinking…how you could have possibly survived without it ever!
Here is a list of things, every enterprise application should borrow from Slack, and you, as an app owner, should learn from this app.
1. Slack makers knew exactly, what its users needed.
A hurdle-less team collaboration depends completely on smooth communication. Most formal communications, being driven by the email legacy, suffer from issues such as —
1. Time latency while responding 2. Grouping of information 3. An invisible wall of formality 4. Miscommunication, because the tone is generally overlooked 5. Long threads of communication, that make future correspondence hellish.
Slack brings an end to all of these problems, because Slack cuts out the email part from collaborative communication.
And when that happens, communication changes in the following ways —
1. It becomes more personal, bringing down the formal wall 2. There is no latency in responding (any member of the team, who is using slack, would get notification of any activity, he is concerned with) 3. Chances of miscommunication almost disappear, because communication is basically in one-liners, with complementing emoticons. 4. There is provision to tag people, so the communication is basically direct, yet keeping others in the team, in light of what’s happening (all without the irritating cc and bcc norm) 5. It makes processes faster, thus keeping the end user happy.
With such a clear idea of the main culprit of miscommunication in teams, Slack makers almost got a clear road-map laid ahead of them….with no room for confusion as far as features are concerned.
2. While the target was very niche, the purpose was quite broad.
Look at the communication here. They have not placed a definition of the purpose very specifically. It nowhere says, Slack is meant for designers, developers, managers, artists, engineers, or any other category for that matter.
It says, “Whatever work means for you”. Now, you might be running a fashion studio, employing a group of photographers and image editors. Or you might be a renowned mobile application designer and developer agency, employing more than 300 people in your organisation.
Slack would be useful to you, no matter who you are.
The crux lies of building a successful enterprise app lies in:
a. Defining who would be using your application
b. Defining exactly what purpose would your app be catering to
c. Defining what problem, in that purpose, would your app be solving
Apply this model to Slack and you would get:
a. Slack would be used by teams
b. Slack would cater to team collaboration
c. Slack would solve team miscommunication and correspondence delays, caused by conventional communicative routes.
3. How much to offer
Too much is as grave a mistake as too less.
Limiting offerings to a selective few is a bad idea, because it suffocates your users.
Over-showering your users with tools and features, can also backfire….considering the fact that users of enterprise apps generally download and use applications because they are extremely clear with what their problem is, and what they are looking for. Space for feature discovery, as such, gets limited to the availability of time and scope.
The best way, as such, is to find out a more diplomatic way to cater to demands and expectations.
Slack has done this in a very smart way. It brands itself as an application, that would bring all apps under one roof, so that users don’t have to keep switching apps. The crux is, it has given the liberty to choose apps, to users.
Obviously, you, as a digital marketer, will be using different apps that someone who is into photo editing. Hence, it makes sense to give that choice to users.
4. Getting into the users’ shoes is important (more particularly, because enterprise apps instill sort of a chain reaction)
Being built for enterprises, spans a lot of challenges in itself.
Most often, optimizing resource utilization is the main aim of enterprise applications.
But that is definitely not all of it. While resource optimization (that includes increasing productivity and being more resourceful as far as time is concerned) are the main motives of building enterprise apps, it is the end user that is affected at the end of the chain.
So if you have built an enterprise application, that helps organizations keep a track of sales and improve client communication, please remember that it is your client’s clients that you are finally serving.
Everything in your app, has to be accordingly placed, starting from the search box to the automated notification system.
See this screen for example…
Calls are an integral part of all communication. Calls make tones clear, set grounds for understanding in a more convenient way and brings linguistic clarification, much better than text messages and emails.
But if you are trying to make a call to person X, you will generally have to exit the app that you are using, look for X’s number in your caller list or your saved contacts and then make a call.
Slack did away with all of this. With slack, you can call a team member, right there, while you are using the application. You save on your time. Cumulatively, this time would amount to hours….Let’s not forget the cognitive load that is being done away with.
When that is the sort of effect on your team members, it is unjust to overlook the increased productivity in projects, and ultimately, towards your end customers.
5. The app has a personality
This is a highly neglected aspect of enterprise applications.
The most accepted norm is —
Because enterprise apps are for enterprises, they have to look formal and carry a sense of gravity. Most enterprise applications around will be in formal colours (blue, shades of orange or grey, black and white). There would be a plethora of activity options, studded right there at the top of the screen. The language used, would be highly technical….and the app would contain features and options, that would witness discovery by the user after months of usage.
Worse, most enterprise applications will come with long manuals and protocols.
In short, the whole scenario looks like a heavy-duty burden, having mastered which, you will feel you have started knowing the chemical formula for rocket fuel.
It does not have to be like that!
Since we have already chosen to elaborate on the beauty of Slack, we take this example further. The User Interface of this app is so simple, even the naivest of professionals would get used to it really quick.
The experience of using this application is simply fabulous. A few things that make this app really awesome:
1. a drag and drop upload mechanism 2. A side panel commenting space 3. Integration of third party applications to this app 4. The possibility of tagging people and channels to directly talk to them 5. A lot more
It is important to set the personality of an app, depending on the personality of its users. This stands as true to enterprise applications, as it is to end user utility apps. Once that is done, everything else takes care of itself.
While we seriously fell in love with these 5 things about Slack, there are a lot more that you need to keep count of.
We shall next talk about things, that you should never ever do, while you are getting an enterprise app built.
To be continued ……..