Note: Special Thanks to Jessica M. H. Smith for some editing and a few ideas, she’s a class act
Robert F. Kennedy said, “Only those who dare to fail greatly can ever achieve greatly.” It’s among the scores of failure quotes meant to encourage us to take chances and turn our defeats into victories. Daring greatly in the app world is important, but it doesn’t mean that you have to fail or suck into order to build a brilliant app.
Building an app is easy. Find a few developers, give them the specs, and you’re off to the races. If you’re really lucky, had some vision, and great developers, you end up with a hit. More likely, you’ll end up with a crapplication, those apps that you use once and never use again unless forced. They’re difficult to use and really don’t help you accomplish anything.
This isn’t much of an issue if you’re building your app for the public, if they don’t like your app they will just find another one in Apple’s App Store or Google’s Play Store. On the other hand, building an app for your business and employees can involve huge risks. If they don’t like your app they will find alternatives that work better but may be less secure.
The question isn’t whether you should be building brilliant apps for your business (you should) or whether your CIO thinks apps are vital – they do. The question is: what are app development best practices for your business, and on what principles are they built?
You have to start with the four pillars whenever you are designing an app. It isn’t just something to go on a device, but an experience for the user that helps them get stuff done.
When you base all of app development on the four pillars and you add a dose of the business requirements to the mix, you are going to build a great app that meets your business’ needs. Identity Identity and access management (IAM) are hugely important when you are designing any experience. Who is the person using your app, and what should they be accessing? It doesn’t matter whether you are Facebook or an email app, you need to know who the person is that is accessing the app. This requires that you build interfaces for querying someone’s identity and that you have access permissions on your content. If you start with designing an IAM framework that your developers can plug into, then it becomes much easier for them to build an app properly. Security Most app projects take a dim view of security. They’ve spent years dealing with security “slowing” their projects’ releases, and they care more about meeting the needs of the business and hitting a deadline. This “slowing” is usually due to the fact that security wasn’t consulted until the end of the project when it was ready for release. This puts the security team in an impossible place. They have to figure out what an app does and then make sure it has a low risk. It is easy to see how this becomes an antagonistic relationship. The right approach to building an app involves Security throughout all phases of app building. The security team itself must strive to build frameworks and secure APIs so that developers are following secure principles whether they realize it or not. The only way for security to stay ahead of the needs of the developers and provide the building blocks that they need is to be part of the process from the beginning. As they understand the business’ and user needs, they can work on making those connections secure and less risky to achieve. The security team will learn that no isn’t the only answer, but that they have to say yes and show how to achieve that yes. They have communicate and work like partners with the business, rather than treating them like an obstacle course to get through when a project is finished. FUN principle FUN in this case is an acronym for Focus on the User Needs. Many times, especially in the enterprise, development is solely based around the business requirements. The user needs fall between the cracks. This isn’t just an issue with the developers, but also with the business itself. Companies are too frequently focused on the perceived outcomes rather than how the user works and what they need to get things accomplished. Developers need to insist on focus groups and user previews if the business isn’t already providing it. The lack of focus on users tends to lead to scope creep and monolithic apps that are difficult to use. Note: there is a difference between user wants versus user needs. User experience (UX) No matter how much work you put into an app, if it doesn’t have a great user experience , it will become a failure. There are too many options for your users in the OS app stores. If they don’t like the UX of the app you created for them, they will choose an equivalent app that meets their needs better. The fact that you can force your employees to download an app and ostensibly use that app leads to the rise of shadow innovation. Your employees want to get their work done and will find ways (other apps) to do that. You need to remember that in the end, mobile isn’t about giving them a device or an app, it giving them an experience which allows work to be done without hardware or software getting in their way.
When you set up your foundation for developing apps with these four pillars, all you need to do is feed business requirements in and watch as your team builds great apps that are popular among your employees. Remember, the goal of mobile is enablement, helping your workforce to be flexible and agile while improving productivity and efficiency.
