Principles for Quick and Ugly Back-Office Application Design
Recently, Revelry has been doing some pro bono work to help Cajun Airlift. Cajun Airlift is a group of pilots and other volunteers who move cargo for disaster relief. The present situation for coordinating all of these missions is one guy with a spreadsheet who is texting like mad in order to make sure ground volunteers and pilots are all scheduled and kept apprised of what’s going on. We wanted to step in and make that easier for him.
With limited resources to put toward it, squeezing this in between our regularly paid projects, we dropped a lot of our tried-and-true process and set out to build a volunteer air logistics system, hackathon-style. Which is a great way to quickly build a prototype, but not always a great way to get a 100% useful application.
Even the most basic application design requires complicated problem solving.
The problem with going from One Spreadsheet To Rule Them All to a full-fledged application is flexibility. One easily-corrected-in-a-spreadsheet edge case, unhandled by an application, can cause everything to go sideways and send your primary user right back to Excel.
For instance, our app texts a number of different alerts, including flight updates for people involved in those flights. To do that, we need to make sure that we can actually text those users, so we make them verify their phone numbers first. But what if one of these 100+ volunteers doesn’t follow through on that? What if the pilot forgets to add their aircraft to the list after they’re approved to be a Cajun Airlift pilot? Does someone have to call them and walk them through the process again, to find those old text messages and click through?
As I think through and plug these holes, it occurs to me that there are some things I should have done from the outset that might have put me in a better position to launch the app, for real-world use, sooner.
Write the instruction book right there in the app.
This is an ugly, functional back-office app, not a shiny thing to put on Product Hunt. Explain what that form is for. Tell the users where in the menu to look. We can design intuitive controls later. For now, we just need menus, buttons, CRUD forms, and verbose language for all of them.
Empower the superuser.
Give the admin user superpowers to manually manipulate the database data (within reason) so that there is no reasonable record they cannot touch. You almost certainly missed something they needed in your main UI. If there’s a more direct-manipulation tool in place, you can hop on the phone with them and teach them a workaround so that business can continue while an application update is being prepared.
Everything should have an escape hatch.
Extend this principle to allow the superuser to do anything on behalf of another user that is reasonable. For example, I should let the admin add people’s aircraft for them. I should let the admin change their phone number. I should let the admin re-send the phone number confirmation text. I should let the admin verify their phone number on their behalf, in case they’re being too slow about it and I’m really really sure.
I wish I could say that I did all of this in the first place, but I absolutely did not. If I had, I wouldn’t be plugging functional holes right now, and this application would be getting cargo moved from Texas to Puerto Rico. But now that I have worked out this framework for defensive features, we can move forward more confidently to ship the app without that nagging feeling that something major is missing.
Revelry builds digital products to help companies scale, automate workflows, and deliver innovation.
Keep in touch by subscribing to CODING CREATIVITY.