Who are developers?
When we think about software developers, there is often a specific image that comes to mind of someone with their nose buried in a computer screen with lines of code scrolling by. We firmly believe this stereotype is no longer true.
These days, everyone is a developer, even if it’s only of a spreadsheet or of content. There is a huge opportunity for many of us to improve our development capabilities and solve valuable problems for our businesses more quickly and effectively. The value of a no-code platform like Quickbase rests in the fact that it can empower anyone to develop a problem-solving mindset; to play an active role in shaping and optimizing the way day-to-day work gets done. Anybody willing to learn Quickbase will see higher productivity and efficiency when employing an app, and potentially receive recognition that drives career advancement.
When we build business applications with Quickbase, it’s tempting to dive right in and start customizing a form or put together a report before thinking through all the needs of a new application or process. This usually results in an app that needs constant revision, an app that can’t scale with growing needs, or both. So how can you ensure that you plan your database like a pro and make your application a success?
Think like an app builder: Use an app building framework
We’re going to introduce you to an app planning framework with three simple steps: requirements discovery, process documentation, and data modeling. Follow these three steps with every new application and you’ll not only save yourself time, but launch that app sooner.
Requirements Discovery
All good app planning begins with discovery. Discovery is where you gather all the requirements the given group has for an app. During discovery, you are learning the process inside and out. Keep in mind that even if this is for your own team, you want to be thorough and ask questions you think you know the answers to already.
Good, thorough discovery helps you establish the right app structure the first time. A discovery done well leads to:
- Clear understanding of an app’s purpose
- Sharp focus on the true process challenges
- Uncovering hidden or unrealized requirements
You need to establish:
Why: What current shortcomings and limitations exist with the process? Why isn’t the process more efficient? What returns do you hope to gain? You may find that you need to ask “why” several times before arriving at the root of a problem.
Who: You’ll want to identify who is involved in this process, directly or indirectly. You want to outline all contributors and their roles in the process. Focus on who is actively supplying and entering data, who is updating and changing data, who is viewing and consuming the data.
What: List what actions these contributors take during the process, such as what data is entered, modified, viewed, shared and consumed. Even if this process isn’t remotely like what you do in your own daily job, you should be able to picture it in your head once you’ve asked the right questions.
When: You’ll want to understand when these actions are taken. There’s a specific sequence, or perhaps several sequences, that comprise a larger process flow. You don’t necessarily need to piece together a process flow step-by-step during the initial discovery, but ask enough to understand the sequence of events so that you can recite the process correctly to the group who will use this app. And as I’ve mentioned before, if this is your team’s process, you may be tempted to take shortcuts because you know the process, but since you’re trying to improve it, leave no stone unturned.
How: Finally, you’ll want to understand when and how contributors take those actions. What tools are they using to capture data? Think about where they are when they capture, change, or view data. Is this at a computer in an office? At a remote location? Do they use phones and tablets in the field at any point? Do they capture notes on paper and translate that digitally later, or perhaps store info in spreadsheets?
Process Documentation
Processes are everywhere, in all aspects of life. We learned in the last section that identifying the true goal of your application is a critical component to app planning.
Process Documentation is a way to begin documenting the steps that are involved to help you put structure to the notes that you took during the discovery phase of this App Planning Framework.
The steps or tasks that you document will typically fall into two categories, and we suggest you include both when planning an application. The first type of tasks are the Human Tasks. These are the steps that people will tell you about first during discovery, as they are typically manual. The other type is the System Tasks, the steps that are automatically performed by some type of software today. It’s a good idea to make a note of what system is already involved, as that may not need to change.
The two most common ways that people represent processes are with a list or with a map. There are a couple advantages to using a map rather than a list:
- It’s easier to represent decision points, but you could also envision this being an approval process where you’re signing off on something or not
- Parallel work streams can be documented with more clarity
Processes can be documented at various scales, from very detailed to large groups of steps. This can be useful when thinking about the user experience of an application, as you will start to see how a person would interact with each page that you put together.
Keep in mind, when looking at a large process with many roles and systems involved, it can be almost counterproductive to go into too much detail. Instead, it’s possible to represent smaller groups of steps, as an individual component in a much larger process.
Process documentation is very useful when trying to identify the scope of an application, and remind yourself of the higher level objectives involved. Once you’ve completed your process documentation, you’re well on your way to thinking like an app builder and creating an awesome app!
Data Modeling
Data modeling is simply a way to structure and organize your data. It provides you with a structural foundation, in graphical form, that you can use as you build your app correctly the first time.
So where do we start? How do we make sense of our data?
By simply observing the language used to describe the business problem we are attempting to solve; by looking for the nouns – the people, places or things – that are used.
As you observe the words used in the responses to your questions in the discovery phase, and the commonly used words or phrases seen in the process documentation phase, you will begin to see patterns or trends in the language. You’ll want to start grouping terms based on what they’re describing.
Below is an example of data used in property management. Through discovery, we’ve learned that the terms buildings, apartments, tenants and leases come up often, so those will be our groups.
Next, we want to list repeated terms underneath the group to which they belong. So when we hear address, we can assume this refers to the idea of a building, and a Start Date would likely correspond with a Lease.
By doing this, you’re essentially informing what Tables you will need. If you haven’t built a Quickbase app yet, just remember that Tables are a main component of an app, and outlining these before you build is the best way to save time and ensure proper structure.
Don’t let the term “data modeling” overwhelm you – we already do this every day. On our computers, we all have created file folders to structure and organize our data so that we may search and retrieve what we’re looking for quickly and efficiently. This way of thinking is no different!
5 steps to take now
You may be eager to get started and jump right into Quickbase and begin building, without taking the time to plan their application, but we have found that without proper planning, apps can quickly grow out of control as more functionality is added and the app evolves over time. This can make applications difficult to manage as they become more complex. Here’s what to do now to think like an app builder, even if you aren’t a pro developer:
- Pick a Problem to Solve
- Document the Situation
- Visualize the Process
- Identify the Table Structure
- Implement the Model
