I was kindly invited to speak at the recent LeanDayLondon event by Stuart Eccles of Made By Many. It was an opportunity to speak in front of people from a variety of design agencies, ux backgrounds, product development houses and startups. I wanted to speak about design from a software engineering perspective to see what would stick. As it turns out, the topic resonated with a number of people and I was fortunate enough to have a number of interesting conversations afterwards.
I’ve always been fascinated by the act of design. Sometimes it’s described by mysterious terms such as creativity, innovation and imagination, sometimes as a magical balance between form and function. A few years ago I spoke to a world-famous sculptor about the act of design. He shrugged and gave me the “1% inspiration, 99% perspiration” line. Further conversation revealed that much of the perspiration aspect came in the form of detailed engineering work required to ensure that the end result could stand the environment and the test of time.
Trying to understand the act of design in a given context raises some questions:
- How are people approaching it?
- What language are they using to socialize it?
- How do they go about it – what are they actually doing?
- What techniques are being practiced and what are the underlying principles?
- How have people learned and how can I learn?
- How are key decisions being tested with reality?
- Who identifies the key decisions to be made, and who makes them?
- Is there a “design hierarchy” in operation?
- If we wanted to do “more” or “better” design, how would we identify the constraint?
- How does design interact at different levels of context and how can we integrate it effectively?
- What does a minimal, viable design look like?
Normally I work to get a good, clear definition of key terms before getting into the detail, but I wasn’t going to attempt this with “design”. It’s a heavily over-subscribed word and, while possibly carrying some essence of meaning, is interpreted very differently in different contexts e.g. graphical, interaction, software, service and organisational design. Instead I opted to use Tom Gilb’s definition of “engineering design” from the excellent Competitive Engineering.
“What are the totality of performance and cost attributes expected from this design in relation to the multiple, quantified performance and cost requirements? What are the risks, priorities, uncertainties, issues, relationships, dependencies and long-term lifecycle considerations that we should responsibly consider about this design?”
Over the coming months I’ll be writing about the building blocks of engineering design including iteration, impact estimation, constraint identification and measurement. Stay tuned.