Technical Writer Notes on iPhone: Capturing SME Intelligence Before the Next Interview

Technical writing is fundamentally a translation discipline. You take something complex — a software product, a hardware system, a clinical process, an engineering specification — and translate it into something humans can understand and act on. The translation requires accurate understanding. Accurate understanding requires capturing what you learn precisely when you learn it.

The challenge: technical writers rarely have perfect recall of what an SME said three days ago, and their understanding of a product often builds through overlapping, iterative conversations that need to be traceable.

What Technical Documentation Needs That Notes Miss

SME interview intelligence: Subject matter experts speak in domain shorthand, offer non-linear explanations, and often bury the most important insight in a casual aside. "She mentioned in passing at the end of the call that the error message in that flow only appears if the API times out — not if it returns an error code. That distinction is critical for the troubleshooting section and I almost missed it." Voice notes capture exactly this.

Product behavior observations: When you're testing a product or process to document it, your real-time observations — the unexpected behavior, the workflow that doesn't match the design spec, the edge case you discovered — need capturing before you move to the next scenario. Voice notes while you're actively using the product are more accurate than reconstruction from notes taken after the session.

Structure and organization ideas: Documentation structure often comes in moments of insight while you're deeply engaged with the material. "Realized that the API reference section is structured around endpoints but the user mental model is around tasks — should reorganize around task flows with endpoint details nested, not the reverse." That structural insight needs a note immediately.

Complexity and clarity notes: Where is the content currently confusing? What analogies or examples came to mind while you were writing? What feedback from a review session revealed a gap in the documentation? These observations are your quality improvement system.

Version and change tracking context: In rapidly changing products, the rationale for a documentation change matters. "Updated the authentication section because the product team changed the token expiry behavior in the 2.3 release — the old procedure was no longer accurate and was causing user confusion in support tickets." This context makes the change log meaningful.

The Post-SME-Interview Voice Note (5-8 minutes)

Immediately after a subject matter expert interview — before you open your notes:

Interview identifier (spoken): "SME interview note, [topic/feature], [SME name/role], [date]."

The key things they explained (2-3 min): Speak the core technical explanations in your own words while they're fresh. Not a transcript — your synthesis and what you understood. If you can't explain it, that's diagnostic information about what needs clarification.

What I still don't understand (1 min): The gaps in your understanding that the interview didn't resolve. The question you forgot to ask. The explanation that didn't fully make sense. These become your follow-up questions. Speaking them is often clearer than writing them — and forces you to be specific about where your understanding breaks down.

Structural observations (1 min): How should this information be organized in the documentation? What examples or analogies would help? What related content does this connect to?

Follow-up needed (30 sec): Specific next steps. "Need clarification on the API rate limiting behavior — the response he gave was incomplete and I need to test this myself."

Product Testing and Observation Notes

When you're testing a product to document it:

During testing (brief, real-time): "Behavior note: when you cancel a draft, the draft content isn't automatically saved — you lose unsaved work. This needs a warning note in the relevant procedure."

Post-testing synthesis (5-10 min): After a testing session, capture all observed behaviors, deviations from expected behavior, and documentation implications before you move to the next item.

Documentation Review Notes

After a documentation review — whether by an SME, a usability test, or peer review:

"Review note, [document/section], [reviewer], [date]: the main feedback was that the troubleshooting section assumes too much technical knowledge — users who hit the error messages we're documenting may not know what a REST endpoint is. Need to add a glossary and reframe the troubleshooting steps for a less technical audience. The reviewer also caught an inaccuracy in the authentication flow — I had the token refresh step in the wrong position."

These review notes become your revision brief — specific, actionable, and traceable.

Style and Voice Development Notes

Technical writers who are developing their style and voice benefit from observation notes.

"Style observation: the documentation for this product has been written by multiple contributors over several years — it's tonally inconsistent. Some sections are formal to the point of being bureaucratic; others are conversational. The audience is developers who expect conversational-but-precise. Bring this to the style guide update."

"Just read [competitor's] documentation — their API reference uses a 'request parameters' / 'response format' / 'example' structure for each endpoint that's much more scannable than our current format. Worth adopting."

API and Developer Documentation Notes

For technical writers working on API documentation:

"API documentation note, [endpoint], [date]: the POST /users endpoint has a subtlety that the spec doesn't capture — the email address parameter has silent normalization (lowercase conversion) that affects the uniqueness constraint behavior. This needs an explicit note in the documentation or it will cause confusion."

"Response code documentation: the 422 error for this endpoint includes a field-specific error detail in the response body that other 422 errors don't include — inconsistency that developers will need to know about."

These technical observation notes are the substance of good API documentation.

FAQ

How do voice notes interact with documentation tools like Confluence or GitBook? Voice notes are your personal observation and synthesis layer. Your finished documentation lives in the appropriate tool. Voice notes capture the upstream thinking — the SME intelligence, the product observations, the structural reasoning — that informs the documentation.

Should I use voice notes or live transcription during SME interviews? Voice notes after interviews are often more valuable than transcripts during. Transcripts give you everything, including noise. Your post-interview voice note gives you your understanding and the gaps in it — which is the actionable information.

How do I handle technical vocabulary in voice notes? Speak it naturally. Nemos handles technical vocabulary (API endpoints, UI component names, product terminology) well in transcription. Review transcripts to confirm critical technical terms were captured correctly.

Can these notes support documentation review processes? Yes — your post-review voice notes capture the reviewer's feedback and your own reactions and questions in a form that's more nuanced than a comment thread. They supplement the formal review artifacts.

What's the highest-value use of this system for technical writers? Post-SME-interview notes, captured before you open your written notes. Your synthesis of what you understood — and explicit identification of what you didn't understand — is more valuable than any amount of raw transcript for actually writing accurate documentation.

Related Reading

• Work Journal iPhone App for Professionals
• Meeting Notes App iPhone: Capture Decisions That Actually Matter
• Daily Planning with iPhone Voice Notes
• Nemos for Journalists iPhone

Sources

• William Horton, *Designing Web-Based Training* (2000) — user-centered technical documentation methodology
• Gary Blake & Robert Bly, *The Elements of Technical Writing* (1993) — documentation structure and clarity principles
• Microsoft Writing Style Guide (2023) — voice, tone, and technical precision standards
• Tom Johnson, "I'd Rather Be Writing" (idratherbewriting.com) — contemporary technical writing practice and tooling