Data And Models that Behave Like A Considerate Human

Can a data table or calculation model be designed to be either courteous or rude? They certainly can! Designing for courteous and considerate is a guiding principle for enhancing usefulness of these products –helping customers get insights from their data whether these users are expert or non-expert.

My long-time guiding principle: Data, models and dashboards should behave as would a considerate human. I notice this remains fresh and intuitive based on people immediately nodding their heads in agreement. This is true 20+ years after Cooper et al. published their “designing considerate software” inspiration as a chapter in their renowned book now in its 4th edition, About Face: The Essentials of Interaction Design. Quoting from the 2nd Edition (2003) chapter’s opening paragraph:

If we want users to like our software, we should design it to behave in the same manner as a likeable person. If we want users to be productive with our software, we should design it to behave like a supportive human colleague.

This is sage advice. Cooper et al.’s teaching anticipates current AI software that starts to closely resemble “supportive human colleagues.” That’s a hot topic, but I will focus here on user interface principles for great data products and models that encourage teams to get insights – leading to being able to scale these models and use the fruit from that to grow their business.

A warning at the onset: You can’t unsee this. Software is everywhere. Learning to look through the “considerate design” lens can turn you into an instant critic of the rude little corners of even luxury products’ software:

“My car’s software is being inconsiderate and not deferring to my needs again today. I instructed it yesterday and the day before that I want to use Bluetooth for audio and Apple Carplay for navigation. Why is it blaring FM radio from the speakers and making me thumb through its screens to re-enable Carplay while I’m trying to back it out of the garage?”

Me to anyone sitting in the car with me when I back out of the garage

Cooper et al. share 13 great characteristics. Examples include that considerate software should be deferential meaning it puts your needs first. Considerate software doesn’t burden you with its personal problems. It fails gracefully.

In our context, “deferential” could mean that, if we are designing a cost model that will be used by the General Manager or Owner, he or she should see the overall numbers first. The model should arrive with the detail columns collapsed while still allowing the Finance or Product Design teams to expand things to work with and graph the details. Many “considerate data” and data usability discussions center on how a user can instantly get the data they want in view and get it analyzed starting from a bigger whole –without unnecessary distractions and without being tempted to break the whole set into smaller pieces that limit doing big-picture analysis.

That’s the high-level flavor of the topic. Read on for some additional motivations and examples. Of course, please reach out if we can make your spreadsheets, dashboards and models more courteous. This is a core, guiding principle for solutions we design for clients. The examples below are based on our online course, Digital Transformation with Excel where we teach an extensive module on how to use Excel’s features to build considerate spreadsheet models.

Additional Considerate Design Motivation and Examples

Cooper et al. make the software case. That’s great but, for data products and models, users often have additional options for heading down a false path versus for the software design topic where they either enjoy using the software or they don’t. Inconsiderate data designs often cause users to avoid using the data (missed insights!) or to descend into bad habits of creating their own “bad spreadsheets” to try to make sense of things. This leads to missed insights and missed chances to scale and connect with adjacent data.

The following sections relate a few of Cooper’s principles to data and models –using content from the Digital Transformation with Excel course. We apply similar thinking to building models in coded languages like Python.

Considerate data and models keep us informed.

Cooper cites the need for software to avoid “pestering us incessantly about its little fears and triumphs,” but we do want it to inform about important updates and status. I extend this to say that data and models should intuitively inform us about data source and state. In spreadsheets, an example is using Excel’s built-in Calculation style (orange bold text below) for columns containing a consistent formula in all rows. The formatting makes clear that the only [visible] inputs in black text are the Tier, Initiative and Size columns B, C and D. There might be additional input columns lurking in the collapsed sections though.

Keeping the user informed is closely related to doing a good job “curating.” That is an important digital transformation topic too. We strongly encourage use of cell notes in header cells (Row 1) to describe variables and give units. In Python models, this is a reason to have multiple sets of columns in DataFrames –one for the variable names and one for the description and units.  We often use automation (an Excel add-in or Python library) to apply and update these comments from a metadata table describing the variables. While not part of keeping the user informed, the model below also illustrates use of macro-refreshable conditional formatting in Columns A to C to avoid the visual distraction of repeated values. This staves off users’ urge to merge cells which would break the table’s structure and eliminate being able to graph the data and to filter and sort the rows.

An Informative Cost Model

Informed

To keep users dynamically informed, we use our home grown Excel macro (VBA) user messaging system to issue informative update and error messages. I recently ported this to Python for use with a client’s model that needed to do extensive pre-checks on inputs for problems before running a model. If all goes well, there are no messages, but we included 100+ potential messages for describing problems and how to correct them.

 

Considerate Models Fail Gracefully

It’s sad but true. Models may not always work when run or recalculated. Sometimes this is due to the user making inappropriate inputs, but sometimes unexpected errors occur. “Gracefully” means that, in these situations, the model does its best to help you pick up the pieces and fix the problem. Showing mysterious gobbledygook to the user is not graceful!

Non-Graceful Failures in an Excel VBA Macro and a Python Model

A quick illustration of failing gracefully with spreadsheet models is that lookup formulas should include a message to explain the problem if a lookup fails –something that can easily happen if the lookup table doesn’t contain an expected value from the master table doing the lookup.  The formulas below show examples of equipping Excel formulas to fail gracefully and avoid the dreaded and difficult-to-understand “N/A” result. Are you not yet familiar with XLOOKUP options and the IFERROR function? Not learning them now would be…inconsiderate.

Excel IFERROR to Advise Correcting Inappropriate Input for Square Root Function

 

Excel XLOOKUP Function’s if_not_found Argument

 

For dynamic errors in coded models, our error handling module allows VBA models to flag specific, problematic cells as in the example below. The “Model contains an error…” dialog alerts the user that there is a problem (so they don’t miss this important fact!). The cell comment describes specifically what’s wrong and how to fix a problem like the typo shown.

   

 

Considerate Models are Forthcoming

For a data product, the basic task of scrolling through data is a great illustration of “forthcoming.” Scrolling is like breathing, right? But equipping models for this to occur in a considerate way is A BIG DEAL. The potential learning from a model or data goes up if it can be scaled and not broken up into little silos that are hard to cross-compare and graph. It is an immediate discouragement if a user ends up looking at a sea (or even a small lake!) of unidentified rows and columns of numbers like this example. Do you remember what Column F is? You shouldn’t need to!!

What am I looking at????

While the above scroll view is rude, the model can be made forthcoming by using Excel’s freeze panes features to anchor the view in the Row 1 column names and “key” columns at the left edge of the data. This makes clear what’s in whatever pane of data is in view. As a bonus for anchoring the view, the key columns at left can be used to filter rows to a desired subset. In consulting projects, When a model outputs data to Excel from another source, we use automation to apply these splits and other formatting –not forcing the user to need to know to do it themselves.

A Forthcoming Model’s Scrollable View

 

These illustrations of considerate software principles give a flavor for how to bring user-interface design excellence to data and models. I recommend that model designers and those designing data analysis study the full, 13-item list of characteristics in Cooper et al.’s book. It has permanently reshaped how I approach design of both basic and advanced “considerate model” elements.