Design for Real People
The acknowledged father of industrial design Henry Dreyfuss once said;
“the products we design are going to be ridden in, sat upon, looked at, talked into, activated, operated, or in some way used by people individually or en-masse. If the point of contact between the product and the people becomes a point of friction, then the industrial designer has failed. If, on the other hand, people are made safer, more comfortable, more eager to purchase, more efficient-or just plain happier-the industrial designer has succeeded.”
Thus, espousing the view that success should be defined by how well the product’s design or functionality meets the needs of the people who use it.
But designing with the user in mind pre-supposes that clients and designers have taken the time to fully understand what it is that the end-users want; what the product is for, and how will the solution make users satisfied. Looking through the lens to see the design problem from a designer’s perspective, one can ask: what does a designer want to achieve from his design efforts? What are the requirements from the designers perspective, and do they align with those of the user?
In 1967 Melvyn Conway, a mathematician and computer scientist, submitted a paper called “How Do Committees Invent?” to the Harvard Business Review. HBR rejected it because he had not proved the thesis. So, Mel submitted it to Datamation, a major IT magazine at that time, which published it in April 1968. The central premise of the paper was;
“any organization that designs a system (product) will produce a design whose structure is a copy of the organization’s communication structure.”
When Fred Brooks cited the paper and the idea in his elegant classic “The Mythical Man-Month,” “Conway’s Law” was born. The central premise being that products of design mirror exactly the shape and character of the design teams who are assembled to design them.
Conway’s law provides a valid sociological basis for why complex designs normally fail to meet the needs and expectations of clients or users who commission them. The reasons for failure is pre-determined due to the management processes we follow and the background sociological or human context in which the design is taking place. For example;
All design requires designers to make choices. Many of the choices may be more than design choices, they may be personal choices the designer makes to accommodate his own prerogatives. Sometimes these choices will subvert the clients’ interests in favour of the designer’s or his organisation’s interests.
It is unavoidable that in the process of organising a design, some aspects of the product of design become pre-determined, explicitly or otherwise by the mere process of team selection.
The selection of a design team means that there is a certain skill set that is included as well as a skill set that is excluded, so further narrowing the design palette from which the client’s optimal solutions can be found.
The design team will also carry with it engrained biases within in each of its members, giving rise to the fact that no design team is unbiased or perfectly organised in the execution in favour of its design goals.
This thinking supports and validates a view that designers rarely, if ever have the complete and undiluted control over design in the interests of their clients or users when committing it to paper. Any of us who are designers and honest with ourselves, will recognise the difficulties in balancing client needs with those of our own internal or external stakeholder organisational, communication or relationship requirements.
And if this is not sufficient to raise the concern of clients who happily place confidence in their commissioned design teams, perhaps it may be best to gloss swiftly over the findings of C Northcote Parkinson. Parkinson postulated from his own observational research that members of an organisation [design teams] tasked with solving a problem usually give disproportionate weight to trivial issues. He cites the example of a fictional committee whose job was to approve the plans for a nuclear power plant. Where the members spent the majority of time in discussion about the materials to use for the staff bike-shed, while neglecting the proposed design of the plant itself, which was more important but also a more difficult.
The law which gave rise to the term bike-shed effect or bike-shedding was coined as a metaphor to illuminate the law of triviality; it was popularised in the Berkeley Software Distribution community by the Danish computer developer Poul-Henning Kamp in 1999 and has spread from there to the whole software industry.
All of this makes a case for the need of clients to stay close to the progress of design work being carried out on their behalf. Client delegation of complete responsibility for the functionality of the design, will have impacts for you and your business. It stands to reason that the design should serve you and your people and not the designers and their people.
And so, the first problem in designing for people is not one for designers, but for clients to address: how will this product work for you, and how will it be used? How will it make what you or people do more effective?