How to boost design thinking part 2: Design communication

Presenting the results of your work to stakeholders is a part of any design process. Revealing the results of your own work, especially at a work-in-progress stage, can be stressful. On the other hand, it teaches you plenty about yourself, other people and, naturally, design work itself. When you present your thoughts frequently and keep your audience (your stakeholders) close, the threshold of presenting unfinished work becomes lower. This way, getting feedback and iterating the solution becomes faster.

Preparation helps you make presenting your design more fruitful. A user or audience oriented presentation takes into account the goals of the design and the interests of the audience. It tells the story from the user’s point of view in a language that the audience can understand, meaning that it presents a scenario where the design helps to solve a business challenge. An audience-oriented presentation rarely focuses on individual screen views, components, visual details or implemented JIRA tickets. ”Your script creates your feedback” is a good rule of thumb for design presentations, and for sprint demos, too.

The books Presenting Design Work and Articulating Design Decisions offer excellent insights on how to present the results of creative problem-solving.

Boost iteration with feedback

Naturally, the goal of design presentations is to gather feedback. Does the presented proposal solve the business problem in a suitable way? Feedback leads to iteration towards a more fitting solution, but it also feeds decisions that mark out the final direction of the solution. Retracting such a decision may take a considerable amount of convincing, and it is likely worthwhile to document these decisions and their justifications in a longer project.

A decision may lead to a design driver – for example: ”The processing automation of permission documents must be transparent and justifiable, so that users can trust the system.” It can also be connected to a particular functionality, for example: ”Each permission document must have at least a minimum of two inspectors, as the law requires us to abide by the four eyes principle.” A decision may also suspend some solution options and kill some of your precious ideas.

Store all decisions with documentation

A long development project can involve plenty of decisions of different sizes and levels. Documenting all decisions is vital in order for the team to be able to come back to them during further development, even after a long time. At that stage, the team may require answers to questions such as:

Why is the solution the way it is?
What is worth changing and what is worth keeping?
What options did we consider and why did we choose this particular one?
If we change the solution in a certain way, what are the effects?

Those who join the project later on will also need to be informed about all essential markers. You might also be handing over your work to someone else. How do you share the most relevant aspects of the solutions and the process that lead to them as a part of the project and design brief?

It may also be that the design has been created prematurely and the team comes back to it after a longer time when development is about to commence (changing priorities, anyone?). When creating the design, the designer most likely has a good intuition about what works and what doesn’t when the subject is being worked on actively. However, without any notes, it might be difficult to recall the road that led to the solution later on.

Nonetheless, documenting decisions is easier said than done, of course. Lack of time, handling different-level things in different tools, varying processes etc. make it difficult within the everyday, and it may take a long time to discover the optimal way of working. For example, in my current project, information that affects future solutions can be found at least in these tools: Figma, JIRA, Powerpoints and most likely Confluence.

This is our second article of the "How to boost design thinking" blog series. You can find the other articles here: