Using QuickBase business applications to empower employees to solve their own collaborative work management and process management issues has been a long accepted and successful practice. However, that doesn't mean that you should just create your application without putting some thought into it. Even something as simple as a well-written email takes a little planning and effort, and QuickBase should be no different.
People have heard me talk about the apps that I have seen which are hideously deformed. Relationships randomly created between tables with no rhyme or reason, forms that lack any kind of formatting, duplicate fields running rampant. To combat this, I've found a few steps that are helpful when trying to avoid this dreaded “Franken-App,” and make something that will really last and provide a better user experience.
This can be a little counter-intuitive, but what I'm really implying is that you should start at the end. Many good writers talk about the fact that they know the ending to their story before they've even written the first page, and we're going to take that idea and apply it to App building. Before you start trying to build out forms and other methods to input data, find out what reports people need to get out of the system. If you know what sorts of reports people are expecting before you start, the rest of the planning process will be much easier.
We have talked a lot about the idea of Process Mapping here at QuickBase. Whether you take the steps I outlined in "5 Steps to Translate your Process into a Working App", or you jump right into tables and relationships, this step is always critical. Using the Reports as a baseline, you can often reverse engineer a strong schema for your table and relationship structure. From there you can use your process diagram, if you have one, to refine this and really nail down the right architecture to move forward.
Anyone who has seen a new house being built knows that the frame has to go up before you can start mounting light fixtures, and that you probably need drywall before you can hang paintings. With QuickBase, this means that you build your tables and relationships out first. Use the Relationship Diagram tool to double check that the plan you made matches the structure of your app before you attempt to start throwing reports on dashboards or playing with your forms. I know that making things look nice is the fun part, but trust me we'll get to that in just a moment.
Now that the Data framework is in place, and the schema is all tuned up and ready to go, it's time to put the polish on the application. For our customers who are traditional IT developers, partnering with business focused teams, this can actually be a good time to take a step back and let the actual users of the application take a little ownership. With the easy customization options available, I've had many people tell me that fleshing out the look and feel of the app is what they really enjoy about QuickBase. It's also a great opportunity for the people who will actually be using this to define exactly how they like to look at things.
Closing the loop on Step 1 by facilitating the output that you have documented can be an immensely satisfying moment. With QuickBase, this moment is often a lot closer than you think. I've worked with two teams that got through all of these steps in just 2 days. Just remember that different people like to see things in different ways, so make sure you create dynamic reports for every situation you’ve heard. Leverage the Dashboards and User Roles in order to serve those reports up to the right people at the right time. Users can take it from there, creating their own personal reports when they need something even more specific, allowing you to step back and take pride in what you've created.
After you've had a chance to catch your breath, remember that you can't just walk away and forget about this forever. Businesses are living breathing organisms that change every day, so once the app is up and running the next thing to do is to make sure that there's nobody sitting out there being quietly unhappy. I'm a huge advocate of collecting feedback from users, because nothing will waste more time, money, and become a management headache, than a team that doesn't want to adopt a new process.
Speaking from personal experience, there's nothing more painful and discouraging than spending your time and energy making something, only to find that people don’t like to use it. In order to avoid that feeling, I think we can all afford to take the time to think about these steps, and make sure we're really getting things right.
In my following posts, I will go over these steps individually so that we can get into more detail while showing examples of how to be successful at each.