Design Manifesto

Shreyas Prakash headshot

Shreyas Prakash

This thought was inspired by the book Design Expertise (Lawson & Dorst, 2009) which includes an interview with the architect Ken Yeang where the author mentions: “I give every new member of staff the practice manual to read when they join. They can not just see past designs but study the principles upon which they’re based”.

In other words, what would be the ethos behind your own unique design practice? When every designer is different in their own way, what would be one’s own philosophy of practice?

This took me on a very reflective journey, digging into my very own practice back in India, and also with the Masters program here at TU Delft to understand the underlying practices and principles behind my very own way of doing design.

Writing the key principles, has in a way, made it explicit, my very own 11 fundamental principles behind my current workflow. Truest to the design process, the principles are still iterative and not exactly written on stone, however, this is a good start to thinking seriously about one’s own practice manifesto.

It’s always the case (at least with me) when the projects somehow magically gets completed in the last moment, few minutes away from the exact deadline when you wonder, and marvel at how stunningly true this law is. Commonly called as the Parkinson’s law, it quotes that work expands so as to fill the time available for its completion. ^4d1fad

You have five days to complete a project and it gets over after four weeks, 23 hours and 55 minutes (or somewhere around this borderline). But surprisingly so, when you have seven hours to complete the same task, you could still do a decent job at completing it in time. The time pressure does something magical to you.

To steer clear, I started having self-imposed deadlines which I started taking seriously when I realised how having milestones every week through sprints were making the design process more effective. Through this scrum approach, things were getting done more quickly than expected. The week finally wraps up       on a better note with a standup meeting where the team discusses critical blockers and milestones achieved over this span.

As Naval Ravikant, Founder of AngelList puts it, human beings are not meant to be like cows, grazing on grass all day. We are closer to carnivores, the lions in this aspect. We train hard and we sprint and then rest for sometime until we are all set to sprint again. This quote summarises how the mental model of the design sprint should be perceived as. It is not about the number of hours put in, but the expected deliverable that comes out at the end of the weekly design sprint that matters the most. This helps overcome fixations of most kinds.

As a designer, we become more of an interlocutor, connecting various nodes, stakeholders in the form of engineers, users, scientists, governments and other stakeholders, to synthesize information in order to come up with a creative outcome.

In this journey of dealing with wicked problems, one might get lost assimilating information, be sidelined or might even find it difficult to comprehend. Empathy is that bulletproof shield that keeps one from continuing the journey. Adam Grant in the Tim Ferris podcast mentioned his workflow to achieve high-volume high-quality work done as follows, “When you feel unproductive, it doesn’t mean you’re lazy. Its often the sign that you haven’t found what makes the project interesting to you or meaningful to others.

Once we empathise with the individual we are designing for, assimilation and synthesizing information becomes easier, as now we have the intent to get it done.

Empathy should come first. Grasping technology required to tackle this problem would become much smoother once priorities are set.

Framing of the words matters. And in the design process, it might become even more important to keep framing and reframing the problem until it makes sense in our context. For instance, when one is tackling an environmental issue, a slight change in the description of the problem from ‘climate change’ to ‘global warming’ could change the interpretations (George Lakoff, 2010) and the mental model related to it as well, thereby affecting the solutions that might come out of this eventually.

Choosing the right words. And choosing the words right. Both equally important in various governing aspects. For instance, mistaking an it’s for an its, or a you are for an you’re might just be the very thin line between being professional or being careless, which could eventually stifle a design agency. Collaboration between conscious grammar nazis becomes more productive, when we are busy involved with chasing meaningful outcomes rather than correcting spelling mistakes or punctuation marks.

Designers don’t have to become rocket scientists to design rockets. There’s a big difference between design and science. Design has no right or wrong. No optimal answer to the problems. Where promising directions are taken in terms of designing services to products to both products and services together.

Coming back to the point, when designers come to a stage where they design rockets, my personal opinion is that they don’t have to know the exact science behind the rockets to design it.

Ashlee Vance, in the Elon Musk biography gives the example of how Musk cold-called a couple of Russian rocket scientists to have talks with them. Thereby absorbing experiences and knowledge from the people he was around, becoming the ‘one-day rocket scientist’ quite literally. This becomes an important quality as a designer especially when communicating with various specialists in different fields. The designer here is an interlocutor. And being a ‘generalist-specialist’ helps.

Even when it comes to designing rockets. Or anything else which involves technology or multi-level stakeholders. As the conversations could change from rocket propulsion to political strategies. It really depends on the context and one has to understand the vocabulary of the context.

One might have usually encountered certain books existing as a compilation of various methods and methodologies (Delft Design Guide, Norbert Roozenberg etc) and it’s always a struggle to use the right method in the right situation.

When a certain method doesn’t work out as intended, we try to put the blame on the method or the facilitation of the process. Methods are sometimes incredibly useful, however, it should be looked at as a means to an end, but not as an end to itself. And while recommending methods to others, one should eat their own turtles. Or in other words, one should have skin-in-the-game, to have actually used it in practice and to recommend when one finds similar patterns from the past emerging in the current situation.

Therefore, they are a description of what one has executed in the past, and what could be applied, but not as a prescription. It can never be applied as a one-size-that-fits-all and one should always be skeptical about it.

As Nigel Cross puts it in the paper (The Method in their madness, 1996), methods are life-jackets, helping designers out in fuzzy situations and not straight jackets, to be normally applied to each and every situation without thinking critically as to whether the method should be applied or not.

Methods help orchestrate the ‘madness’ of designers.

Every body a designer.

Every one can involve in the design process.

Be it Sporty Susan, or Political Pete and even Single Stella. By nature everyone is born creative, and creativity is not something exclusive to the profession of design. Ideas exist in the intersections. And that’s exactly some of the reasons why participation of key stakeholders in the design process can provide immense benefits. Direct users can provide key insights as ‘experts of experience’ whereas indirect users, or other stakeholders can help enriching the understanding of the problem by providing multi-fold vantage points.

However, it has to be looked carefully in terms of application as collaboration might not necessarily lead to creative solutions if that’s what we’re looking for. But would definitely provide a better understanding of the problem. The analogy is similar to a blind man touching an elephant from various sides, and getting a better understanding of what one’s trying to perceive.

While involving stakeholders, the designer should play the role of a host at the dining table, carefully involving each participant with care and comfort as the best ideas come when at ease.

Prototypes should not be evaluated at its face value. But it has to be looked at as a tool for enquiry. As an investigation which sheds insights about the research question. In that regard, how beautiful the prototype would matter less if it doesn’t really help guide the research through design process (Rust, Chris. 2004)

Prototypes need not exactly exist in a ‘physical’ space.

Einstein ran a series of visualised thought experiments for understanding physics better. Sometimes chasing beams of light mentally. On a similar note, prototypes need not be exactly demonstrated physically but could be done through role playing or through a series of thought experiments similar to how Einstein did. Qualities of the desired interaction could be demonstrated on the go without even a piece of paper. Just with your bare hands in a long train journey, one could iterate on the fly. That’s the power of an ultra-rapid prototype (Buchenau, 2000), when all you need is a chain-of-thought and some presence of mind.

Being relaxed gives you more creative ideas. For Salvador Dali, it came at a specific junction in his sleep phase, while holding a steel ball in his hand waiting for it to fall so that he could wake up and sketch his ideas that pop up in his dreamy state. For some others, it can come while sitting naked in a bathtub (eureka, eureka!) or when waiting for your bus at the stop.

It no longer has to be forced upon by sitting in a cubicle, brainstorming various possibilities using different coloured sticky notes, but it could come through rational flaneuring (the act of walking without any specific direction or destination) or even through lucid dreaming.

The mind which has spent enough time digging into the root cause of the problem, the best ideas emerge in itself through the co-evolution of problem and the solution (Cross & Dorst, 2001)

Perfect is the enemy of the good. What that means is that one could spend 100 hours on the same task which could probably be done with in 10 hours and be good enough.

Which is why Gert Hans, Founder of Scrum Academy suggests to timebox everything. 10 hours for the good job helps one to get closer to the goal than spending 100 hours for the perfect outcome.

Viki Pavlic, Pitching coach from TU Delft regularly cites how Ideas are only as good as you could communicate them. Which is one of the reasons why verbal prototyping plays a major role - By finding the right words which conveys the desired reaction for the product/service. As you move from one person to another, through the verbal prototype, one gets feedback and iterates on the fly with ones tongue. Water cooler conversations which start with, ‘What are you working on?’ usually end with another iteration of the verbal prototype if looked this way. ^f04d25

What are you working on?

Iteration #1: I am designing an affordable, reliant device for deaf blind runners.

What are you working on?

Iteration #2: I am helping deaf blind runners navigate their surroundings using a communication device…

And so on.

Getting the words right matters.

References

Lawson, B., & Dorst, K. (2009). Expertise in design. Design expertise, 81-112.

Lakoff, G. (2010). Why it matters how we frame the environment. Environmental Communication4(1), 70-81.

Dorst, K., & Cross, N. (2001). Creativity in the design process: co-evolution of problem–solution. Design studies22(5), 425-437.

Buchenau, M., & Suri, J. F. (2000, August). Experience prototyping. In Proceedings of the 3rd conference on Designing interactive systems: processes, practices, methods, and techniques (pp. 424-433).

Willemien Brand. (2017) Visual Thinking: Empowering People and Organisations Through Visual Collaboration

Subscribe to get future posts via email (or grab the RSS feed). 2-3 ideas every month across design and tech

Read more

  1. Hammock driven developmentagentic-coding
  2. Peculiar ways number three fits into our funny little brains
  3. AI sandwich as a defacto principle for anything agentic engineering relatedagentic-coding
  4. How I write essays in 2026writing
  5. Authority in the guise of evidencecritical-rationalism
  6. Map is not the territoryphilosophy
  7. Self hypnosis as a manifestation ritualmeditation
  8. Hegelian dialectic for structured reasoning with AI agentsphilosophy
  9. How I prepare for tough negotiations nowadaysnegotiation
  10. When should we steelthread somethingproduct-development
  11. How to become a polyglot
  12. Breadboarding, shaping, slicing, and steelthreading solutions with AI agentsproduct-management
  13. Healthy conflict in teams have a tipping point
  14. Deslopify AI writing
  15. How I started building softwares with AI agents being non technicalagentic-coding
  16. Read raw transcriptsknowledge
  17. Legible and illegible tasks in organisationsproduct
  18. L2 Fat marker sketchesdesign
  19. Writing as moats for humanswriting
  20. Beauty of second degree probesdecision-making
  21. Boundary objects as the new prototypesprototyping
  22. One way door decisionsproduct
  23. Finished softwares should existproduct
  24. How I periodically rank my rough draftsobsidian
  25. Flipping questions on its headinterviewing
  26. Vibe writing maximswriting
  27. How I blog with Obsidian, Cloudflare, AstroJS, Githubwriting
  28. How I build greenfield apps with AI-assisted codingai-coding
  29. We have been scammed by the Gaussian distribution clubmathematics
  30. Classify incentive problems into stag hunts, and prisoners dilemmasgame-theory
  31. I was wrong about optimal stoppingmathematics
  32. Thinking like a ship
  33. Hyperpersonalised N=1 learningeducation
  34. New mediums for humans to complement superintelligenceai-coding
  35. Maxims for AI assisted codingai-coding
  36. Personal Website Starter Kitai-coding
  37. Virtual bookshelvesaesthetics
  38. It's computational everythingtrends
  39. Public gardens, secret routesdigital-garden
  40. Git way of learning to codeai-coding
  41. Kaomoji generatorsoftware
  42. Copy, Paste and Citeai-coding
  43. Style Transfer in AI writingai-coding
  44. Understanding codebases without using codeai-coding
  45. Vibe coding with Cursorai-coding
  46. Virtuoso Guide for Personal Memory Systemsmemory
  47. Writing in Future Pastwriting
  48. Publish Originally, Syndicate Elsewhereblogging
  49. Poetic License of Designdesign
  50. Idea in the shower, testing before breakfastsoftware
  51. Technology and regulation have a dance of ice and firetechnology
  52. How I ship "stuff"software
  53. Writing is thinkingwriting
  54. Song of Shapes, Words and Pathscreativity
  55. How do we absorb ideas better?knowledge
  56. Read writers who operatewriting
  57. Brew your ideas lazilyideas
  58. Trees, Branches, Twigs and Leaves — Mental Models for Writingwriting
  59. Compound Interest of Private Notesknowledge
  60. Conceptual Compression for LLMsai-coding
  61. Meta-analysis for contradictory research findingsdigital-health
  62. Proof of workproduct
  63. Gauging previous work of new joinees to the teamleadership
  64. Task management for product managersproduct
  65. Beauty of Zettelswriting
  66. Stitching React and Rails togetherai-coding
  67. Exploring "smart connections" for note takingknowledge
  68. Deploying Home Cooked Apps with Railssoftware
  69. Repetitive Copypromptingwriting
  70. Questions to ask every decadejournalling
  71. Balancing work, time and focusproductivity
  72. Hyperlinks are like cashew nutswriting
  73. Brand treatments, Design Systems, Vibesdesign
  74. How to spot human writing on the internetwriting
  75. Can a thought be an algorithm?product
  76. Opportunity Harvestingcareers
  77. How does AI affect UI?design
  78. Everything is a prioritisation problemproduct-management
  79. Nowlifestyle
  80. How I do product roastsproduct
  81. The Modern Startup Stacksoftware
  82. In-person vision transmissionproduct
  83. How might we help children invent for social good?social-design
  84. The meeting before the meetingmeetings
  85. Design that's so bad it's actually gooddesign
  86. Lessons learnt interview prepping for product rolesinterviewing
  87. Obsessing over personal websitessoftware
  88. English is the hot new programming languagesoftware
  89. Better way to think about conflictsconflict-management
  90. The role of taste in building productsdesign
  91. Dear enterprises, we're tired of your subscriptionssoftware
  92. Products need not be user centereddesign
  93. World's most ancient public health problemsoftware
  94. Pluginisation of Modern Softwaredesign
  95. Let's make every work 'strategic'consulting
  96. Making Nielsen's heuristics more digestibledesign
  97. Startups are a fertile ground for risk takingentrepreneurship
  98. Insights are not just a salad of factsdesign
  99. Minimum Lovable Productproduct
  100. Methods are lifejackets not straight jacketsmethodology
  101. How to arrive at on-brand colours?design
  102. Minto principle for writing memoswriting
  103. Importance of Whytask-management
  104. Quality Ideas Trump Executionsoftware
  105. How to hire a personal doctor
  106. Why I prefer indie softwareslifestyle
  107. Use code only if no code failscode
  108. Self Marketing
  109. Personal Observation Techniquesdesign
  110. Design is a confusing worddesign
  111. A Primer to Service Design Blueprintsdesign
  112. Rapid Journey Prototypingdesign
  113. Visualise detailed file structures on CLIcli
  114. Do's and Don'ts of User Researchdesign
  115. Design Manifestodesign
  116. Complex project management for productproducts
  117. How might we enable patients and caregivers to overcome preventable health conditions?digital-health
  118. Pedagogy of the Uncharted — What for, and Where to?education
  119. Future of Ageing with Mehdi Yacoubiinterviewing
  120. Future of Tacit knowledge with Celeste Volpiinterviewing
  121. Future of Rural Innovation with Thabiso Blak Mashabainterviewing
  122. Future of Equity with Ludovick Petersinterviewing
  123. Future of work with Laetitia Vitaudinterviewing
  124. Future of Mental Health with Kavya Raointerviewing
  125. Future of unschooling with Che Vanniinterviewing
  126. How might we prevent acquired infections in hospitals?digital-health
  127. The why to endure any howentrepreneurship
  128. Design education amidst social tribulationsdesign
  129. How might we assist deafblind runners to navigate?social-design