Apps usually follow one or two laws in the perpetuation once they have been developed. In the words of the grittier technicians: the slog is only half finished once the development is done. Personally I am sure many of you are equally up to grips with this fact as well but when we talk about maintenance, then we enter the messy realms of debate. Pertinent questions such as “is the UX needing change? “ “is the data secure” “are there any unexpected crashes” and the ilk appear. There’s already a stable field of usability testing that goes about rounding off these questions but who has ever heard of an application being completely bug free?
As one of my teachers told me, most developed work never gets to see the light of day. Between user needs, incremental features and debugging services, a lot of applications either get rejected abandoned or completely changed from what they originally were. The industry will probably have enough stories to fill us with regarding this matter. But all in all it’s a question that reserves much scrutiny. The better question to ask though is exactly why do some apps see the light of day and some don’t? Sturdy structures and flawless programming can never mean a good product in the market. There are some more subtle questions that need answering. The aspects I mention here though are some of the more critical aspects when we talk about application evolution.
Nothing and I do mean nothing can compare with triumph of seeing something like “221345 users are now registered on your app”. It’s a crowning moment: your work is accepted by so many users who came across it and even more have seen what you are capable of. It’s an awe-inspiring feeling, except that it’s a little misleading. How many of these users did you force into signing for your app so that they could reap value? In many cases such as online blogs or shopping need sign up in order to get the necessary information from the user, however smarter business models can enable us to derive value for users without needing them to sign.
Think of it in this light: I have not even used the app for 2 minutes and already all my information is being demanded. Also as a user, trust me when I say that there are few things app users hate more than sign ups, so give value to them before you ask them to sign up, otherwise you might be looking at some unhappy users.
Q: “So what does this tab on the corner do?”
A: “ It allows you to change your location and then list restaurants in the country”
Q: “But my service and agreement are just with the chain in this locality”
A: “ It’s an extra feature, in case you ever decide to expand”
The above conversation should not happen ever between you and your client. Any agreement you pack in the final product must follow a rigorous cycle of checks through the prototyping. There are features though that are not understood in prototypes, particularly the low fidelity ones which is where some features end up coming to the final version which were never intended to be part of use by the client at least. Within maintenance, run a check on the regular list of features. The client will not immediately be aware that a few features are not used at all within the app. If a tab is pressed only once or twice by certain users within a week and derives nothing “meaningful” for the user then that feature has to go.
When it comes to the smartphones apps, there are certain gestures in the touch screen which many users recognize as universal when they are interacting with smartphone apps. In many cases though, especially when we are dealing with data intensive apps, certain gestures need to be reinvented for certain features which can understandably cause a certain amount of confusion.
These gestures are not always deemed as troublesome or unsuitable by clients or owners of the application. User feedback built on a few months or even a year can sometimes generate this data and then you have to go about redesigning the gesture for that particular application. In iOS’s case, most gestures are standardized so this trouble seldom if ever arises however the maintenance aspect is all about evolving or changing the input method whenever the need deems it fit.