Everyone dreads “Design by committee”. Someone proofing your work might be a threat to creativity. But approaching digital design as a sole creative genius simply doesn’t work. Ida shares what she’s learned about collaboration from developers.

1. Let’s review it.
Ida Aalen
CPO, Confrere
ida@confrere.com / @idaaa
Pixel Pioneers Bristol 2018

2. @idaaa

3. confrere.com/how-we-work/collaboration

8. Design and
development.

9. When user testing drives
development

10. When user testing drives
development
What designers can learn
from (code) review

11. Code review.

12. “Code review is systematic examination […] of
computer source code. It is intended to find mistakes
overlooked in software development, improving the
overall quality of software. Reviews are done in
various forms such as pair programming, informal
walkthroughs, and formal inspections
Wikipedia

13. Dag-Inge, CTO Ingvild, Senior Engineer

14. Pull request submitted by
ingvilin
#423 Add onboarding status
To keep track of the
onboarding progress, a
default onboarding progress
object is added to the user’s
metadata on completing the
sign-up process.
ingvilin requested a review
from daginge

15. 👍
Main Repository
AuthorReviewer

16. Why do code
review?

17. Weeds out
errors and
heightens quality.

18. Ensures
consistency.

19. Promotes learning
and openness.

20. Curtails “my” code
and “your” code.
It’s our code.

21. Are reviews
just for code?

22. Time to review
ourselves.

23. “Code reviews set the tone for the entire
company that everything we do should be
open to scrutiny from others, and that such
scrutiny should be a welcome part of your
workflow rather than viewed as threatening.
Bruce Johnson, co-founder of Full Story

24. “Code reviews set the tone for the entire
company that everything we do should be
open to scrutiny from others, and that such
scrutiny should be a welcome part of your
workflow rather than viewed as threatening.
Me

25. Review ≠
Design by
Committee

26. One author
+
Reviewer(s)

27. How can we
generalize this
advice beyond
code?

28. Principle #1
Critique the work,
not the author.
“The way you’ve made this button won’t work”
vs
“This button needs improvements”

29. Principle #2
Be critical, but remain
affable and curious.
“This button isn’t accessible”
vs
“What could be done to make this button accessible?”

30. Principle #3
Differentiate between
a) suggestions,
b) requirements,
c) and points that need
discussion or clarification.

31. Principle #4
Move discussions from
text to face-to-face.
(Video counts).

32. Principle #5
Don’t forget to
praise the good parts!
What’s clever, creative, solid, original, funny, nice, etc?

33. Review principles
1. Critique the work, not the author.
2. Be critical, but remain affable and curious.
3. Differentiate between a) suggestions,
b) requirements, and c) points that need discussion
or clarification.
4. Move discussions from text to face-to-face.
5. Don’t forget to praise the good parts!

34. An example.

35. Creating our sign-up flow:
1. Requirements gathering
2. Mockup
3. Implementation
4. User testing
5. Design
6. Implementation

36. 1) Requirements
gathering
A bunch of people in front of
a whiteboard arguing?

37. 1) Requirements
gathering
Author: Ida
Reviewers:
• Svein (CEO)
• Dag-Inge (CTO)
• Ingvild (Sr. Engineer)

38. 2) Mockup
A bunch of people getting at
it in a Google Docs?

39. 2) Mockup
A bunch of people getting at
it in a Google Docs?
Nominating reviewers
Author

40. 2) Mockup
Author: Ida
Reviewers:
• Eivind (Design)
• Svein (CEO)
• Dag-Inge (CTO)
• Ingvild (Sr. Engineer)
• Jørgen (Design/frontend)

41. 3) Implement
The UX designer meddling in
the engineer’s work?
Nominating reviewers
Author

42. 3) Implement
Author: Ingvild
Reviewers:
• Dag-Inge (CTO)
• Ida (CPO)

43. 4) User testing
Author: Ida
Reviewers:
• The users!

44. 5) Design
Author: Eivind
Reviewers:
• Ingvild (Sr. Engineer)
• Ida (CPO)

45. 6) Implement
Author: Ingvild
Reviewers:
• Eivind (Designer)
• Ida (CPO)

46. Creating our sign-up flow:
1. Requirements gathering "
2. Mockup "
3. Implementation #
4. User testing "
5. Design $
6. Implementation #
One author

47. Creating our sign-up flow:
1. Requirements gathering " + %#&
2. Mockup " + %$#&&
3. Implementation # + " '&
4. User testing " + 👭👬👫
5. Design $ + " #
6. Implementation # + " $
Many
reviewers

54. One author
≠
Waterfall
process

55. Involving everyone
≠
Design by
Committee

56. Regular review
walkthroughs.

57. Review walkthroughs
• Walkthrough is done together
• One person in charge of reviewing and documenting
• Choose a format that gives as much context as possible
• The idea is to identify issues, not necessarily solve them

58. Accessibility
review

59. Accessibility
review

60. Accessibility
review

61. Feature
review

62. User testing

63. User testing
as review.

67. 1 in 2
problems found in
user testing were
overlooked in
expert review
1 in 3
problems found in
expert review are
false alarm

68. 5

69. N (1-(1-L)n)

70. 0%
25%
50%
75%
100%
Number of test
0 3 6 9 12 15
Observedproblems
Small &
frequent tests
are more
efficient

71. Regularity
requires
affordability.

74. Add
screenshots to
InvisionApp
before you
begin
Add your
observations
between each
test

75. By
connecting it to
Slack your team-
mates can follow
the test

78. “Hugging”

80. Usability
review

81. Review:
Death to creativity?

82. A good idea will
survive review.

83. We’re not artists.
We’re artisans.

84. Let’s create
something
together.

85. Thank you!
confrere.com/about/how-we-work
Ida Aalen
Chief Product Officer, Confrere
ida@confrere.com / @idaaa