Hiding Simplicity, Enabling Complexity
Developing apps for smartphones requires careful consideration of many factors. We are constrained by issues such as limited memory, slow processors, and small screens on some devices. We also have to account for the expectations of users, which generally amount to “it needs to be fast” and “it needs to be simple”.
The former is mostly an engineering problem, while the latter is largely a design problem and – arguably – a trickier proposition. In an interesting paradox, the simpler you make an app, the more complex it can become to design.
Removing simplicity means hiding details away from the user and having the app account for a myriad of different scenarios. These scenarios are often called “use cases” and explain situations like “If the user has a limited Internet connection, and they try to use this feature, how long do we wait before retrying?” and “How many times do we retry before we alert the user?”
As a project evolves and these use cases are expanded, we often run into what are known as “edge cases”. These are scenarios that a small fraction of users may experience, and require a very precise and unlikely sequence of events to occur. But however unlikely, when a user does experience this edge case and it hasn’t been accounted for, it leads to a poor user experience, and possibly a poor rating in the app store.
Finding the edge cases
Discovering edge cases is not a simple task.
Before any feature is worked on, our Product Director walks through the feature with our client, to make sure we understand what is being asked for and who the primary audience is. He then comes up with an initial solution, and sits down with one more or more team members to walk through the solution. This always brings up at least one scenario that had not been accounted for, if not three or four.
But even with the most careful and considered analysis of how a feature should work, the trickiest edge cases may not come up until the feature is actually being built and tested. Thankfully, knowing there are things we don’t know yet is half the battle. This means we attack our features ruthlessly with the desire to make sure no stone is left unturned.
We have even gone so far as to acquire a Faraday Cage so we can test our apps in circumstances where the phone’s WiFi and network were on, but absolutely no data was getting in or out. This is a different scenario than if the user has turned off their data connections.
Of course, the ultimate test is when the app is released to the world, and in the hands of actual users. We plan, execute, and test thoroughly, but nothing can stand in for true real-world testing by actual users.
Getting better every day
As a business, our goal is to be better every day. The more edge cases we find, the more they end up becoming a common case that is easily solved, and the more solid our apps become.
We work on apps where people’s banking information, personal information, and even lives, are in our hands, so every edge case we find and account for makes a real difference to the world.
