Near the end of a call setup for a small school district last winter, a customer asked us to do something we’d been quietly avoiding for years. “Can I just draw out what I want the phones to do,” she said, “and have it work?”
The question was not unusual. Every customer of a complex phone system eventually asks it, in some form. What was unusual is that we said yes, not because we’d been planning to ship something for a year, but because we’d been incrementally building toward it without quite admitting that’s what we were doing.
This is a note about what we shipped, why it took us this long, and what we have learned about visual programming for the people who do not program.
The problem.
A school office manager wants the front desk phone to ring for ten seconds at the start of the day, then roll to the kitchen, then roll to the principal’s cell, but only between 7:30 and 9:00 AM, and only on days the bell schedule says are A-days, and only if the line itself hasn’t been put into night mode.
Every word in that sentence is a routing concept. Every word represents a decision the phone system has to make in real time. The conventional way to express it on a business phone system is to open a ticket with your vendor.
The reason that’s the conventional way is not technological. The technology has existed for thirty years. It is that the systems were built assuming a contractor would do the work. The interfaces reflect the assumption. They are not bad interfaces. They are interfaces for the wrong person.
We had been asking the wrong question. The question is not how do we make our admin portal more powerful? The question is how do we make routing decisions expressible by the person who actually needs them expressed?
What we built.
The Action Editor is a visual surface in the NocTel portal. It looks roughly like a small whiteboard. The office manager can place a node (a thing that represents a routing decision), drag a connection from one node to another, and save. The save is the deploy. There is no compile step. There is no test environment. The flow is live the moment she clicks the button.
The nodes are simple. There is one for ring a phone for X seconds. There is one for check if today is an A-day or a B-day. There is one for if the building is in night mode, do this; otherwise, do that. There is one for send the call to voicemail. There is one for ring this group of phones in parallel. About a dozen in total. We resisted the urge to add more.
Connecting them is the entire interface. The graph is the program.
We did not design a visual programming language. We designed an interface for the people who already know what they want the phones to do.
Where we cheated.
Cheating, in product design, is the right kind of work. The wrong kind is building things from first principles when the world has already solved your problem.
The biggest place we cheated: the editor already knows about the customer’s data. The schedule node already knows about your bell schedule. The hunt group node already knows which extensions you have. The customer is not configuring a system; she is composing pieces that have already been configured. The work she is doing is the only work that is genuinely unique to her situation: the arrangement of the pieces.
The second place we cheated: when she draws a connection the system can prove is wrong (a loop, an unreachable node, a pointer to a hunt group that no longer exists), we tell her. We do not refuse to save it. We do not lock the canvas. We display a small note next to the broken edge. She can act on it or ignore it. We have found this builds more trust than enforcement does, because enforcement reads as the system thinks it is smarter than you are.
What surprised us.
The thing we worried about most (the spatial canvas getting too crowded) has not happened. The number of nodes a real customer actually places in a single flow tends to land between four and twelve. Above twelve they start composing. They build a flow that calls another flow. We did not have to teach them this. It is what people who think procedurally do when they run out of horizontal space.
The thing we did not anticipate is that the editor became a medium for conversation. Sales calls now involve a customer describing what she wants and one of us drawing it on screen while we talk. The drawing becomes the system. The conversation becomes the documentation. The follow-up email is a screenshot.
We are not the first people to discover that an executable diagram is a better artifact than a written spec. We were surprised to find that it works for a school office manager in the same way it works for software engineers.
What we are still figuring out.
The most honest thing we can say about the Action Editor right now is that we do not yet know how complex it can get before it stops being useful. Our largest production flow has thirty-one nodes. We are watching how that customer uses it. We have a theory that the right answer is not make the editor handle more nodes but help people factor large flows into smaller ones. We are not sure yet.
We are also not sure how to handle the case where two people edit the same flow at once. Currently we lock the flow during edits. This is fine when the editing happens in seconds; it is less fine when someone walks away from their desk with the lock held. We are working on it.
And we are not sure when, if ever, more AI-assisted editing makes sense here. We shipped one piece of it, the ability to import a photograph of a whiteboard sketch and have it render as a working draft, because customers asked for it and it worked. We are not in a hurry to add more. The editor’s value, as far as we can tell, comes from the fact that what you see on the screen is what the system does. Anything else we add has to preserve that.
What this is in service of.
We did not build a visual editor because we wanted to ship a visual editor. We built it because there is a person at a desk in an office somewhere who knows what the phone system needs to do, and we want her to be able to do it.
Most software ships features and hopes someone uses them. We try to ship interfaces that the person we are imagining can actually use. The work of designing those interfaces is the work of imagining her in greater and greater detail until what we make stops being a guess.
We are not done with this. We will keep posting as we learn.