Heidi's processing can be thought of as mutiple layers of indirection. Voice is processed to make a transcript The transcript is processed to extract concepts The concepts are transformed into a note or letter The last stage is the problem. The interface presents the note first, with a button inviting the user to convert it to a letter. This suggests a workflow in which the notes are being used as the basis for the letter, but this is not the case. In practice, the notes and the letter are very obviously generated from the same data, and will contain the same errors, even if those errors have been corrected in the notes section. This is bad for several reasons. Firstly, the UI suggests that the note will be used to generate the letter (you may not have intended this, but that is the impression that is given), so there is a risk of user error there. Secondly, once the user understands what is really happening, there is an obvious duplication of effort, where mistakes have to be corrected in both the note and the letter (and if I wish to produce e.g. onward referral letters, then I need to correct those too). Thirdly, errors are easy to correct in a bullet-point list, but are harder to correct in a narrative letter (simply due to the additional cognitive burden of reading prose vs notes). The obvious solution is for Heidi to work the way that the interface suggests is actually happening: Audio > Transcript > Concepts > Notes > Letters For bonus points, have the letters automatically mark themselves as containing outdated information, if the Notes are changed.
