Writing the CRC of the recording room usability test taught me the differences between writing for a real client and writing for a class assignment. Typically, the audience for my output is an instructor who is evaluating whether I followed the rubric, but in the CRC, I was writing for someone who would actually use our findings to make decisions about an actual place on campus and its documentation. The team's recommendations had to be specific enough to act on, so "fix the audio configuration" wouldn't do unless I specifically pointed out the exact things that needed to change. The participant data also had to be presented in such a way that the client could quickly determine what the result was rather than having to dig into the minutia of the data. The toughest part was turning 6 participants worth of notes, survey responses, and video recordings into an organized list of information to help the client.

I expect this skill to apply directly to a software engineering career. Engineers constantly produce findings that have to be translated for non-engineering stakeholders: bug reports for product managers, postmortems for leadership, and design proposals that have to appeal to people outside the team. The process of collecting raw observations, identifying patterns, and packaging them into a recommendation with clear evidence behind it is the same discipline whether the artifact is a usability report or a technical design doc. Working on the CRC also reinforced how much credibility comes from showing the data. Our recommendations carried weight specifically because the participant notes table was right there for the client to verify against, which is a habit I want to carry into engineering writeups, where it is far too easy to assert and far too easy to be wrong.