View models expose recording state, transcript segments, corrections, generated actions, save state, and export commands.
Case File 03
Voice-to-Workflow TranscriptionFrom spoken thought to editable action.
A desktop productivity proof of concept that records speech, produces an editable transcript, and turns reviewed text into notes or action items.
01 / Product
What the application does
The application separates capture, transcription, correction, and transformation into visible stages. Users can always return to the source transcript instead of trusting a silently rewritten result.
A provider abstraction allows the prototype to work with either a local speech engine or a cloud service. Audio, transcript, corrections, and generated actions are stored as one project so the workflow can be resumed.
Primary workflow
Record → transcribe → review uncertain text → generate notes or tasks → export.
Illustrative stack
C#, .NET 10, Avalonia, MVVM, audio capture service, pluggable transcription provider, local SQLite project store.
Core features
Recording states, waveform feedback, transcript editing, confidence flags, task extraction, autosave, Markdown export.
Target users
Developers capturing ideas, users who prefer speech input, meeting-note workflows, and accessibility-focused productivity use.
Transcript
“Update the release checklist, confirm the build target, and create a follow-up task for the save-system bug.”
Generated actions
- Update release checklist
- Confirm build target
- Investigate save-system bug
02 / Problem
The problem behind the interface
Traditional transcription ends when words appear on screen, but the user still has to correct the text, find decisions, create tasks, and move the result into another tool.
Automation can reduce that work, but it can also alter meaning. The application therefore needed to make uncertainty, transformation, and data handling visible.
Primary design requirements
- Make recording, processing, review, and export states unambiguous.
- Preserve the raw transcript beside edited and transformed versions.
- Allow provider replacement without changing the Avalonia interface.
- Keep keyboard navigation and focus order usable without a mouse.
- Store audio or text locally by default and require an explicit choice before cloud processing.
03 / Ownership
My role and responsibilities
As Project Lead and the studio’s only developer, I treated the project as both a software system and a product exercise. I owned scope, technical direction, interface behaviour, implementation, testing, prioritisation, and the final portfolio narrative.
- Defined the capture-to-output workflow and separated transcription from transformation.
- Built the Avalonia recording view, transcript editor, confidence indicators, action panel, and export workflow.
- Created C# abstractions for audio capture, transcription providers, transformation rules, and project persistence.
- Implemented autosave, error states, cancellation, and recovery for interrupted processing.
- Designed sample accessibility checks for keyboard use, labels, contrast, and focus movement.
04 / Architecture
How the proof of concept is structured
The application treats speech recognition as one replaceable service inside a larger user-controlled workflow.
A C# service streams microphone input to a temporary local file and exposes level information for waveform feedback.
An interface returns timestamped segments, text, and optional confidence values from the selected local or remote engine.
Deterministic rules convert reviewed text into note headings or action items; every generated item links back to its source text.
05 / Decisions
Technical decisions worth discussing
The proof of concept is intentionally small, but the decisions below show how the application would remain understandable and maintainable as it grows.
The transformed result never replaces the source transcript, allowing the user to verify names, commands, and technical language.
The interface depends on a contract rather than one speech engine, making privacy, cost, and offline support explicit choices.
Task extraction runs against the reviewed transcript by default to reduce error propagation.
Audio, transcript, corrections, and actions are autosaved locally; cloud transmission is a separate opt-in action.
06 / Validation
Sample proof-of-concept evaluation
The sample proof of concept was reviewed with ten short recordings covering quiet speech, background noise, technical vocabulary, and task-oriented notes.
The workflow completed from recording through export without losing the original transcript or generated actions.
A mock local provider and a simulated remote provider used the same interface and UI workflow.
Recording, transcript review, task approval, and export were reachable in a logical focus order.
Cancelling transcription preserved the local audio project and allowed the user to retry with another provider.
07 / Outcome
Result, limitations, and next steps
The proof of concept demonstrates a complete user-controlled workflow from speech capture to structured output. Its main limitation is that the sample evaluation does not establish universal transcription accuracy and the transformation rules remain intentionally conservative.
The application treats transparency and correction as product features rather than hiding uncertainty behind automation.
Accuracy varies by microphone, environment, accent, vocabulary, and the chosen transcription provider.
Add domain vocabulary, speaker separation, offline provider integration, richer export targets, and user-defined transformation rules.
Show a one-minute recording workflow, a transcript correction example, cancellation recovery, and the provider interface.
What this project demonstrates
C# desktop development, Avalonia accessibility, service abstractions, audio workflow design, local persistence, failure recovery, and careful handling of automation and privacy.
Project links