Reflection 2: Think Beyond the Design
This week is all about presentations. It was not until I took IDP and met the bizarre panda hat full of doom cards that I realized presentation itself can be as scary and exciting as design and needs more practice than we thought.
Narrow and Thorough
“Designing narrowly and thoroughly is extremely difficult given the short time. But a design will be useless if it can only fit in the established scenarios. A good design team understand their statement inside out and is well prepared for every question.”
During this project, we were asked to design a super-light information and disaster relief app within 2 weeks. Considering the time constraint, our team chose to narrow down the design focus to “enabling users to broadcast urgent messages to get help from neighbors when ”. Generally speaking, we gave a good presentation by backing up our design with solid research and told a clear design story. Because we drew a doom-free card, everything was within control. But some other teams had various curveballs for having “unlucky” doom cards. By observing their unexpected presentation, I recognized that our design lacks lots of considerations that we might not be able to survive those critique.
- Developer critique
One of the doom cards is “Developer critique” which means developers can interrupt the presentation and ask questions at any given time. we all know there is a love-hate relationship between designers and developers. So don’t expect developers to show mercy to a project when you only design from a designer’s perspective.
Be careful when talking about functions regarding connection to outside resource or real-time information. Without comprehensive technical and cost consideration, these ideas only mean an intimidating work schedule to developers. It’s unreasonable for them to not fight back as hard as possible. Due to the same reason, spend less time talking about future iteration or blueprint.
How to improve: Talk to developers before presentations and make sure the feasibility of every detail.
2. Design Manager critique
Similar to developer critique, senior designers or design managers also raise many head-scratching questions. Besides details, they often challenge the design foundations: Why you chose APP as a medium? What’s the motivation of users to download this app? Why I have to replace my existing app with your new design? These questions require a holistic understanding of our design in terms of marketing strategy and service design.
How to improve: Divide your team into two groups when practicing the presentation. One group present and the other one critique. And then switch.
3. No perfect story
This single slide is my favorite among 11 teams’ presentations: There should be no perfect story in any design storytelling. A good design ponders on various accidents.
In our design, victims who have major injury will hold a button to broadcast an urgent help message to neighbors. However, we forgot to think about what if nobody responds. Will victims wait desperately forever? What should we do to reassure them that we are trying our best to get them help?
What if something goes wrong? This is the question we designers should bear in mind and ask ourselves all the time.
Make the presentation as clear as a child book
I think one of the most frustrating moment during the presentation was when we were required to “ draw a picture of how this app works within 30 seconds”.
To present, we sometimes put a complicated app workflow at the beginning. But for most of the time, instead of giving other people a clear overview, we actually overwhelmed them by showing all the screens at once.
We can either put this picture at the end of the presentation or, a better way to show this overview, simplify it to the minimum description just like what kids’ book do.
“Drawing a picture of how this app works within 30 second” forces us to think about how we can clarify our design that is easy to follow. Having this picture in mind also helps keep a team on the same page and focus on the real problem.
Special thanks to professor Marty Siegel and all the teams!
If you have any question or suggestion, please reach out via firstname.lastname@example.org
More about my work at www.iamdoutian.com