I’m the senior member of the Intuit QuickBase Support team and have been with QuickBase for five-and-a-half years. In that time I’ve worked with hundreds of QuickBase application managers to help them create applications for their businesses. I have a good idea what is needed to make an online database application successful. Unfortunately, I’ve also witnessed firsthand some of the biggest mistakes new application creators make when getting started with building a QuickBase app. In this article I’m going to discuss some best practices for first time app builders, and some of the pitfalls you’ll want to avoid. Let’s get started!
1. Map the Structure of Your Application
Translating your Business Process into Application Tables
Before you begin creating your application, you should map out the structure of your application. As a general rule of thumb, a good way to do this is to identify which “tables” you’ll need to create in your app. The best way to do that is to use a trick we refer to as identifying the “nouns” in your business process.
Here’s an example: Let’s say your company runs a call center and you have customers that call your sales reps to place orders for your product. Those same customers can also set up repairs if there is a problem with their existing product. Finally, your sales reps need to log an activity after each customer interaction. Every italicized word in the preceding sentences represent a major noun in your business process, and is something you’ll want to track in its own table.
Here’s a visual:
You can see how just talking out your business process and identifying these “nouns” will tell you which tables you’ll need, and get you well underway towards constructing the application.
2. Create Relationships between Your Tables
Understanding Table Relationships and Data Flow
Now that you’ve identified which tables you’ll need, it’s time to figure out how all these tables will be related to one another. This is where it can get a bit tricky, but this is by far the most important step in creating a functional app. It’s also really helpful to get a piece of paper and draw this out because seeing the table relationships visually will make it easier to know if you have them right or not before you build your app.
Let’s continue to work off the example I gave above. We’ve already established that we need a customer table. Each customer that calls has the potential to place multiple product orders, repairs, or generate call activities. In relational database terms, that is a series of one-to-many relationships (i.e. one customer can create many orders). If you look at all the tables you’ve identified as needing, you can start to see how they can be related to one another in this one-to-many structure. The one is called the master table, and the many is called the detail table.
A common mistake many customers make is they create dozens of relationships between tables without really considering whether or not the relationships even make sense. Your app can get very cumbersome when you relate the same two tables together multiple times, and in both directions. Try and avoid doing this, and instead take the time to map out how the relationships should actually be set up.
Another thing to consider when creating relationships is how your data will flow between all these related tables. Data always flows down from the master table to the detail table. If your goal is to create a report that contains data from two separate tables, for example a report that shows all the orders created by a specific customer, then you must create that report on the detail table because you can pass data down from the master to the detail via what’s called a look-up field.
Here’s a visual of a relationship:
3. Elicit End User Feedback
At this point you should have a pretty good idea of the overall structure of your new application, but try and refrain from building just yet! This next step is something that many new app creators almost never think to do, but can make the difference between launching a great app that your users will love and quickly adapt to versus an app that they may struggle with and become frustrated by.
Before you start creating your app, identify a few key employees that will be using your app and ask them what it is that they like and don’t like about their current process. Ultimately the app you create is going to be used by these people, so it’s important to identify early on in the build process what the app will need to have for them to successfully do their jobs. You can even take it one step further and sit with some of them as they work, and pay close attention to their workflow.
- Email Users. Maybe you have a user who works heavily out of emails. That will tell you that launching an application that makes use of email notifications, subscriptions, and reminders is going to be very important to this user.
- Excel Users. If another user relies on Excel spreadsheets for data entry, which columns in that spreadsheet are the most heavily used? By identifying that you’ll start to see which fields, reports, and forms are going to be important to have in your application.
- Managers. You probably have managers that only need to use your app to view reports about critical metrics in your business. Use that as an opportunity to create a highly functional home page for your managers so they can quickly access the data they need.
As much as you think you know what your employees do every day, I promise you that sitting with them and watching them work will bring to light some subtle nuances that you weren’t aware of, and incorporating that workflow into your new application will really impress your users, and make the transition to using your app that much easier on them.
4. Establish Alpha and Beta Periods and Involve Users
At this point you’ve planned out your app enough to start building. As you build, you should think about building your app out in stages, like it has an alpha and a beta period. Let your users see the app as it’s in progress and give them the chance to provide their feedback at this point. It will be much easier to incorporate their feedback now than it would be once you launch and they start entering live data into the app.
A common mistake many app builders make is they build out an entire application, launch it, and then force their end users to completely change their workflow based on the design of the app. At that time the application will start to fill up with real data, and if it’s necessary to restructure the application to make it work better it can be very difficult to make changes of that magnitude as your users are trying to use the app. It’s best to collect feedback early, make incremental changes based on that feedback, and then launch a completed app that won’t require many changes going forward.
5. Launch the App and Turn Users into App Managers
Once you and your test users are happy with the app, it’s time to roll it out to your organization. If you’ve followed the advice above, it will no doubt be a huge success and your users will love you for it! At this point, the users that gave you their feedback during the build process have hopefully become DIY application advocates themselves. Why not consider giving them rights to create their own apps? Once you designate other app creators, you will start seeing great apps created that will tackle a wide variety of business processes across your organization.