Structure, Not Design By Committee

July 30, 2021

I wrote this for the Product blog.

In The Simpsons episode “Oh Brother, Where Art Thou?”, Homer is asked to design a car for a company run by his long-lost brother. Homer, to no one's surprise, fails so miserably that he drives his brother out of business. One of the things that makes this Simpson's clip so interesting is that Homer has real dreams for the car that are perfectly reasonable. As designers, our job is to figure out people’s problems and desires and then translate those into great products.

  • Homer wants a large car, since he is a family man with three kids and two pets, but he doesn't want to be distracted by his family and pets while driving
  • Homer wants places to put his drinks.
  • Homer wants an easily recognizable care as he struggles to find his car when he parks in a large parking lot.
  • Homer wants a car that is pretty quick because he wants to feel alive every now and then in his suburban dad life.
    All reasonable requirements, right? User feedback is something that should be considered in the design of every product. Honestly, the biggest requirement for any product should be that it solves actual problems.

So why did Homer's car not turn into a great success? The story implodes because the car company also let Homer design the actual car. While Home might be great at recognizing the problems he is experiencing, he's simply not a designer.

Our job, as designers, is to understand a problem and find the best possible solution. We can utilize user interviews to gain insights and test a thesis, but just like any data insight, they should steer our decisions, not fully educate them. Homer fails because he can't take his very sensible requirements and turn them into a great product. It's nothing against Homer, in fact almost no user can.

A camel is a horse designed by committee

Humans (research shows - men much more than women) tend to want to solutionize. When we understand the problem, we want a solution, right? Most of us tend to either take the approach that 'we're not designers, so we can't really say anything' or the complete opposite.

Mike Monteiro puts this brilliantly in one of my most overused quotes throughout the years:

I DON'T KNOW anything about design. Bullsh*t. Look around you. You make choices based on design every day. Even if you can’t design those things yourself, that doesn’t take away from your ability to decide that was the chair you wanted to sit on, or the shoes you wanted to wear, or the car you wanted to buy. You know bad design when you encounter it. From every chair you’ve sat in that hurt your ass, to every coffee cup that burned your hand, to every time your finger triggered the wrong link on your phone, to every airline booking site that pissed you off. You know bad design. You hate it.Mike Monteiro - You're my favorite client

It's true that we all know bad design when we experience it. Attention to the user's experience has been a focus for the last few years, and we've become better at spotting not only bad design, but bad user experiences. Everything from confusing navigation to checkouts with way too many steps and friction.

We need to be capable of understanding all of the context around a problem before we start to design a solution - full disclosure: designers tend to be very quick at coming up with solutions too early in the process too! User research and problems needs to be distilled down to core principles and, most importantly, to a strategy. We need to follow these principles vigorously throughout the whole design process. As the project progresses, we need to stay true to the principles even when feedback starts to appear from every direction. The most certain path to a failed project is trying to please everyone all the time.

Coming from Sweden, I've been on numerous projects where the consensus always seems to win. This, essentially, meaning that no one wins. Sir Alec Issigonis, designer of the iconic Mini car famously said: "A camel is a horse designed by committee."

A structure creates usability

I’d prefer to set purpose and structure for each phase of a project. In larger meetings with stakeholders, we can agree on what problem we are solving, for whom and, most importantly, why it needs to be solved. A smaller team of strategists and UX designers can then regroup and brainstorm on possible solutions given the context and framing that the larger group agreed upon. As we define these requirements and constraints, we make sure what we’re building will be functional and reliable. When creating the wireframes, we can order and arrange each feature in a way that’s logical for the user so the product will actually be usable (keep in mind that usable and useful aren’t the same thing!).

Once that solution and framework is set, the visual designers can work on solutions that will bring the experience to life. For a long time, moving from wireframes to visual design was just considered the ‘making the thing pretty’ stage. Truthfully, taking wireframes into visual designs is not about making things pretty, but rather about making things a pleasure to use and with which to interact. During the visual design stage, we can make our product even more usable, but it also gives us an opportunity to make something that’s a pleasure to use.

To summarize: each step of the project is important in itself, but to have a successful product, it's crucial to separate the desired actions and outcomes of each step:

  1. What to build, why and for whom (strategy)
  2. How it should work and why (UX principles)
  3. What it should look like and how it should act (visual and interaction design)
    By following these steps we can minimize the risk of creating the digital equivalent of Homer's car, or worse, a camel when users specifically asked for a horse.

It’s honest, authentic, and accessible.

I love sharing my experiences working in design and what’ve I’ve learned along the way. Join a community of thousands of designers, developers, and product professionals by signing up to my newsletter!

Not quite ready to sign up? I totally understand! Why not start by reading some of my past issues?

Great! Just “one more thing”...

You need to confirm your email to confirm your subscription.

  1. March, 2024

  2. February, 2024

  3. January, 2024

  4. December, 2023

  5. November, 2023

  6. October, 2023

  7. September, 2023

  8. August, 2023

  9. July, 2023

  10. June, 2023

  11. May, 2023

  12. April, 2023

  13. March, 2023

  14. January, 2023

  15. December, 2022

  16. November, 2022

  17. September, 2022

  18. August, 2022

  19. July, 2022

  20. June, 2022

  21. May, 2022

  22. April, 2022

  23. January, 2022

  24. December, 2021

  25. November, 2021

  26. October, 2021

  27. September, 2021

  28. August, 2021

  29. July, 2021

  30. June, 2021

  31. May, 2021

  32. April, 2021

  33. March, 2021

  34. January, 2021

  35. November, 2020

  36. October, 2020

  37. September, 2020

  38. August, 2020

  39. June, 2020

  40. May, 2020

  41. April, 2020

  42. March, 2020

  43. February, 2020

  44. January, 2020

  45. December, 2019

  46. November, 2019

  47. October, 2019

  48. September, 2019

  49. August, 2019

  50. July, 2019

  51. June, 2019

  52. May, 2019

  53. April, 2019

  54. March, 2019

  55. February, 2019

  56. January, 2019

  57. December, 2018

  58. November, 2018

  59. October, 2018

  60. September, 2018

  61. August, 2018

  62. July, 2018

  63. June, 2018

  64. May, 2018

  65. April, 2018

  66. March, 2018

  67. February, 2018

  68. January, 2018

  69. December, 2017

  70. November, 2017

  71. October, 2017

  72. September, 2017

  73. August, 2017

  74. July, 2017

  75. June, 2017

  76. May, 2017

  77. April, 2017

  78. March, 2017

  79. February, 2017

  80. January, 2017

  81. December, 2016

  82. November, 2016

  83. October, 2016

  84. September, 2016

  85. August, 2016

  86. July, 2016

  87. June, 2016

  88. May, 2016

  89. April, 2016

  90. March, 2016

  91. February, 2016

  92. January, 2016

  93. December, 2015

  94. November, 2015

  95. October, 2015

  96. September, 2015

  97. August, 2015

  98. July, 2015

  99. June, 2015

  100. May, 2015

  101. April, 2015

  102. November, 2014

  103. April, 2013