Chapter 25 — Team project studio

Chapter 25 — Team project studio

Lesson map

Lesson 25 published. Map, example, EX073.

flowchart TD
  N0["Learning outcomes"]
  N1["25.1 Project"]
  N2["25.2 Roles"]
  N3["25.3 Review"]
  N4["25.4 Outcome"]
  N0 --> N1 --> N2 --> N3 --> N4
  N4 --> EX["Worked example"]
  EX --> Q["Exercise EX073"]

Logical drawing

flowchart LR
  N0["Learning outcomes"]
  N1["25.1 Project"]
  N2["25.2 Roles"]
  N3["25.3 Review"]
  N4["25.4 Outcome"]
  N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX073"]

[Learning outcomes]
    |
    v
[25.1 Project]
    |
    v
[25.2 Roles]
    |
    v
[25.3 Review]
    |
    v
[25.4 Outcome]
    |
    v
[Worked example] --> [Exercise EX073]

Learning outcomes

You will (1) work in a team on a privacy project; (2) divide roles; (3) review peers.

25.1 Project

Aisha's team redesigns the app's privacy settings page. The research from the previous chapter showed that members misunderstood the heart-rate sharing setting. The team project turns this finding into a redesign. Aisha works with three classmates from other specialisms: interface design, software development and testing. The team agrees a brief, a timeline of six weeks and a definition of success based on member understanding. Success means most testers explain the setting correctly without help, measured with the same questions as in the earlier study.

25.2 Roles

Roles include research, design, development and testing. Aisha leads research and privacy review, a classmate leads interface design, another builds the prototype and a third plans tests. Roles are clear but not rigid; everyone joins two member sessions. The team meets twice a week and keeps a shared log of decisions, which later helps explain why particular wording and layouts were chosen over alternatives. When the designer and developer disagree about placing the setting, the log records the member evidence that settled it.

25.3 Review

Peers review each other's work for clarity and accuracy. Reviews follow a simple checklist: is the setting easy to find, is the wording accurate, does the default protect members and does the design work for screen readers. Aisha's wording is criticised for being too long, and she shortens it. Peer review catches an error in the prototype where switching off sharing also stopped workout logging. That bug would have silently removed members' workout history, so the team adds a test checking that sharing and logging are independent settings.

25.4 Outcome

The new page explains class screen sharing clearly. Mr. Reilly notes that teamwork brings varied views. In a retest with new volunteers, most participants now explain the setting correctly. The page separates sharing to class screens from the strap connection and uses plain words: show my heart-rate zone on class screens. Sharing is now off by default for new members. The team hands the design to Quayside's app team with the research evidence. Screen sharing now needs a deliberate choice. Existing members are asked once.

Worked example

The team redesigns the settings page with clear roles and peer review.

Synthetic case. The project is synthetic.

Errors and limits

Teams can miss member views; test with members.

Exercises

• EX073 — Project. What did the team redesign? Rubric: 3 = privacy settings page;; 2 = partly correct;; 1 = vague;; 0 = none.
• EX074 — Roles. Name two roles. Rubric: 3 = research, design, development, testing;; 2 = two;; 1 = one;; 0 = none.
• EX075 — Outcome. What improved? Rubric: 3 = explanation of class screen sharing;; 2 = partly correct;; 1 = vague;; 0 = none.

Continue studying — lesson 25 (chapter 25 of 30)

← Chapter 24 · Course chapter index · Chapter 26 →

Continue to the next authored lesson.