Koda began with a question about how a reading and writing tool could help people work with their own ideas. I wanted AI to support finding material, asking questions and checking references while leaving the thinking and expression with the person writing. I set the product direction and work with AI on implementation. One particularly useful part of that process was using the prototype and recording where it interrupted me.
In September, I saved a short note inside Koda describing the experience. It covered unclear tool explanations, the arrangement of controls, navigation, the mentor and export. The note was informal, but its details gave the next iteration a practical basis.
Describe what happened during an action
One observation concerned the mentor. Clicking it moved me from the writing page to another page. My request was for it to open at the side, so I could continue working in the same place. That was a specific response to the way the interaction interrupted the writing context.
The distinction helped me express the requirement more clearly. “Make the mentor easier to use” would leave several interpretations open. Asking for the discussion to open alongside the writing describes an expected relationship between two parts of the interface. It gives implementation a direction and gives a later check something visible to inspect.
The local revision subsequently included a mentor panel beside the writing area. That is a concrete interface change. The question of how well it supports sustained writing needs a different kind of observation: following a writing task over time and seeing how the panel is actually used.
Make tools understandable where they appear
My note also said that some tool explanations were hard to understand and that the overall arrangement was unclear. I asked for tools to be displayed more directly alongside each other. These comments connected two aspects of the same experience: finding an action and understanding what it would do.
A tool can be present without being easy to use. If its label needs another explanation, or its position makes its relationship to the writing unclear, the interface asks the user to stop and interpret it. In my own use, that interpretation became part of the work before I could decide whether the tool was helpful.
The useful requirement was therefore more precise than simply adding a visible button. I wanted the available actions to be easier to recognise in the writing space. Reducing unnecessary explanations belonged to the same request. It required deciding which information was needed at that moment and which information was making the page harder to read.
Small elements need a clear ending
The export menu exposed another kind of friction. After opening it, I found that the box remained on screen when I moved on to other work. I wrote that it should close when I took another action.
That observation concerned the end of an interaction. Exporting is an action within a longer writing session, so the interface needs to let the person return to that session. A menu can perform its initial function and still interfere with what follows. Recording the expected closing behaviour made the problem much clearer than a general request to improve export.
It also suggested a practical way to inspect a revision: open the menu, move to another action, and observe what stays on screen. This kind of check can establish whether a behaviour matches the request. It does not need to stand in for a broader claim about the quality of the whole product.
Keep the observation connected to the change
AI helped organise my original note into a structured list and supported implementation. I find it useful to preserve the connection between the short observation and the resulting requirement. The organised version is easier to work through, but the original wording explains what I experienced and why I asked for a change.
In this example, the chain is simple: I was writing, an interaction interrupted that activity, and I described the behaviour I wanted instead. That gives a requirement a reason. It also makes it easier to distinguish a response to an observed problem from a new feature idea that needs its own justification.
What this iteration taught me
This was development based on my own use of a local prototype. The valuable outcome was a clearer account of several interactions and a more concrete set of changes, including the side mentor and tool layout. It was not a measure of how a wider group would use Koda.
The method I want to retain is to begin with the action, record the interruption and describe the expected behaviour. Then check that behaviour in the revised interface. For a reading and writing tool, those small decisions matter because they determine how much attention remains available for the work the person came to do.