Excerpt

Created

December 6, 2019

Thumb (600x600)

Featured

Featured

Status

Done

When software first came out, you had to build work tools for yourselves from scratch. Then out-of-the-box solutions came to market which were already mostly built: business users just had to customize them and train the team. Recently, a new wave of tools have come into the hands of makers, and these tools have building blocks so that makers can design their unique ways of doing things.

When I first learned about these types of “no/low-code” tools like Coda, I got excited about the possibilities of what I could do with them, but quickly realized that I needed more skills and experience in building solutions to compete with the apps we were already using. So after 7years of working at software / service product companies and using out-of-the-box tools to run the company, implementing and customizing 50+ internal business apps, and building / launching over a 100 Coda docs across various use cases and client industries, I've begun to document what works and doesn't with internal apps.

It’s funny. You can work for a product company with talented product managers, designers, engineers, customer experience champions, marketers, and sales folks, and, unless you’re working at Salesforce or Atlassian, you're rarely building a product that you get to use daily. Instead, you use some other company's idea of what a CRM, project tool, or meeting app should be, all while having product rockstars on your team secretly (or not so quietly) thinking about ways to improve or change it. Their dissatisfaction results in wonderfully built docs and sheets, as those programs provide surfaces flexible enough for the people who are actually doing the work to build their own, unique way of doing things. And, with product skills, these docs and sheets feel so close to apps.

Unfortunately, these tools aren’t designed to scale or be connected in any meaningful way ー they come with the same building blocks and concepts from desktop word processors and spreadsheets 40 years ago.

Coda is unique in that you can take some of the simple affordances of docs and sheets, but you can build tools that work for your team: meeting systems, 1:1 trackers, OKRs connected to your product roadmap. See what the current community of makers are building in the Template Gallery, and if you have a keen product eye, you can start figuring out the patterns that work when teams design and build their own tools.

This guide is my attempt to elucidate the best business app patterns (and things I've seen in other's docs) and share how to incorporate those into your (soon-to-be awesome) Coda doc — a doc users love working in and stakeholders appreciate insight from.

But first, the patterns of out-of-the-box business apps.

Adaptable patterns of out-of-the-box business apps

What’s cool about most business apps is that they follow the same pattern for a successful user experience and system design that scales. Strip away the branding, any strong points of views that the software product company has infused, and the UI, and you're left with a core set of principles. Fortunately, when you’re designing your homegrown doc /tool / app, you can apply these principles into the unique way you do things:

1. A warm welcoming to and within the app with clear direction on the steps a user should take to interact and be successful with the app.
2. A set of database tables, the discrete things you’re tracking in the relational database.
3. Views, for different users. End users focus on taking action on their work and stakeholders see the big picture.
4. Information hierarchy follows a front stage for the workflow and a back stage for the setup.

1. Warm welcoming

Successful out-of-the-box business apps welcome new users across various channels with specific instructions and call to actions (CTAs) for how to be successful using the app.

EXAMPLES 👇

Salesforce

Salesforce has a starter home module that all new users drop in to on their first ーand until they change the settingー Nth time logging in to the app. This homepage includes help links and calls the user to Create (a client, sale, case). On the left, navigation guides them from the classic UI of Salesforce to the Lighting UI.

Asana

Asana sends a welcome email to all new users highlighting why you would want to use asana (it's a better way to work of course!) and then including three call to actions (CTAs) for how to get started with the tool starting with Create your first project which is what's going to begin the user on a successful journey. Onboarding emails with CTAs that link into the app are a common way to remind and support coming back to the same place to get the job done.

2. Everything tracked is a database table

Most SaaS business management applications are just pretty and easier-to-use relational databases that are branded. Under the hood, business apps are basically just a collection of database tables (RDBM), and the ability to create, read, update, and delete rows within these tables (CRUD). [4 years after writing this, Satya CEO of Microsoft says something similar]

There are a bunch of rules for relational databases that are pretty detailed and slightly dry, so let's go with 2 principles for now:

1. There are no duplicate tables in the app (on the backend). If you see the table twice in any app, one of them should be a view of the base table.
2. In a table, you order the core, unique, more important items on the left, the less accessed items to the right, and the actions on the far right. And the first column is almost always the key, and it must be unique to that row —i.e., no other row can have the same alpha numeric combo in it.

EXAMPLES 👇

Quickbooks

In Quickbooks, when an invoice comes in, that date is the most important item in the sales module of accounting software.

• Check box on the left is a common pattern for tables where the rows (invoices here) need to be "bulk actioned" like sending overdue notices to your clients.
• Invoice # which is the only unique column in this table, so it's the first column relating to the invoice itself.
• All details like the customer, and the amount follow.
• Status on the right is common as users take actions using buttons and drop downs after they have complete context (invoice date, customer, amount, overdue) of the situation.

Jira

Jira is funny because it hasn't changed much since its initial release in 2002 and is heavily used by engineers, so we get to see almost what a database looks like in this issue list.

• First column is an icon to tell us what issue type it is ー these icons haven't changed for a long time and Jira users often know what they are associated with, so Atlassian took the approach of using iconography over text to outline the type to increase information density.
• Key column is directly from relational database language and is the unique value in a row that can be used to reference it. While their actual database key is likely a Row ID in the Jira database backend, this key is the human-readable version which combines the issue number with the project name to create a unique reference (a trick of concatenating multiple columns to create a unique primary key).
• Summary, which is the core piece of information (though I've always thought this is more like the ticket “name” or “title”) is taking up the main visual space on the left.
• Assignee so we can easily see who's working on the issue.
• Status on the far right, similar to Quickbooks, so that we can take action once we have established context for the issue.

3. Different users get different views

Everyday users get a homepage to launch from with the ability to quickly add data.

This view gives end users immediate context for how to interact with the doc by creating a space designed specifically for them where they focus on their own work. Most end users will be adding data (usually related to themselves) and updating their own info, so creating a page for them will allow them to get in, do their work, and get out in the easiest and fastest way.

EXAMPLES 👇

Asana

This section, My Tasks, is a filtered view of the team's task table. Each user of Asana gets their own My Tasks list / board with a big button to add their own tasks. They don't have to worry about others and can focus on what they need to do.

Greenhouse

Greenhouse's user homepage, My Dashboard, is a customizable space with the core focus on filtered tables of the rest of the app down to what's assigned to the user: My Interviews and My Applications that I need to review. The right hand space includes Tasks, which are sub tracked items under Candidates and a secondary workflow. Greenhouse uses this homepage as an educational welcome space to with help resources similar to Salesforce's Warm Welcome.

Salesforce

For this user, a salesperson, the core focus is a roll-up of their team's performance against their sales goals. The main value-prop for Salesforce is for a team to move from multiple lists of clients and opportunities to one place for the team to update pipeline in the cloud (no on-premise software), so this dashboard makes sense to communicate that value.

In the core area are events and tasks that are assigned to the user that they need to focus on today - using both time based and user assignment to make these tables more focused. Recent records goes to search history given users often come back to the same clients and deals within a week. In the right space is Salesforce encouraging the use of Einstein, their AI bot, increasingly a value-prop for them.

Stakeholders (often managers) see reports with aggregate and highlighted info.

Folks who aren’t part of the core operation but essential to the success ー the Head of Delivery for client projects, hiring managers for applicants, VP of Product for the Product team, Head of Sales for Growth ー will want insight into how the team / process is performing. They want aggregates, summaries, and gists of what’s going on so that they can guide the team, ask the right questions, and make strategic adjustments where needed.

EXAMPLES 👇

Accelo

Accelo starts with aggregate single numbers, often called Key Performance Indicators (KPIs) which sit on their own. The number alone can start conversation where it's high / low, trending up / down. For managing directors of digital agencies and partners of consultancies (the key users of this dashboard in Accelo), work in progress measured in hours and dollars is vital to being able to bill and recoup effort as well as the billable % (often called utilization) for their team. KPIs are often put front and center in manager dashboards as they kickoff a meeting or report.

A project scorecard table allows partners to skim each project at the highest level (if there are less than 50 projects) with their project managers and drill down in if needed.

Greenhouse

Hiring mangers and the head of HR / People get to step through weekly / monthly an entire pipeline (Pipeline Stage chart) and then can see how the pipeline looks for each of the roles. Pipeline and workflow tools like ATS, CRMs, and manufacturing often have this design with a bar chart on top, with summary details below.

4. Information hierarchy: front stage vs back stage

Apps traditionally have a flow from top → bottom or left → right (as with most other things like how you read a document or navigate a website).

Generally, the pattern is as follows:

• Home page and personal space where every user starts off
• Reports for managers and stakeholders
• Team views for folks to collaborate and work together
• Admin and setup also known as the "back end" or "back stage"

EXAMPLES 👇

Asana

Home, My Tasks, and Inbox are all personal user sections. Reports for management. Team space with projects and tasks related to each functional area. Not on this navigation, but still calling out, that personal and admin settings are under the user profile areas.

Salesforce and Greenhouse

Both start with a personal workspace/ home, then move into All [insert unique object to that app] such as Jobs or Clients. Reports and dashboards for management. Then a back end admin and configuration area.

You can do it

So we've gone across the universe of business apps and their design patterns that make them stand out amongst their fierce competition. Now it's time to roll this new insight and understanding of the world (at least the business app world) into your own Coda doc.

Apply the four principles of best of breed business apps and make docs that users love, that scale as the operation and team growths, and that leadership sees as a key part of any organization.

Welcoming

A welcome section acts as the first place someone comes to a doc (so you'll share that URL with others). Start docs with the story: the best Coda docs read like "productized blog posts" and give a sense of what the doc is about, who it's targeted to, some of the key insights, etc. Like this one A delightful doc! It can take the form of a landing page, tutorial, README, User Guide, or FAQ.

The goal is to drop new users into a place that can give them context of what to expect in the rest of the doc.

Makers often include the following components:

Tables

If you look closely at most CRMs (Salesforce), Project trackers (Asana), applicant trackers (Greenhouse), or meeting management tools (Fellow) , they basically follow the same database and display patterns of their tables.

Incorporating these best practices in your doc will ensure that users will feel comfortable and use your "app" well.

Makers often include the following components:

Views

Within Tables, we were likely looking at a Base Table:  a core data table that powers your doc. For example, if you have built a CRM, your base tables would be Companies, Contacts, and Activities. A Product Roadmap would have Products to Launch, OKRs, and Epics.

You then create Views that are portals into parts (or if you want, all) of the Base Table.

Base vs. View Table Principles

The rule of thumb is that you should leave Base Tables alone as they are. Think of them as tucked away, all-inclusive, tables that drive the rest of your doc (learn more in Front / back stage).

Apply all your refining to Views:

• Hides columns in Views, not Base Tables. Hide columns in views, but keep all columns available in the base table so that when you or others go to it, they can immediately understand the full breadth of the table. You can always hide columns in the views of the base tables. In the example above, we are Content, Lots of Content, Scale, and Number within the view but keeping them in the base table. More on hiding columns.
• Filter Views, not Base Tables. If you filter a base table, that filter will apply to all other views. Also, it's just confusing to come to a table that should include all of the data (your customers, all product launches) and you can't find them. More on filters.
• Sort Views, not base tables. This isn't that big of a deal, but can mess up filters and other queries sometimes.
• Conditionally Format Base Tables, not Views so that all views can inherit those formats. Otherwise, you'll need to re-color each view. More on conditional formatting.

Types of Views

A view is a place for different users and stakeholders to interact with the doc from their point of view. These views take two forms:

1. User View
2. Stakeholder View

User View

Give a home-base for users to add and view their data. Here's an example below of setting up a place for users to add a bug that they find in the software.

Makers often include the following components:

• Create a button in the canvas to add new rows (with includes user being auto assigned to the new row).
• Right click the button to edit it
• Create a modal adding experience if there are a lot of fields by turning Open Row for Editing on.
• Use Layouts by clicking on the three dots in the popup window and Custom Layout to customize this view
• Change the information hierarchy by selecting the Quick Styles or by dragging and dropping the fields. Increase information density by placing fields side by side, especially if they relate to each other, users will be able to more quickly update and add data.Hide fields (columns) that don't pertain to adding a new item so that you don't distract the user.

1. Turn off Comments & Activities.
2. Turn off Allow Viewing Hidden Columns
• Create a button(s) to add / close / cancel the modal.
• These are normally placed in the bottom right of the popup modal and the trick is to make it a hyperlink button that "opens" up the current section that the user is on.

You can find fully-built example here's: Add new item user view

Stakeholder Views

You can share a section of the doc / data with stakeholders that are Views so that they can focus on getting insight and understanding what's happening in the doc.

Makers often include the following components:

Front / back stage

Use Sections and Folders to organize the different functions and areas of the app. Below is an illustration of a common pattern that we see in the docs; namely, there's a front stage and a back stage of the information hierarchy 👇

Makers often include the following components: