Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Let's review it: What designers can learn from (code) review

1,129 views

Published on

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

Published in: Design
  • Be the first to comment

  • Be the first to like this

Let's review it: What designers can learn from (code) review

  1. 1. Let’s review it. Ida Aalen Chief Product Officer, Confrere ida@confrere.com / @idaaa Yggdrasil 2018
  2. 2. Links & resources for testing: bit.ly/tools-for-testing To check out the service: confrere.com
  3. 3. There’s also an API.
  4. 4. Design and development.
  5. 5. Code review.
  6. 6. “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
  7. 7. Dag-Inge, CTO Ingvild, Senior Engineer
  8. 8. 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
  9. 9. 👍 Main Repository AuthorReviewer
  10. 10. Why do code review?
  11. 11. Weeds out
 errors and
 heightens quality.
  12. 12. Ensures
 consistency.
  13. 13. Promotes learning and openness.
  14. 14. Curtails “my” code
 and “your” code.
 It’s our code.
  15. 15. Are reviews
 just for code?
  16. 16. Time to review ourselves.
  17. 17. “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
  18. 18. “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
  19. 19. Review ≠ Design by Committee
  20. 20. One author + Reviewer(s)
  21. 21. How can we generalise this advice beyond code?
  22. 22. Principle #1 Think like an adversary, but be nice about it.
 Critique the work, not the author.
  23. 23. Principle #2 Differentiate between
 a) suggestions, 
 b) requirements, and
 c) points that need discussion or clarification.
  24. 24. Principle #3 Don’t forget to praise the good parts.
  25. 25. An example.
  26. 26. Nominate reviewers
  27. 27. Suggestion
  28. 28. Suggestion
  29. 29. Requirement Nominating a reviewer
  30. 30. Don’t forget to praise all the good work!
  31. 31. User testing as review.
  32. 32. 1 of 3
 problems found in expert review are
 false alarm 1 of 2
 problems found in
 user testing were overlooked in
 expert review
  33. 33. 5
  34. 34. N (1-(1-L)n)
  35. 35. 0% 25% 50% 75% 100% Number of test subjects 0 3 6 9 12 15 Observedproblems Small & frequent tests are more efficient
  36. 36. Testing that’s affordable enough to be regular.
  37. 37. Add screenshots to InvisionApp before you begin Add your observations between each test
  38. 38. By connecting it to Slack your team- mates can follow the test
  39. 39. «Hugging»
  40. 40. If you need observers: Test machine Observation + Screen
 sharing+
  41. 41. 30 min pause between each test
  42. 42. Informed consent!
  43. 43. Summarizing and prioritising in Google Sheets or AirTable
  44. 44. Regular review walkthroughs.
  45. 45. 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
  46. 46. User testing
  47. 47. Usability review
  48. 48. Usability review
  49. 49. Usability review
  50. 50. Usability review
  51. 51. Accessibility review
  52. 52. Accessibility review
  53. 53. Accessibility review
  54. 54. Feature review
  55. 55. Feature review
  56. 56. Feature review
  57. 57. Feature review
  58. 58. Design review
  59. 59. Review:
 Death to creativity?
  60. 60. A good idea will survive review.
  61. 61. We’re not artists. We’re artisans.
  62. 62. Let’s make something together.
  63. 63. 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

×