Best-Practice App Building Part 3 - Soggy Deckchairs: You did TEST it, didn’t you?

You let go. Chilled champagne sails through the air and breaks into a million pieces in a cloud of glass and bubbles on the bow of your brand new ship. The brass band begins to play. Ropes are cut. Thousands of tonnes of sovereignty and hard work begin to slide down the slipway. With a raucous cheer, the gathered crowd watches as your vessel glides into the water like a swan. And keeps gliding. And a bit more. And it’s not stopping. Oh. Oh that’s not good. Did it…? Yes. Yes it did. The ship has been replaced with a flurry of bubbles, bunting and floating deck chairs, all your hard work filling with water at the bottom of the harbour. The brass band never stopped playing. The crowd is staring.

How awkward.

You did… You did TEST it, didn’t you? You didn’t launch something without actually checking whether it worked first… Did you? Oh dear. You did. Well, better luck next time. 

That would make for a short blog, wouldn’t it?

Welcome to Part 3 of the series of blogs covering Best Practice in App Building

So, how do we stop your App getting soggy deckchairs? You’ve worked out your outputs, you’ve put in your inputs and decided on a process. What else is there?

There’s a journey from A to whatever your letter of choice was (sorry if it’s A). From input to input, and process to process, and even in how your outputs are presented. Nothing happens in isolation when it comes to being on an App as an end-user. 

An App can work perfectly, fully as intended and look brand-spanking-new at the end of it. Except there was a typo in your Templated Report Field References, which you not only didn’t spot, but left in the final product. Just one. And it’s broken the whole report. Users logged into your App, breezed through the process like greased otters and came out the other end smiling. Proudly, they clicked Export, and… Soggy deckchairs. The whole thing broke. The users don’t know why, and now instead of cracking open a celebratory bottle of scotch, you’re getting emails at 4:30pm on a Friday, begging for help, and you’re trying to work out why your expensive violinists are drying out their socks in the middle of the Atlantic. 

When building an App you must be both the brilliant architect, and the clueless end-user. Life must be made as easy for users as possible, and then, when the time comes, you must walk a mile in their mismatched shoes - Yes, actually use your own App. Create a test-user, log in, and use the App as intended. Check that the inputs make sense. Check the process works. Check the function of the App as well as the form - do you have any Expressions that go on to perform some complex wizardry you’ve cunningly employed? Did they remain both cunning and employed from start to finish, or did something break half way and leave you wringing out your hair on the dockside?

Once you’ve established that none of the furniture is sliding across the dining hall with a 15 degree list to port, it’s safe to proceed to the next step - inviting test users onto the site. Beg, borrow, steal, or bribe a friend, fellow app builder, or concerned but helpful party (like an end-user for whom the App is intended) and sign them up. Ultimately, a great test-user is an experienced App builder who knows common issues and where to find them. Better yet, if you can find one, employ a total novice. Ideally, this novice would be one of the target users for the App when its finished and frolicking in the summer meadows of its completed state. 

Like a pro, you could take the whole thing one step further, and plan how you’ll test your App during the early stages. Knowing what you want to do, and how you’re going to test it, in advance of creating it, saves yet more time and effort - It may also highlight flaws in the design process that you might not otherwise have noticed until it’s too late. After all, if it can’t viably be tested, can it viably be used?

All of this is what we refer to as App Validation - like Field Validation, it’s part of a check into whether something is working for us rather than against us. App Validation checks whether your App is fit for purpose. But it also provides one other key thing that you ought to rely on heavily. User feedback. 

Good user feedback is a fantastic experience for all involved. The planners, the builders, the stakeholders, and the user who had no problems. Thumbs up all round. The ship didn’t sink. Everyone’s socks are dry.

Most other kinds of feedback are varying degrees of, well, “negative feedback”. While it can be euphemistically referred to as positive criticism, in practice, it’s never really a euphemism, but a powerful ally. Receiving bad feedback may feel like the lucky shot that sank HMS Hood (I’m still not over it, I know you can tell), but in reality, feedback of all sorts will act as a torpedo belt that saves the ship*.

Even so, consider that dodging a torpedo isn’t always the best course of action. If doing so causes you to ram another ship, or ground yourself, or hit two torpedoes instead, taking the hit on the chin is your best bet. By which I mean, user feedback is only as deep as the user’s experience - Their comment on something not being as they’d like might not be couched within an understanding of what can reasonably achieve the goal in question, or what they prefer may compromise another part of the process. 

With this in mind, always listen to user feedback, but it’s your choice as to whether it’s actioned. As the App Builder, you will know more about what can and cannot be done, or whether a particular practice is superior to another - and why. Use, or discard feedback, but ignore it at your peril. Ideally, when discussing feedback with the user, explain why the element of the App in question is the way it is, and if their feedback isn’t valid, why that is so. Or, why they’re brilliant, and their active involvement has just improved the project!

At the risk of utterly over-labouring my barrage of naval comparisons, I shall venture another volley. 

Apps and battleships are similar in several principles; they take many people to work optimally, they can serve as force multipliers, and generally represent a major effort to both construct, maintain, and sometimes keep afloat. In the case of an App, a torpedo is some event, breakage of process, or general failure that creates what we call a “blocker” - something that completely prevents the user from either progressing from their current stage, or using the App for its intended purpose at all.

Blockers, like torpedoes, are bad, and your only protection is good preparation.

Feedback is an armour belt preventing torpedoes opening your App below the waterline, to be lost at sea with all hands and no small amount of your self respect. Feedback is how you improve your App in ways you never considered. Features and processes can easily be overlooked, left out of App specs, not thought of by anyone before that point, and generally two heads are just better than one. What works on paper doesn’t always work in practice, and user feedback is what gets you from what you created to what works for the user. After all, never forget the mission - to create an App that, yes, is as the end-user desired - but it also needs to achieve their goals. The task is to do more than simply create an App. Apps are tools that bring about an outcome - a means to an end. 

Speaking of ends, here we are! We hope you’ve enjoyed this blog, and we’ll see you next week for Part 4 - You have a plan… Right?

*Dear naval enthusiasts - I know a torpedo belt wouldn’t have saved the Hood but much like the Bismarck I was on a roll