Critique as consensus building
Design-by-committee and frankensteining are much-hated phenomena in the
design community. Both are often used to imply the misguided amalgamation
of ideas into a final creation without any attention paid to their disharmony or
whether they really work to achieve the desired outcomes. In environments
where this takes place, the driving force has become to get those involved,
particularly stakeholders, all saying yes to what is being created without regard
to whether what is being created is actually the best solution. And so bits and
pieces are added to appease the various influencers of the project.
In these environments, critique may still be happening, but it’s typically found
happening in a small corner of the project team. A few people, maybe the
designers and developers are doing it, but the entire team isn’t doing it.
Remember that the team includes stakeholders.
What Aaron and I have found in teams that carry a culture of critique is that at
any time, these discussions may involve members of the team from all areas. It
becomes a natural part of the way they talk with each other. And so, as the
project progresses and decisions are made, members are consistently focused
on and discussing the elements of the design that work best to achieve its
goals. Consensus begins to be built around which ideas are stronger or weaker,
and the design is strengthened as a result.
Years back, on a project that involved the creation of a new insurance
application and processing platform, I got a call from one of the developers.
She had been working on building out some of the functionality I had
prototyped for the initial submission of an application. While doing so, she
was stopped by a stakeholder who had an idea for a new piece of functionality
that they were hoping could be added to the screens. In a few minutes, the
developer had given me a call (I worked in another office), set up a screen
share, and she, the stakeholder and I were discussing the new functionality and
the ideas for its inclusion in the design.
As we did, we referred back to the task flows and scenarios we’d created for
this particular set of functionally as well as the goals we had for individuals
using it. In doing so, we quickly realized that the functionality itself didn’t fit
the objectives we were after. It would have created an awkward branch in the
task flow and more work for the user. We also saw though, that the main point
of this new functionality was to give the users, insurance agents; view of a key
piece of data that had been missing from our designs. Once we realized that
and agreed that being able to see that data was important to our objectives, we
were able to generate a few ideas for adding the data value to the screen in an
effective manner. The entire process took less than 30 minutes and afterwards,