A Service Design Principle to avoid information overload
One thing you get pretty good at when you run hundreds of workshops is summarizing a ton of different ideas in a few words (1). But it's only after having to explain how to do it to students that I really realized how this happens.
One of the ways I use to go from a hundred feedback pieces to a summary that is actionable is to make summaries progressively. I try to put together the feedback elements by themes. Usually, that's still way too big to handle. I might get 30 different themes. And having 30 things to do, doesn't feel like a realistic to-do list. So then starts a process where I try to slowly reduce the number of categories by combining similar themes under a new name.
As I repeat that way of working a few times (2), I get to a more manageable amount of information.
Where the art is, is to know when it's the right time to stop summarising. Sometimes you don't know what's the right summary level. So there, it makes sense to bring keep different levels of summary (for example, on the summary with 10 elements, one with 5, one with 3). You can then compare them to decide which one is the most interesting without being overwhelming.
Being able to summarise information is something that will make the lives of both users and workers easier. If you know how to summarise and find key learnings from many user feedback you can improve your service or product without feeling overwhelmed, making the lives of users easier.
If you know how to summarise information, you can then better inform people who work in the backstage of your service. What's especially interesting to me is that the level of summary might be different for the type of person you're talking to. A CEO doesn't need much of the details, but the person working on implementing the changes will be a bit more detail. That's where your multiple variations of summaries get really useful.
Action question
What's the right level of summarisation for the different you could use to share "just enough" information inside your company? Who needs more details and who needs less?
Footnotes
Daniele's note