Design Thinking is less a process and more a way to think about problems and solutions from the people's perspective and how the architecture affects the stakeholders.
In this post, I’m going to highlight the four principles of Design Thinking and how they can be applied to software development to guide our design activities.
🔹 Design for Humans
We design software for people and with people, in the end, software development is an intensely social and collaborative activity. The idea to create a software architecture isolated from the team is a myth.
As we design a system, we work closely with our team, fostering mutual respect by actively listening, assuming positive intent, and embracing human-centered design principles.
Empathizing with the humans who directly and indirectly interact with the architecture makes us a better designer, communicators, and leaders.
🔹 Preserve Ambiguity
Ambiguity in engineering is dangerous. Once we've made a design decision, we must share it with precision and clarity. However, design decisions that do not directly influence a quality attribute or reduce risk threatening our ability to deliver software are more about detailed design than architecture.
Such decisions can safely be left open for downstream designers to settle outside the architecture.
🔹 Design is Redesign
The redesign rule encourages us to think about what we already know by exploring patterns and past designs. As time goes on and as we build more software, our institutional knowledge about how to design great software improves. Other teams have probably seen a problem similar to the one you are facing currently. Hopefully, someone documented a pattern you can use as a starting point for your architecture.
When designing software architectures, we'll spend more time refining existing designs than creating new ones. One of the least effective ways to design an architecture is to ignore the software system that came before us.
🔹 Make the Architecture Tangible
While the structures in the architecture can exist in code, this does not make the architecture any more tangible.
Code is difficult to read and does not make discussions about quality attributes, coarse-grained components, design rationale, or the consequences of our decisions any easier.
If we want to share an architecture with others, then we need to make it real in a way that code by itself will not allow.
The tangible rule is closely related to the human rule. Humans must be able to relate to ideas to internalize them.
Reference
Design It: From Programmer to Software Architect by Michael Keeling
What are your thoughts? Let’s discuss it! 👇
Top comments (1)
Very nice! Design for Humans fosters collaboration and Making Architecture Tangible ensures clear communication, especially with non-tech folks.