Best-Practice App Building Part 5: UX, or; How I Learned To Stop Worrying And Love The End-User

You get into an uber, coffee in hand. Driver asks “Where to?” You instruct him thusly, and off you both go. 

The driver, familiar with the route, and in command of the impressive car he’s happy to drive every day, couriers you to your destination in record time. He finishes his whistlestop masterpiece of speed and efficiency with a gentle skid, having turned his ABS off for the occasion; his attention is wholly on impressing you with how quickly he can get you to your destination.

Upon inspecting the passenger seat, he finds not a delighted customer, but the remains of what could only be described as an earthquake at the offices of Nickelodeon. 

In his enthusiasm for speed, and your best timekeeping interests at heart, the driver threw the car about like GTA V, forgetting, curiously, that the passenger might also wish to arrive in some comfort. It would not be enough to describe you as simply wearing your coffee.

What this allegory means, I’m sure we’ll never know.

Now, onto today’s topic - user experience! More specifically, attempting to create a good one. 

I am certain everyone reading this has used a website or technology which was useful and important, but was such a pain to use that resisting the urge to throw it was a triumph. This is what we mean by user experience; the freedom for a user to travel from A to B without feeling like they’ve just lost a complicated negotiation. 

There are three weapons in your arsenal against creating a stressful user experience:

1. Planning (shock. horror.)

2. Don’t Be Boring

3. Becoming Your Adversary

4. Testing (honourary mention)

Let’s discuss them individually. 

• Planning

We saw this one coming. Incorporating the anticipated user’s experience into a planning session is the salve that will soothe the largest number of potential problems, and will do so right out of the gate. An App is written to perform a task, but this task is still performed by a user - processes must be as easy as possible for the user to complete their goal. If the App makes life more difficult than using a different tool, then they’re just going to use a different tool. This is where Shadow IT (spoooooky) comes in, and will be the subject of another blog.

Planning the most logical process for your App, as we discussed in Part 2, will also generally map out the most logical process for your end-user.

Attempting to anticipate what the user will go through when using your App is never a waste, though it can go too far - as with all planning, never let decision paralysis create inertia, or you’ll never start.

• Don’t Be Boring

Similar to flooding your house from floor to ceiling, listing every Field, one by one, in a long column, would work. This would enable you to collect the data required. Just like copying out a textbook word for word might assist in learning the contents. The only (yet highly likely) cause of incomplete data collection would be the user falling asleep before all the data could be captured.

How, then, should you go about creating an App that does not require warnings against operating heavy machinery after use?

Make it interesting! With Softools there are all kinds of Fields that are both visually interesting and functionally more practical than simply listing information or bland data entry.

Image Fields

You can use Image Fields to capture information visually, or provide it to the user by default - already on the page when they arrive there. 

ImageLists

Need to present a user with some options? Rather than manual entry, or a Selection List, you can present the user with some more visually stimulating options which are also more appropriate than less interesting options.

You can take this a step further and integrate them into other elements of your Application; here you can see that a GridField has ImageLists to represent custom colourful icons.

Image Action Buttons

Need to navigate between Records? Visit external sites? Initiate workflow? Bam! Image Action Buttons: 

A familiar sight to many of you, the homepage for the Softools ABC course uses Image Action Buttons to aid users around the site. They’re so intuitive that they’re perfect for guiding users who are completely new to the platform.

• Becoming Your Adversary

This may sound a little dramatic, but you know what they say. You either die a hero, or live long enough to see yourself become an end user. At least, I think that’s how the saying goes. I’ll brush up on my Batman. Anyway.

Once you’ve planned your journey, theorised over what the fabled end-user may have to endure to navigate your masterpiece, and done everything in your power to temper visually engaging content with the purpose of the Application, you must attempt the journey yourself.

As with most things, testing the Application yourself is a valuable first step before letting a user anywhere near it. Put yourself in the shoes of your users and have at it. You’ll find anything at this stage, from typos to Fields in the wrong place to images not working, or parts of the process gone awry. 

There are so many things that can go wrong, expected or unexpected, that it’s always worth checking your own work before asking someone else to.

When you’re sure that everything was where it should have been, and all arms and legs were inside the carriage at all times, you must begin to think of your users, and their experience levels. Some users will be very familiar with the platform, some may not. The use of Russellian predicate calculus is optional at this point, but it’s worth considering the logical assumptions you take for granted when going through an application. 

If a user doesn’t understand the layout of the page, or even what a Field is, or is for, or what a Template is, or looks like, or the relationship between the two, then a process involving multiple Forms, Child Apps and Workflow is going to cause more harm than good.

Add as much help as you can, whether it’s Image Action Buttons that make the process clear and stimulating, Template Help Text that explains a process and requirements for a Template, or just using the minimum number of Fields, as clearly labelled as they can be. The more help you give them during the process, the less help they require outside the process - ie, emailing you for help.

• Test It

Last in order but not priority- testing. Once you’ve made your preparations as best you can, as with all Apps, allow some users to test it. The steps involved in testing were outlined in a previous edition, so we won’t go over them again here. Once a torpedo belt, always a torpedo belt. If you don’t know what I mean by this, then I fear for your App’s waterline (and highly recommend you read Best-Practice App Building Part 3!)

That’s it, really! Following the advice laid out in these guides, from Part 1 to Part 5, should hold you in good stead for releasing stable, purposeful Apps that keep your users and stakeholders happy.

Any questions, as always, feel free to reach out to us on social media (Twitter or Linkedin) - we’re always happy to help!

Best-Practice No-Code App Building - User Experience — Softools