What if designers approached collaboration and critique more like developers? Could it make us better designers, and could it better collaboration between designers and developers? Presented at Yggdrasil 2018 in Sandefjord, Norway

1. Let’s review it.
Ida Aalen
Chief Product Officer, Confrere
ida@confrere.com / @idaaa
Yggdrasil 2018

2. Links & resources for testing:
bit.ly/tools-for-testing
To check out the service:
confrere.com

8. There’s also an API.

9. Design and
development.

10. Code review.

11. “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

12. Dag-Inge, CTO Ingvild, Senior Engineer

13. Pull request submitted by ingvilin
#423 Add onboarding status
To keep track of the
onoardingProgress a default
onboarding progress object is
added to the users metadata on
completing the sign up process.
ingvilin requested a review from
daginge

14. 👍
Main Repository
AuthorReviewer

15. Why do code
review?

16. Weeds out
errors and
heightens quality.

17. Ensures
consistency.

18. Promotes learning
and openness.

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

20. Are reviews
just for code?

21. Time to review
ourselves.

22. “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

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.
Me

24. Review ≠
Design by
Committee

25. One author
+
Reviewer(s)

26. How can we
generalise this
advice beyond
code?

27. Principle #1
Think like an adversary, but
be nice about it.
Critique the work, not the
author.

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

29. Principle #3
Don’t forget to praise the
good parts.

30. An example.

32. Nominate reviewers

33. Suggestion

34. Suggestion

35. Requirement
Nominating a reviewer

37. Don’t forget to
praise all the
good work!

38. User testing as
review.

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

43. 5

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

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

48. Testing that’s
affordable enough to
be regular.

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

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

57. «Hugging»

59. If you need observers:
Test machine Observation
+ Screen
sharing+

60. 30 min pause
between each test

61. Informed
consent!

62. Summarizing
and prioritising
in Google Sheets
or AirTable

63. Regular review
walkthroughs.

64. 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

65. User testing

66. Usability
review

67. Usability
review

68. Usability
review

69. Usability
review

70. Accessibility
review

71. Accessibility
review

72. Accessibility
review

73. Feature
review

74. Feature
review

75. Feature
review

76. Feature
review

77. Design
review

78. Review:
Death to creativity?

79. A good idea will
survive review.

80. We’re not artists.
We’re artisans.

81. Let’s make
something together.

82. Thank you!
Ida Aalen
Chief Product Officer, Confrere
ida@confrere.com / @idaaa
PS. Send
en mail til
ida@confrere.com
for to måneder
gratis trial <3