Skip to content

Chapter 5 Quiz

← Back to chapter

1. What are the five core questions that audience analysis answers?

  1. What, When, Where, Why, How
  2. Who, What, What, How, Why
  3. Who, How many, What level, Which format, When
  4. Purpose, Channel, Encoding, Decoding, Feedback
Answer

B. Who, What, What, How, Why Audience analysis answers five core questions: (1) Who are the people receiving this message? (2) What do they already know about this topic? (3) What do they need from this communication? (4) How do they prefer to receive information? (5) Why should they care? These questions shift the communicator's focus from what they want to say to what the audience needs to hear.

Concept tested: Audience Analysis

Bloom's level: Remember

2. According to the chapter, what is the primary question a technical audience asks?

  1. "What is the business impact?"
  2. "What does it do for me?"
  3. "How does it work?"
  4. "What is the timeline?"
Answer

C. "How does it work?" Technical audiences (fellow engineers, architects, data scientists) primarily want to understand implementation details, architecture, trade-offs, and code quality. Non-technical audiences ask "What does it do for me?" and executive audiences ask "What is the business impact?" Recognizing each segment's primary question is fundamental to message adaptation.

Concept tested: Technical Audience

Bloom's level: Remember

3. In a stakeholder map, how should you communicate with stakeholders who have high influence but low interest?

  1. Manage closely with tailored communication and regular updates
  2. Keep satisfied with concise summaries and escalate only when decisions are needed
  3. Keep informed with broader updates
  4. Monitor with minimal communication
Answer

B. Keep satisfied with concise summaries and escalate only when decisions are needed High-influence, low-interest stakeholders (such as a CTO who can block or accelerate a project but is not deeply engaged) should receive concise summaries rather than detailed reports. Communication should be escalated only when decisions are needed. This prevents both over-communicating to a disengaged decision-maker and under-communicating to someone with the power to affect outcomes.

Concept tested: Stakeholder Mapping

Bloom's level: Apply

4. A software engineer sends the same detailed technical email about a database migration to her engineering team, the product managers, and the VP of Engineering. What is the core problem?

  1. A clarity problem -- the email was poorly written
  2. A structure problem -- the email lacked a pyramid structure
  3. An audience problem -- the message was not adapted for different segments
  4. A brevity problem -- the email was too long
Answer

C. An audience problem -- the message was not adapted for different segments The chapter uses this exact scenario to illustrate that even clear, well-structured communication fails when it is not adapted for different audiences. The engineering peers appreciated the technical specifics, but product managers were confused and the VP stopped reading. The solution is message adaptation -- adjusting content, vocabulary, and depth for each audience segment.

Concept tested: Message Adaptation, Audience Segmentation

Bloom's level: Analyze

5. What is a "knowledge gap" in the context of audience analysis?

  1. The difference between what the speaker knows and what they can explain
  2. The difference between what the audience currently knows and what they need to know
  3. The gap created when technical jargon is used with a non-technical audience
  4. The time delay between sending a message and receiving feedback
Answer

B. The difference between what the audience currently knows and what they need to know The knowledge gap is the delta between the audience's current understanding and what they need to know to understand your message or take the desired action. Your entire communication exists to close this gap -- no more, no less. Delivering information they already possess wastes time; skipping information they need creates confusion.

Concept tested: Knowledge Gap

Bloom's level: Understand

6. Which depth calibration level would be most appropriate when presenting a completed infrastructure project to the VP of Engineering?

  1. Close-up: architecture decisions, trade-offs, performance metrics, code-level changes
  2. Standard view: user-facing outcomes, workflow changes, timeline
  3. Wide angle: what happened, why it matters, what is needed next
  4. All three levels presented simultaneously
Answer

C. Wide angle: what happened, why it matters, what is needed next Executives operate under extreme time pressure and need the big picture -- what happened, why it matters strategically, and what resources or decisions are needed next. The close-up view (A) is appropriate for technical audiences. The standard view (B) suits non-technical stakeholders like product managers. Presenting all three simultaneously (D) would overwhelm the VP and violate the principle of audience-appropriate depth calibration.

Concept tested: Depth Calibration, Executive Audience

Bloom's level: Apply

7. Which of the following is an example of inclusive language in technical communication?

  1. Using "sanity check" to describe a validation step
  2. Using "manpower" to describe staffing needs
  3. Using "validation step" instead of "sanity check"
  4. Using "bikeshedding" without definition when writing for a broad audience
Answer

C. Using "validation step" instead of "sanity check" Inclusive language avoids expressions that exclude, marginalize, or stereotype groups. The chapter specifically identifies "sanity check" as an ableist metaphor that can be replaced with "confidence check" or "validation step." "Manpower" (B) should be replaced with "staffing." Using undefined jargon like "bikeshedding" (D) creates in-groups and excludes those unfamiliar with the term.

Concept tested: Inclusive Language

Bloom's level: Apply

8. Why does the chapter describe accessibility as a "quality multiplier" rather than just an accommodation?

  1. Because accessibility features are legally required in all countries
  2. Because accessible design only benefits people with disabilities
  3. Because designing for accessibility produces communication that is clearer for everyone
  4. Because accessibility is the most expensive part of communication design
Answer

C. Because designing for accessibility produces communication that is clearer for everyone The chapter argues that accessibility benefits extend far beyond people with disabilities. Captions benefit people in noisy environments. Plain language benefits non-native speakers. Clear heading structure benefits anyone skimming a long document. Designing for accessibility from the start produces communication that is more effective for the entire audience, making it a quality multiplier rather than a niche accommodation.

Concept tested: Accessibility

Bloom's level: Understand

9. You are preparing a presentation about a new machine learning feature for a meeting that includes data scientists, product managers, and the CTO. Describe the Five-Minute Audience Check process and explain how you would apply each step to prepare for this mixed audience.

Answer

The Five-Minute Audience Check has five steps:

Step 1 -- Name your audience segments: Data scientists (technical audience), product managers (non-technical audience), and CTO (executive audience). Each segment has different priorities and vocabulary.

Step 2 -- State each segment's top priority: Data scientists care about the model architecture, training methodology, and accuracy metrics. Product managers care about how the feature affects the user experience and the launch timeline. The CTO cares about strategic alignment, competitive advantage, and resource investment required.

Step 3 -- Identify the knowledge gap: Data scientists likely understand ML concepts but may not know the specific business problem. Product managers understand the user problem but not the technical approach. The CTO needs to understand how this investment fits the company's strategy.

Step 4 -- Choose vocabulary level: Use business-accessible language as the default since the CTO and product managers are present. When discussing technical details, briefly define terms. Consider structuring the presentation so technical deep-dives are optional or in backup slides.

Step 5 -- Set depth: Start with the wide-angle view (what the feature does and why it matters strategically) for the CTO, move to standard view (user impact, timeline) for product managers, and plan backup slides with the close-up view (model architecture, training data, accuracy metrics) for data scientist questions during Q&A.

Concept tested: Audience Segmentation, Depth Calibration, Vocabulary Adaptation

Bloom's level: Apply

10. A team lead notices that two engineers on a distributed team have built conflicting implementations of the same feature because they each interpreted the design document differently. Using concepts from this chapter, explain what likely went wrong and what the team lead should do to prevent this in the future.

Answer

The root cause is almost certainly a failure to build a shared mental model. Several concepts from the chapter explain what went wrong:

Shared mental model failure: The two engineers lacked a common understanding of the design. They may have read the same document but decoded it differently based on their individual backgrounds, assumptions, and mental models of the system. Without explicit alignment, each built what they personally understood rather than what was intended.

Missing context setting: The design document may have failed to establish clear context -- the trigger for the work, the scope of what was and was not being built, and the stakes. Without this shared context, the engineers filled in gaps with their own assumptions.

Absence of alignment checks: The team likely did not verify shared understanding after distributing the design document. The chapter recommends regularly asking "Are we on the same page?" and verifying with specifics, not just nods.

Possible vocabulary ambiguity: Key terms in the design document may have been interpreted differently -- for example, the word "service" might mean a microservice to one engineer and a monolithic module to another.

Prevention: The team lead should (1) establish explicit definitions for key terms in design documents, (2) use visual anchors like architecture diagrams to give everyone the same picture, (3) conduct alignment checks at the start of implementation where each engineer explains their understanding, and (4) build a shared mental model through consistent vocabulary and regular check-ins. Perspective taking -- asking "Could a reasonable person interpret this differently?" -- should be part of the design document review process.

Concept tested: Shared Mental Model, Context Setting, Perspective Taking

Bloom's level: Evaluate