Over the last years, I came across a few books that improved the way I work. These books helped articulate ideas, interact with people, and see the world as a system. Take this list as a suggestion, which I’ll update over time. In no particular order:
A book about communicating with people. The way we articulate our designs is often more important than the actual designs. This book shows how to develop empathy with stakeholders, to our own advantage. It gives practical advice on how to cater ideas to different audiences, prepare for meetings, and follow through.
A practical guide…
Designers often feel drawn to first ideas. These impulses can be short-sighted and interrupt our sense-making efforts. They throw us into the solution space too early, with a superficial understanding of the problem.
Unsurprisingly, this can lead to myopic design–narrow in vision and shallow in value. Having fallen into that trap a number of times myself, I started to experiment with different ways to foster depth and perspective. A combination of the methods below have become my go-to recipe.
Key stakeholders can contribute with framing. During ideation and prototyping, a QA Engineer may explore ways to manage cognitive effort and…
We as designers invest a great deal of time understanding our customers. Who are they? What are their aspirations and frustrations? What do they feel and think and do throughout their journey? How are they valuable for the business? Questions like these help cultivate empathy.
Empathy motivates us to care so much about the challenges of another person that we’re driven to action. Empathy is the ultimate form of understanding.
While there’s unquestionable value in empathizing with our customers, it’s equally important to develop empathy with our internal stakeholders — the people we work with on a regular basis.
If you’re designing products in a team, you’re probably pulling iterations in concurrent projects, writing documentation, exporting assets, raising feedback, fixing and reviewing, holding demos, collaborating and talking to people, etc. Design specs are transversal to all these stages, but with so much at hand it’s hard to keep them validated and up to date.
Design specs document the design, assets, behaviour, relevant user feedback and research, discussion, iterations, testing, and pretty much everything related to the process of coming up with a solution for a specific problem, feature, or improvement. …