Short on time? This page is the recap. For explanations and worked examples, use the full study guide.
Recap
- A computing innovation includes a program as an essential part of how it works. It can be physical, nonphysical software or a nonphysical concept.
- Collaboration improves innovations because different people notice different problems. It includes both teamwork and consulting users.
- Diverse perspectives help a product fit more people, avoid bias and serve its real purpose.
- Consultation with users (surveys, interviews, watching people try a prototype) shows what the program must do and how people will really use it.
- Online tools (shared documents, comments, change tracking) let teams share ideas and give feedback even when apart.
- Pair programming: one driver writes, one navigator reviews; they swap roles regularly.
- Interpersonal skills: communication, consensus building, conflict resolution, negotiation.
Key relationships
| Idea | What to say in an answer |
|---|---|
| Diverse team | More blind spots are noticed early, so the product fits more people and carries less bias |
| User consultation | The developers learn the purpose from the users’ point of view |
| Pair programming | Two sets of eyes catch errors as the code is written |
| Collaboration tools | Share work and feedback quickly, whether people are in one room or not |
| Interpersonal skills | Keep the team working together when views differ |
Assumptions and conventions
- Say what perspective is missing and what it could change. “Add more people” alone earns nothing.
- Link the benefit to the purpose of the innovation, using the details in the scenario.
- Collaboration lowers the chance of bias; it does not remove it.
Mistakes to avoid
- Treating “diverse” as a vague word. Name the group and the problem.
- Forgetting that users are part of collaboration.
- Claiming a diverse team guarantees a bias-free product.
- Describing pair programming as one person typing while the other is idle.
- Mixing up conflict resolution (settling a disagreement) with negotiation (agreeing a trade).
- Listing tools without saying why they help.
Exam wording to recognise
Questions often begin “Explain how…” or “Describe one…”. A reliable answer pattern is perspective, problem, method, improvement: say who is missing, what could go wrong, how the team could involve them and what gets better. For interpersonal skills, name the skill and then say what a team member would do (for example, “agree who will build which part before starting”). Avoid answers that only say “more ideas” or “better teamwork”; they name no group and no result.
Quick self-check
- A map app is tested only by its developers, all of whom live in the same city. Name one risk. (It may fail for users in other places or with different needs, because those perspectives were never consulted.)
- In pair programming, what does the navigator do? (Reviews each statement, spots errors and thinks ahead while the driver writes; the two swap roles.)
- Two teammates agree to build one feature now and another next week. Which skill is this? (Negotiation, which can also be seen as consensus building.)
Next: practice questions.