"Put a queue between Billing and Ledger" is quick to say. It may take much longer to decide what the instruction means. Is Billing the public API or the invoice worker? Is Ledger a database or the service that posts entries to it? Until those names point to specific parts of the system, a fast input method can create the wrong change faster.
Speech has a measured advantage in a narrower task. In Ruan and colleagues' published study, 48 university students copied short English or Mandarin messages on an iPhone 6 Plus in a quiet lab. They used either a touchscreen keyboard or speech recognition, with keyboard or speech available for corrections after dictation. English speech entry averaged 153 words per minute against 52 for the keyboard; Mandarin averaged 123 against 43. The researchers designed the experiment to measure favorable conditions for each input method. The final paper appeared in 2017, after an earlier 2016 preprint with different figures.
Those rates include entry and correction of the supplied phrases. They say something useful about getting known words into a phone. They do not measure the time needed to choose those words, revise a design, or decide whether a diagram is right.
The slow part may happen before or after input
Consider a fictional invoice system. A public Billing API accepts a payment request and records an invoice. A separate billing-worker consumes an invoice event and asks ledger-posting-service to create the corresponding ledger entry. The ledger database sits behind that service. Assume the team now wants to buffer work when ledger-posting-service is unavailable. The diagram shows the existing direct call from the worker, but does not yet show where retries happen.
The engineer's first sentence, "Put a queue between Billing and Ledger," omits the distinctions that matter. A queue between the API and the database would be a different design. Even a queue between the worker and ledger-posting-service raises a question: does the worker publish a durable event and finish, or does it wait for a response? The engineer has to inspect the current request path, choose a boundary, and explain what happens to an invoice while posting is delayed. Speaking the first sentence takes little time; settling those points is the work.
Once the intended change is clear, voice could be a convenient way to express a broad edit: "Add a queue for ledger posting requests from the billing worker." That is a proposed instruction, not a guaranteed result from any tool. The engineer would then inspect the connections. If the queue lands on the API's path, correcting that relationship matters more than how quickly the request was spoken.
Typing has a different advantage here. billing-worker and ledger-posting-service are exact names that the engineer can see before submitting a command. In a shared room, typing may also avoid speaking private system details aloud. Direct editing may be simpler still when the only remaining work is to move the queue box or connect one known endpoint. These are judgments about this example, not comparative measurements of the three methods.
The study's error results reinforce the need to inspect the outcome without predicting what a current recognizer will do. Speech produced fewer errors that participants fixed during entry, yet left slightly more errors in the final copied text than keyboard input. The researchers did not test service identifiers, acronyms, code, noisy meetings, or architecture diagrams. Their phrases were short and had no punctuation. A mistaken component name in a technical command has consequences the study did not measure.
Compare the whole change, not just the first command
If you want to choose an input method for your own work, use a small, repeatable design change like this one. Start from the same diagram and the same written requirement. Make equivalent changes by voice and by typed command, reversing the order on another attempt so familiarity does not always favor the second method. Use direct editing when either attempt calls for it. Stop the clock when the queue's position, the request path, and the delayed or failed posting path match the requirement, not when the first command appears on screen.
Keep three times separate: deciding what the change means, entering the request, and inspecting and repairing the result. Note any mistaken target or missing relationship and whether another engineer can trace the final path without your narration. A few attempts will not establish a universal speed ratio, but they can reveal whether speech saves enough entry time in your setting to offset extra inspection or correction. Try the comparison where you actually work; the quiet lab result cannot stand in for that environment.
For the invoice change, the useful outcome is a diagram that distinguishes Billing API, billing-worker, the queue, ledger-posting-service, and the ledger database, with the delayed posting path explained. Choose the input that helps you reach that state while you can still see and fix what it changed.
Lycana offers spoken and typed instructions for an editable diagram, so you can run this comparison on the same invoice example. Inspect each resulting path and correct it before comparing the full task. A faster first instruction says little if it takes more work to repair the relationship afterward.
