Best-Practice App Building Part 1 - What are you even doing?

Congratulations! You’re a newly-qualified App Builder. You may have completed Softools’ world-class ABC App Builder training, and may even have made it as far as the vaunted Risk 3 modules. You know how to build Apps. But do you know how to build Apps?

You can put some Fields on a Form and they’re in a language a user can read. So what? Both a poet laureate, and a school child, can put words on a page. The difference between a collection of Fields, and a functional App, is in the execution.

In this blog post we’re going to cover some best-practice principles of App Building, as used by Softools, to get the most out of your App Builder experience. Whether you’ve been formally trained, or self-taught, these principles can help improve your App Building skills. 

                       Part 1: What are you even doing?

So, you need to build an App. Well, why? The first and most important part of the App Building process is understanding what the App is for. 

Ultimately, an App is a tool that you need to perform a task, and the process of building an App begins with how you define this task. Break it down into steps, determine how you’re going to gather the data to fulfil these steps, and do so in a logical way that doesn’t get any of your users lost or disturbed in the process.

Those of you that have completed ABC will remember that, largely, designing and maintaining an App can be broken down into four elements: 

• Deciding Outputs - What’s the App do?

• Creating Inputs - Orchestrating the Process

• App Validation - Does the App actually work?

• Governance - So What’s Your Plan?

We’ll also be discussing an additional element that was touched on in the course; user experience.

User experience is an oft-overlooked part of the App build process. It’s not strictly necessary, but we can tell you first hand that building an App people love to use is far more rewarding (and efficient for the end-user!) than simply getting something out of the door, kitchen sink and all.

                                     1) Outputs

It may seem counterintuitive to consider the output of an App before the input, but it makes sense - after all, knowing what you want to get out of the App will determine what goes into it! An App designed to capture user sentiment towards a reforestation project will probably not require Fields for map coordinates to the wreck of the Bismarck. Probably, anyway. We don’t judge. 

Consider the type of data you need to output; are you using Templated Reports to produce formatted documents? Which pieces of information need to be captured in order to produce this report? Do you require graphs or charts? If so, do you require data separate to the rest of the report to acquire the data needed? How will these be formatted? How do you need to arrange the Field References in a word document to be able to create this output? 

Are there any security implications or requirements you need to understand before beginning the input design process? It’s common for an App to have parties that may not see data either before, during, or after an inputting process. Take an employee performance review app, for example. It would make sense for the employee to be unable to see the management team’s internal comments on this document. Therefore, as part of the output considerations, template or record visibility rules need to be put in place so that certain outputs are only visible by certain users.

Next, consider how your outputs will look across devices. Softools works on mobile devices, tablets, laptops, and desktop computers. These screens all have different dimensions and properties, and due to responsive page designs, they all respond slightly differently depending on the App at hand. This will be covered more in App Validation, but is part of the output process, too. The validation of an App is about finding things that are not working as intended, while checking what was intended. At the output level, you should aim to solve errors and problems before they ever occur.

Accurately planning an App before you even start will save you time and pain in the long run. Particularly so if there are many users, and the App is of particular importance to a project or business. A cute To Do list App will not carry the same need for scrutiny as a process audit app, or a suite of apps for onboarding clients and suppliers. Planning is so important to us that we’ve partnered up with Skore, who specialise in process planning & mapping software. Complex Apps require complex planning, but that doesn’t necessarily mean the planning process has to be difficult. With the right information and the right tools, planning the App can be an incredibly rewarding experience, which will pay dividends when the App is executed as planned, and works as intended - you foresaw the hiccups before they ever happened and wrote them out of the proceedings. Sit down with stakeholders (anyone who has an interest in the App and its use, or the people who will use it) and discuss what they need the App to actually do. They may rely on your knowledge of the Platform to understand what can and can’t be done, and how it could be accomplished. 

One way to measure how well an App functions is how well it tracks Key Performance Indicators, or KPIs. These will be defined to you by stakeholders in advance, and if they aren’t, that just means you get to decide what they are!

In a nutshell, if your App is designed to, say, track financial performance throughout the year - the clarity of the information within the App, the level of detail it contains, and the accuracy of the information going into it, will all be part of a system of KPIs. If this App clearly shows the desired finances over time, in a way that is accurate, and measurable, then you have Key Performance Indicators that you can track - and the App is fit for purpose.

That’s it for Part 1, keep an eye out for Part 2 next week, entitled: How are you going to do it?