Best Practice App Building Part 4 - You Have a Plan, right?
The App is built. The day is won. You sail off into the sunset, victorious, contented.
A few years later, you return to visit your creation and bask in the glory of grateful users. What greets you, though, is not the polished utopia you left behind. Instead, what greets you is the App equivalent of Lord of the Flies, as told by the directors of Castaway and The Road. The few remaining users sit around a thin campfire with a thousand-yard stare.
Where did it all go so wrong?
You didn’t think you could just fire-and-forget an App, did you?
There are so many reasons why abandoning an App once it’s completed can only doom it to fail. Like tending to a garden, Apps require maintenance over time to remain perfect.
Build it, and they will come. Stop building it, and they will leave.
User requirements shift. Hardware changes and new hardware technology can change the way things work. New features can make old ones redundant. Or, the business need may change, in response to a changing economy. An App is only ever as successful as it is suitable, and nobody will use an App that no longer works.
The upkeep on an Application can be surprisingly stiff, particularly if the App is new. A released Application is not a first draft, per se, but it is a first version of sorts - it’s the first version that the users have been exposed to and used for its purpose. Often you’ll find that in the theory stages of planning an App, the reality of using that App is impossible to predict. You may find that after some time, users have a list of changes that need to be made. Whether it’s things not working as intended, or that don’t quite achieve what they were initially supposed to, or a necessary feature previously not thought of, Applications should never stay static. More often than not, feedback comes along the lines of “This is so fantastic it made me think of something even better we can do with it!”
The process of keeping an App well-oiled and singing is what we call App Governance. A process of governing an App such that it still works and provides value to your users over its lifetime.
As always, the best way to avoid disaster before, during, and after an App is completed? Planning.
Here are some key steps in App Governance that will not only save you headaches, but time, money and grey hairs.
Agree key dates for the App release with relevant parties (stakeholders)
This will give you measurable, achievable goals to work towards, and the freedom to plan around challenges and obstacles.
Confirm dates for App Reviews with relevant parties after it’s out.
These reviews will allow you to take feedback from users, as well as stakeholders, to determine whether the App is still working as required, in all ways. It will also allow you to begin to plan any work required to improve or maintain the App. You can incorporate new features, discuss new Apps, or fine-tune existing elements.
Be careful when playing with live ammunition
Making changes to a “live App” (when users are, well, using it) can cause serious confusion. Be considerate to the poor little things, and make sure that intention to make changes is scheduled, announced, and understood, particularly by those whose process is likely to change as a result.
Softools develops new Apps in 3 stages (revisions), which we call R1, R2 and R3. R1 is a “Hey, waddya think?”, R2 is an improvement of this initial proof of concept, and will be subject to user testing for an agreed period of time. R3 is the “final'' revision of the Application, after which any change is subject to further review and agreement.
This way, all parties know what to expect, and when. This is particularly handy to users whose experience may be vulnerable to the shifting sands of no-code versatility.
When establishing the process for presenting ideas for improvement, review, and change, there is no minimum or maximum timeline.
“To improve is to change; to perfect is to change often; to annoy is to change way too often. ”
Log suggestions for improvement for your Apps, and always think to innovate, but - let your users have time to breathe, and to get used to a process. If their App is changing all the time, even if the changes are good, it may become counter productive.
User feedback is gold, but don’t forget, not all feedback is useful to the overall project - a user may have a valid critique of a certain element, but to do it differently may not be possible, or may compromise the experience of a larger number of users, or other App features, at the expense of a smaller one.
The beauty of no-code App building is things can be done when appropriate or convenient, no need to book costly coders. The process can be whatever you choose, but do have a process, and stick to it.
And, as always, you can talk to us. If you need any advice, feature requests, or want to make some more complex changes, you can just drop us an email. We’ll show you how, teach you how, or do it for you.
That’s the theory, what about the practice?
We use an App to keep track of all to-do items whenever we’re working on a new App, as well as any upcoming dates, plus changes or developments that have taken place, and when. This allows us to stay up to date and share information between teams, and, crucially, know what has been done, by whom, and when.
This is particularly important if you ever need to pick up a project after being away for some time. Not remembering how far through the App’s construction you were made for a rather confusing return, and more time wasted trying to remember where you were, rather than working on the next steps.
Or, worse, somebody else’s App is assigned to you. This can be for a number of reasons, like a colleague leaving the company. You’ve inherited their project, and zero notes. No governance. You don’t know what they’ve done, or why they did it that way, or how they did it.
On that note, where desirable, involve the stakeholders in the construction of the Application - if it’s useful to show a work in progress, do so. They may have good input for the design process
Finally, if you’re building for a group or individual that will take over the maintenance of their own App, make sure that their administrators know how to make changes, how to manage user permissions, and make sure they know this! Whenever there is a change of the guard, the guard needs to know about it. If the customer thinks you’re responsible, and you think the customer is responsible, you can end up with a Mexican standoff of snooze-worthy proportions.
That’s it for this week’s instalment of Best-Practice No-Code App building. We’ll return the week after next with the final part - User Experience, or: How I Learned To Stop Worrying And Love The End-User
