Lesson map
Lesson 05 published. Map, example, EX013.
flowchart TD
N0["Learning outcomes"]
N1["5.1 Audiences"]
N2["5.2 Problem statements"]
N3["5.3 Decision records"]
N4["5.4 Plain language"]
N5["5.5 Diagrams"]
N6["Writing for the board"]
N7["Listening"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Worked example"]
EX --> Q["Exercise EX013"]
Logical drawing
flowchart LR
N0["Learning outcomes"]
N1["5.1 Audiences"]
N2["5.2 Problem statements"]
N3["5.3 Decision records"]
N4["5.4 Plain language"]
N5["5.5 Diagrams"]
N6["Writing for the board"]
N7["Listening"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX013"]
[Learning outcomes]
|
v
[5.1 Audiences]
|
v
[5.2 Problem statements]
|
v
[5.3 Decision records]
|
v
[5.4 Plain language]
|
v
[5.5 Diagrams]
|
v
[Writing for the board]
|
v
[Listening]
|
v
[Worked example] --> [Exercise EX013]
Learning outcomes
You will (1) write clear engineering documents; (2) tailor communication to library staff and managers; (3) record decisions.
5.1 Audiences
Marta needs technical detail; branch managers need to know what changes for patrons; the library board needs costs and benefits. One project, three kinds of document.
Mateo writes each document for one audience and checks it with someone from that group. Marta's notes list exact settings and image versions. The branch managers' note explains what patrons will see and what staff should say. The board receives costs and benefits on a single page. Using one document for all three would bore two audiences and confuse the third.
5.2 Problem statements
Mateo writes a one-paragraph problem statement: personal files left on public PCs and unauthorised software, caused by PCs that keep changes indefinitely.
The statement names the harm, the cause and who is affected, without proposing a solution. That leaves room to compare options fairly. Mateo shows it to Marta and two branch managers, who agree it describes what they see. The agreed statement becomes the first page of the project file, and every later requirement should help solve it. Marta signed the page as the project owner.
5.3 Decision records
Each design decision is recorded with options, choice and reasons, so later readers understand why.
Mateo's first record compared nightly restore with a commercial cleaning tool and with staff clearing files by hand. It listed the effort, cost and protection of each, and why restore was chosen. When a new manager later asked why the library did not just buy the tool, Marta answered by pointing to the record. A decision without a record tends to be argued again every time someone new joins.
5.4 Plain language
Avoid jargon with staff: say "the computer resets itself overnight" rather than "non-persistent image restore".
Mateo tested his wording on three librarians before sending a notice. One asked what non-persistent meant, which settled the matter. Plain language does not mean less accuracy: the overnight reset still wipes downloads and saved files, and the notice says so directly. Staff who understand the change can explain it to patrons, which matters more than any poster. Mateo kept a short glossary for staff questions.
5.5 Diagrams
A simple diagram of the nightly cycle helps everyone see the plan.
Mateo drew four boxes in a circle: patron session, logoff, overnight restore and morning check. Arrows showed what happens to files at each step. He pinned it in each branch's staff room, and librarians began using it to answer patrons' questions. When the design later added a check before restore, the diagram was updated the same week, so it never described an outdated process. Each version was dated.
Writing for the board
For the board, Mateo writes a one-page brief: the problem in two sentences, what the project will change, expected benefits in plain terms and costs in staff time and equipment. He avoids technical terms and offers a short demonstration on a lab PC. The board approves the project and asks for a progress update each quarter, which becomes part of his communication plan.
The brief and later updates are stored with the project's decision records.
Listening
Communication runs both ways. Mateo visits each branch to hear librarians describe daily problems, which shapes the requirements.
Writing technical notes
Technical notes for Marta use numbered steps, exact settings and expected results. Each note names the image version it applies to. When a librarian reports a problem, Marta can check the note to see what should be true and compare it with the PC.
Worked example
A branch manager asks whether patrons will lose work. Mateo writes a one-line notice for screens: "This computer resets overnight; save your work to your own storage or email." Staff test it with patrons and adjust wording.
Synthetic case. Synthetic.
Errors and limits
Technical accuracy without clarity leads to misunderstanding and resistance.
Exercises
- EX013 — Three audiences. Which three audiences need different documents?
Show marking criteria
Rubric: 3 = Marta, branch managers, board; 2 = two; 1 = one; 0 = none. - EX014 — Decision records. What does a decision record contain?
Show marking criteria
Rubric: 3 = options, choice, reasons; 2 = two; 1 = one; 0 = none. - EX015 — Patron notice. What notice did Mateo draft?
Show marking criteria
Rubric: 3 = resets overnight; save to own storage; 2 = partial; 1 = vague; 0 = none.
Synthesis
Communicate decisions clearly to each audience.
Continue studying — chapter 05 of 50
← Chapter 04 (draft) · Course chapter index · Chapter 06 (draft) →