First Step to Avoid Creating an Ugly Business Application with QuickBase

Here is my first detailed post on the steps that are helpful when trying to avoid the dreaded “Franken-App,” and building a business application that will last and provide a better user experience.

Document the output that people need to see

In many of the applications that I have used or built, I have noticed an interesting difference between how a user interacts with a system while entering data, and how they then view and use that data once they have captured it. The input typically requires clean looking forms and an intuitive interface, and can be designed during the build phase with feedback from users on usability. We’ll talk more about that in a future post, but to start out it is the output which will actually dictate the architecture of your QuickBase app.

Collecting Perspectives

In order to get the ball rolling on this process, I recommend talking to at least one person in each of the roles you expect to interact with this application. Ask each person how they would like to see this information once it has been collected. You may hear about the Calendar that someone needs to look at in order to determine what items are on their to do list for the week, or you may find that an executive really needs to have a pie chart with a breakdown of a budget by categories. Remember to be thorough and ask for an in-depth look at what is critical to each persons’ job.

Being this fastidious now might also come back to help you down the road during step 6, when you are asking people to adopt the new application and give feedback. They will know how far you have gone to learn about their needs and this should give them greater confidence in both the application as well as the feedback process. It also plays a big part in managing expectations during the change process.

Map the Touch Points

In addition to listening for different reporting needs, you will also want to pay close attention to how people expect information to reach them. Some situations may call for a report to be emailed instead of viewed on a dashboard. Other situations may not require a report at all, but instead, a simple notification that something needs to be done. Only by understanding all of these scenarios will you be able to properly build your application.

Make a List of Requirements

At this point you should have a pretty good idea starting to form of what the scope of things looks like now that you know what everyone needs to get out of this system and how they want to view it. If you still feel a little unclear as to how you are going to start planning the structure of your application though, at this stage you might not be as alone as you think. I have had many app builders get to this stage, only to tell me that they are not seeing a framework that will work for their application. In order to take your research and make it more useful it’s time to start putting it all in one place.

If you’re like me, you have a ton of notes all over the place, so if you haven’t put all your notes into one single list, then start there for now. Once all the different outputs that people will be looking for are in one list, you can start categorizing them by their similarities.

This

Can Turn into This

List of Projects with Status

Graph of Projects by Spend against Budget

Timeline of Projects by Week

Projects

By Status

By Spend against Budget

By Week

Identify Common Data Types

Once you have your lists organized, it is now time for some hard work. Your job here is to look for patterns and commonalities among these reports, and use that information to start making a list of fields and tables.

As an example, let’s say you are working with an executive who is expecting a high-level overview of all the projects for his company, broken out by department and with a clear indication of which projects are over budget or in danger of not reaching their next milestone on time. At the same time, you are also working with an individual contributor who will be using the same application and needs a calendar view of their assigned tasks, what does this tell you about the tables and fields which you will need?

In my next post, I will go into depth about how you can turn the information you have just finished gathering and analyzing into a working data model. If you feel confident that you know enough about databases already, your homework for the week is to map the tables and relationships necessary to support the scenario I just described.