The whiteboard is covered with arrows when the meeting ends. One path has been crossed out, another has a question mark, and someone has circled a worker. A photo will preserve every mark. It will not tell a colleague which path the team chose or why.
Before erasing the board, decide what work the drawing still needs to do. Some sketches only help people think in the room. Others carry a decision that someone absent will have to implement or challenge. The useful record can be much smaller than the board, provided it keeps the decision and its limits.
Follow one design session to its end
Imagine a fictional team designing image previews for an upload service. A client uploads a full-size image through an API. The API stores the original in object storage and records an upload row in a database. The product wants to show a preview soon after upload, but it has not promised that the preview will be ready in the upload response. Authentication, image safety checks, and storage retention are outside this session's scope.
The first sketch has the API generate a preview before returning to the client. It is easy to explain and gives the client one response with both image and preview URLs. The team draws a long arrow through the API and crosses it out after discussing large images and slow processing. They do not have measurements proving the path is too slow. Their narrower reason is that the product can tolerate a temporary processing state, so the API does not need to hold the request open for preview generation.
The accepted sketch has the API store the original and upload row, then submit a preview job. A worker reads the original, writes a preview to object storage, and updates the row so the client can see that the preview is ready. The client initially sees "processing." This choice moves preview work out of the upload response, but it also introduces a job that may fail or run more than once. The board has a question mark beside deletion: what happens if a user deletes the original while the worker is processing it? The meeting ends without a policy for that race.
Nothing about the neat final arrow proves that the API can submit a job and record the upload consistently. That guarantee needs separate design work. The team should preserve it as an open question rather than let the drawing imply a reliable handoff.
Keep the decision, not every stroke
For this session, the enduring record is short. It says that the team chose asynchronous preview generation because a processing state is acceptable to the product. It names the rejected synchronous path and the benefit it offered: a preview URL in the upload response. It records the deletion race and the job-submission guarantee as unresolved, with a person or work item responsible for settling each before implementation depends on an answer. A small, legible version of the accepted flow helps readers locate those questions.
The scribbles used to compare processing time guesses do not need transcription if nobody will rely on them. Neither does a temporary drawing that only helped one engineer explain object storage to another. Preserving those marks can make the record harder to read, and an unlabeled photo may cause a crossed-out path to look like a live proposal.
This selective approach fits what researchers observed, within the limits of older studies. In a 2014 study of software sketches, Baltes and Diehl used company fieldwork and a survey of 394 participants. Respondents described keeping some sketches for later understanding and letting others go because they had served their purpose. That exploratory sample cannot tell any particular team how many boards to save. Cherubini and colleagues' 2007 interviews and Microsoft employee survey likewise described drawings used to understand, design, and communicate software; some temporary drawings lost value after the conversation, while some design decisions recorded on them were lost with the drawing. The practical judgment is to identify which kind of board you have before it disappears.
When a photo is enough
A photo is useful when the participants need a reminder of a recent conversation and can still explain every symbol. For example, the preview team might attach the photo to the meeting note that day while they write the decision. It retains the exact alternatives and annotations long enough to check whether the written account missed something.
If an engineer who missed the meeting must build the flow next week, the photo needs context. Label which path was accepted, what the arrows mean, why the other path was discarded, and which question marks remain open. The accepted flow may merit a clean redraw if the original is illegible or will be used in another review. Transcription has a cost, though: it can make tentative lines look settled. Keep uncertainty visible in the redrawn version and link it to the decision note.
The person who owns the upload work should own this handoff record, or name another owner before the room empties. That person does not need to archive every intermediate sketch. They need to make sure the implementer can distinguish the chosen behavior from the alternatives and can find the unresolved work. If the session produced no lasting decision, a photo for the participants or no artifact at all may be enough.
If the accepted flow will change again, Lycana can hold an editable diagram of the API, storage, job, and worker. Keep the reason for choosing that flow and the two open questions in the handoff note; a clean diagram alone cannot carry them.
Before erasing a board, try one test: could an absent colleague tell what was decided, why it was chosen, and what still cannot be assumed? If the answer depends on someone narrating the meeting from memory, write that missing context while the conversation is fresh.
