Danielle Rosenthal

Practice  /  When no-code isn’t

Business users are experts at their own subject

The person configuring a no-code tool is usually already an expert in her own subject. The tool works when it asks about that subject in her words and leaves the engineering to the system.

TO TYPE × 5TO TYPE × 1??????

6 in the morning#

It’s 6 in the morning at a childcare network, and a staff member is opening the form that places a child at a daycare.

The form asks for the child’s name, date of birth, guardian and address. The system already holds all four on other screens, so she looks each one up and types it in by hand.

Every time she does that, another copy of the same details goes into the system, and the copies drift apart. So we built the fix.

A new tab in the tool for setting up forms let whoever built a form connect its questions to data the system already held. The form could fill itself in. It was the biggest thing the platform had added in years, and it worked exactly as designed.

Then I went to see who was using it#

Months after release, I went into the production data to see which customers had set it up.

There were 39 connections, and every one of them belonged to our own quality-assurance account. No customer had built a single one.

What the setup asked for#

The reason was sitting on the setup screen. Setting up a connection meant picking a direction (load, save or both), then a trigger.

After that came a tree of related items to walk, fields to match, an overwrite strategy and a conflict resolution rule. Each of those is a real distinction, and each one belongs to an integration engineer.

The person who builds the forms at a childcare network is an expert in childcare. She knows which questions matter, which ones staff get wrong at 6 in the morning and what should be filled in before anybody starts typing.

She has no view on overwrite strategy, so a screen asking for one tells her it was built for somebody else.

The first screen was empty#

Anyone who got past the vocabulary hit a second wall. The setup built its list of sources from links between the things each customer tracks, and most customers had never set those links up.

So the screen opened empty, and the person setting it up had every reason to think the feature didn’t work.

Start from the sentence she’d say out loud#

The person who builds the forms can say what she wants in one sentence: “when someone opens this form, fill in the child’s details.”

That sentence already holds the direction, the trigger, the source and most of the mapping. The system can propose the whole connection from it and ask her to confirm.

Larry Tesler, who worked on early graphical interfaces at Xerox and Apple, said every application carries complexity that somebody has to handle. A setup screen that asks her to think like an engineer hands that complexity to the person with the least room for it.

What it changes in the work#

The empty screen went unnoticed for months because the feature counted as shipped the day it was built. So now, before a setup screen ships:

  • Ask the person who will use it to describe the job in one sentence, and build from their words
  • Have the system propose the setup from what it already holds, and ask the person to confirm it
  • Open every setup on the most common case, already filled in
  • Count a feature as shipped once a customer has used it, and look at who is using it in the first few weeks

Back to 6 in the morning#

When the form fills itself in, the staff member opening it at 6 in the morning has one thing left to type. The child’s details are the same everywhere they appear, because they were only ever entered once.

Sources