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.

What designers can learn from (code) review

528 views

Published on

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.

Published in: Design
  • Be the first to comment

What designers can learn from (code) review

  1. 1. Let’s review it. Ida Aalen CPO, Confrere ida@confrere.com / @idaaa Pixel Pioneers Bristol 2018
  2. 2. @idaaa
  3. 3. confrere.com/how-we-work/collaboration
  4. 4. Design and development.
  5. 5. When user testing drives development
  6. 6. When user testing drives development What designers can learn from (code) review
  7. 7. Code review.
  8. 8. “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
  9. 9. Dag-Inge, CTO Ingvild, Senior Engineer
  10. 10. 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
  11. 11. 👍 Main Repository AuthorReviewer
  12. 12. Why do code review?
  13. 13. Weeds out
 errors and
 heightens quality.
  14. 14. Ensures
 consistency.
  15. 15. Promotes learning and openness.
  16. 16. Curtails “my” code
 and “your” code.
 It’s our code.
  17. 17. Are reviews
 just for code?
  18. 18. Time to review ourselves.
  19. 19. “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
  20. 20. “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
  21. 21. Review ≠ Design by Committee
  22. 22. One author + Reviewer(s)
  23. 23. How can we generalize this advice beyond code?
  24. 24. Principle #1 Critique the work,
 not the author. “The way you’ve made this button won’t work” vs “This button needs improvements”
  25. 25. Principle #2 Be critical, but remain
 affable and curious. “This button isn’t accessible” vs “What could be done to make this button accessible?”
  26. 26. Principle #3 Differentiate between
 a) suggestions, 
 b) requirements,
 c) and points that need discussion or clarification.
  27. 27. Principle #4 Move discussions from
 text to face-to-face. (Video counts).
  28. 28. Principle #5 Don’t forget to
 praise the good parts! What’s clever, creative, solid, original, funny, nice, etc?
  29. 29. 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!
  30. 30. An example.
  31. 31. Creating our sign-up flow: 1. Requirements gathering 2. Mockup 3. Implementation 4. User testing 5. Design 6. Implementation
  32. 32. 1) Requirements gathering A bunch of people in front of
 a whiteboard arguing?
  33. 33. 1) Requirements gathering Author: Ida Reviewers: • Svein (CEO) • Dag-Inge (CTO) • Ingvild (Sr. Engineer)
  34. 34. 2) Mockup A bunch of people getting at it in a Google Docs?
  35. 35. 2) Mockup A bunch of people getting at it in a Google Docs? Nominating reviewers Author
  36. 36. 2) Mockup Author: Ida Reviewers: • Eivind (Design) • Svein (CEO) • Dag-Inge (CTO) • Ingvild (Sr. Engineer) • Jørgen (Design/frontend)
  37. 37. 3) Implement The UX designer meddling in the engineer’s work? Nominating reviewers Author
  38. 38. 3) Implement Author: Ingvild Reviewers: • Dag-Inge (CTO) • Ida (CPO)
  39. 39. 4) User testing Author: Ida Reviewers: • The users!
  40. 40. 5) Design Author: Eivind Reviewers: • Ingvild (Sr. Engineer) • Ida (CPO)
  41. 41. 6) Implement Author: Ingvild Reviewers: • Eivind (Designer) • Ida (CPO)
  42. 42. Creating our sign-up flow: 1. Requirements gathering " 2. Mockup " 3. Implementation # 4. User testing " 5. Design $ 6. Implementation # One author
  43. 43. Creating our sign-up flow: 1. Requirements gathering " + %#& 2. Mockup " + %$#&& 3. Implementation # + " '& 4. User testing " + 👭👬👫 5. Design $ + " # 6. Implementation # + " $ Many reviewers
  44. 44. One author
 ≠
 Waterfall
 process
  45. 45. Involving everyone
 ≠ Design by Committee
  46. 46. Regular review walkthroughs.
  47. 47. 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
  48. 48. Accessibility review
  49. 49. Accessibility review
  50. 50. Accessibility review
  51. 51. Feature review
  52. 52. User testing
  53. 53. User testing
 as review.
  54. 54. 1 in 2
 problems found in
 user testing were overlooked in
 expert review 1 in 3
 problems found in expert review are
 false alarm
  55. 55. 5
  56. 56. N (1-(1-L)n)
  57. 57. 0% 25% 50% 75% 100% Number of test 0 3 6 9 12 15 Observedproblems Small & frequent tests are more efficient
  58. 58. Regularity
 requires affordability.
  59. 59. Add screenshots to InvisionApp before you begin Add your observations between each test
  60. 60. By connecting it to Slack your team- mates can follow the test
  61. 61. “Hugging”
  62. 62. Usability review
  63. 63. Review:
 Death to creativity?
  64. 64. A good idea will survive review.
  65. 65. We’re not artists. We’re artisans.
  66. 66. Let’s create something
 together.
  67. 67. Thank you! confrere.com/about/how-we-work Ida Aalen Chief Product Officer, Confrere ida@confrere.com / @idaaa

×