Dynamic filters vs column filters in the Quick Base grocery store

I heard a great analogy recently Quick Base is like a grocery store. While a grocery store might have 40,000 unique items, how many do you walk in looking for, let alone purchasing? The grocery store is responsible for serving a very wide customer base and balancing the needs of the many. Of course, you can also go to a specialty store which only has a few hundred items but is much more likely to serve a niche much deeper.

As we promised in our Product Keynote at Empower2019, we are going to carefully be rolling out improvements to modernize our user interface. During this process, we plan on gathering feedback that spans 200,000 users, 6,000 accounts and over 100,000 applications. Spread amongst those is an infinite number of use cases that all require different features and have different priorities, just like all the customers in the grocery store. We want to be transparent about our journey, the process of gathering feedback, reconciling and assessing it, and ultimately share how we produce the product or feature that you experience.

To that end, I thought it would be interesting to walk through our rationale and bring it into the context of some new features for a real-life example. We start with a fact-based model that we use to first decide what we work on as a product organization. Among other things, this includes factors like competitive research, customer feedback, strategic goals, etc. This model drove us to decide to focus on the new table report we presented at Empower, before working on a new form. We believe this benefits the widest footprint of customers while also preparing us for more future compatibility. At the same time, we know there are some customers who would have preferred a new form first.

As we dive into a specific feature like new table reports, we must prioritize the features we plan to tackle. We use the same framework to do that, but at a more microlevel. Within a given feature, there is also a consideration of backwards-compatibility competing with innovation and moving the platform forward. After all, one of the reasons customers chose to use a SaaS solution like Quick Base is that they don't need to continually have teams of developers doing optimizations, enhancements, and bug fixes; they'd rather have us handle all of that. This requires a delicate balance for us. One of the most difficult tradeoffs in software is how simplicity competes with flexibility. For every feature we add, we need to think through defaults and decide if something is optional or not and how it impacts new apps vs existing apps. Unfortunately, we know we simply cannot build every feature to the exact specifications every customer requires. Our goal is to get as close as possible to benefit the most people.

Table reports are used over 100 million times per month. When we look at our builder or user journey, we know that most people are moving into Quick Base and already have experience with some sort of spreadsheet format of data (rows and columns). If they are new to software, their familiarity is probably with something like Microsoft Excel. On the other end is a database administrator, who is probably used to something like SQL Management Studio. So, this common format of rows and columns is crucially important for us to get right. We thought we would share two more specific examples of upcoming features and how we consider adoption and change management for those.



Note: Mockup subject to change

The first one is resizable columns. A highly-requested feature and seemingly as simple as it gets. We will be letting you resize columns on our new reports, but should those settings remain across browsers? Should those settings apply to all users? What happens if you shrink a column but come back to a report and there is a bigger piece of data in a record? What about different monitors? These are very difficult questions that we set out to answer. This required us to do research, talk to customers, and discuss it at Empower 2019. The way we plan to handle this is by having settings such as column width be sticky to your session. That means that if you view a report at your office with a 23" monitor, you can customize your column widths on a report while also having the ability to customize them differently on your 14" laptop. One option we evaluated was having column widths be manually set by the builder of a report and apply to all users who view it. On top of the extra effort associated that would take us away from building other things, the thought process was that this would be confusing for users because a builder cannot always anticipate their user's browser, monitor, and zoom level. That being said, we will continue to learn throughout early access and evolve our thinking as needed.

Even more interesting is the conversion from dynamic filters to something more relatable, column filters. Another highly-requested feature, column filters are more common and have significant advantages. We know that having both features was a non-starter for a never-ending list of reasons. Deprecating a feature, however, is a decision that takes careful time and consideration. We started with an internal power user group as a 'scream test'. Unanimously, the feedback was that the benefits far outweighed the risks of moving away from dynamic filters and onto column filters. Early on, we identified really the only two benefits dynamic filters have over column filters:

1. The ability to point & click for a filter. Column filters requires one more click to get to the drop-down menu when applicable.
2. The ability to have a filter that isn't a column on the report.

Mitigating both concerns was important, but we knew the second one was more difficult from an adoption standpoint. There are a few reasons we are confident in our decisions here:

1. We plan to have amazing collapsible grouping. Some of the scenarios that users may have needed dynamic filters for are reduced.
2. Without the panel on the left, density controls, and a better visual layout, we know that users will have a better use of screen real estate and adding additional columns may not be as big of an issue.
3. With resizable columns, users can customize their view.

Lastly, we plan to make these filters so helpful that most users will be happy with the tradeoff! To validate our findings, we conducted a survey during a session dedicated to this feature at Empower 2019. It was one of the highest attended sessions at the whole conference. We were ecstatic that so many of you came to share your opinions and feedback with us to help shape such an awesome feature. During the session, we held a live survey and discussed the results real-time. We also brought the results back to discuss with our developers and user interaction designers. One awesome confirmation of our hard work on column filters was that 92% of participants said they were okay with us transitioning away from dynamic filters, and onto column filters. An expectation of 100% is obviously unreasonable, but we were thrilled with the support we received.

For each of these examples, there are ten more things that we must carefully consider weighing the tradeoffs, costs, risks, and benefits. Additionally, the priority of how we choose these is important and each customer will have a different priority that is most near and dear to them. So, what are our promises to you as we modernize the user interface and, even wider, as we approach product changes in general?

1. We promise to use objective information and facts in how we make decisions.
2. We promise to spend ample time and take seriously quality control and regression testing.
3. We also promise to communicate via our release notes changes that are coming.
4. Most importantly, we promise to listen and consider your feedback.

You can expect to hear more about our new table component in coming months and we look forward to your feedback.