Making a machine-learning tool feel like a code editor
A developer experience for people who’d been handed an admin panel. 2016.
Problem
LUIS is Microsoft’s tool for training language models. Developers defined intents, entities, utterances, dialogs, and features. The authoring app put every object on its own page. To edit an entity inside an utterance, you left the utterance, opened the entity, made the change, went back. An admin panel, not a developer tool.
Role
Product designer at webkeyz, embedded with Microsoft’s LUIS team. End to end.
Scope
Edit-in-place instead of page-per-object. Entity-utterance connections shown inline. The entity-assignment flyout shipped first onto the old interface; variables and dialogs followed.
Result
Shipped into the product.
Problem
The tool was built for administrators. The users were developers.
A language model is trained by example: you write things people might say, mark the parts that matter, and tell the model what to do about them. LUIS did all of that, through a web app where every object lived on its own page. Marking an entity meant leaving the sentence. Checking a feature meant leaving the intent. You could build a model, but you could never see one.
There was no research budget, and there didn’t need to be. I’d spent my early twenties writing code, and the friends I showed ideas to were engineers. I knew what it felt like to lose your place in a tool, and what it felt like when a tool caught your mistake before you did. The question wasn’t what developers wanted. It was why a tool for developers had been built as if for someone else.
Solution
Treat it like code
One surface, split the way the work splits. Three quarters of the screen for utterances and intents, because that’s what authoring is; a quarter for the advanced features. Intents on the left, the sentence and its dialog in the middle, entities and features on the right. Nothing is a page.
Mark the sentence, not the record
Select a word in an utterance and a flyout offers the entities you have, the prebuilt ones, or creates a new one from what you typed. The model learns from the sentence, so that’s where you teach it.
Read it as data, or as code
A toggle turns “I want to listen to New Divide by LinkinPark” into “I want to listen to $SongName by $ArtistName”. Same sentence, two readings: the example and the template, because a developer needs both.
Let the model answer back
A console at the bottom of the screen: type an utterance, see the intent scores, the dialog’s reply, the JSON the API would return. Trained model on one tab, published on the other. Test before you ship, without leaving the tool.
Outcome
Shipped one piece at a time.
The entity flyout went live first, inside the old interface: the fastest way to prove the model, and a developer could feel the difference the same day. Variables and dialogs followed. All of it shipped before I left webkeyz.
The tool wasn’t bad because it was ugly. It was bad because it had the wrong mental model: a database for something people write. The redesign didn’t add features. It changed what the tool thought it was.