Quit wasting time on your slide deck
Being a research intern at IBM has been a great experience filled with lots of teachable moments regarding ways to contribute to the team, share findings, and use research hacks. I want to share one moment in hopes that it will help you avoid a similar pitfall that happened to me. It involved a Keynote presentation I was working on for a research playback that didn’t go as planned. Here’s what happened.
Final Touch Fridays (FTF!)
It was a Friday afternoon and I was adding the final touches to a 30-slide Keynote. It had a number of transitions, bullet point and picture animations, and carefully worded copy. I spent weeks gathering pics, organizing the content, and doing practice sessions with my core team. This was going to be my first presentation as a new member to the team and I wanted to impress them. I pressed save; that’s when it happened, Keynote crashed!
Noooooo! All of the new work was gone. I was trying to stay calm, but on the inside I wanted to cry. Who was to blame for this mishap? Was it Apple, as the creator of this program? They should’ve fixed this bug. Was it the author of the template I was using? Perhaps he unknowingly provided a corrupted file. Or did I really just have myself to blame for not periodically saving my work? While it would’ve been nice if Siri could’ve comforted me in my moment of despair and offered to help me recreate it (Wishful thinking, but how cool would that have been?), there was no sense in crying about it. I had a few days before the meeting to put something together, AGAIN.
The blessing in disguise
“Deep breaths.” I told myself. Maybe this was a blessing. The crash forced me to take a hard look at what I was saying and how I was saying it. Frankly, for what I was presenting, 30 slides was overkill. Not to mention, I probably would have only had 10 minutes or less to share my analysis.
The early feedback I got on the slides from my peers finally sunk in. Any redundant, obvious, and/or known information they pointed out got deleted. Also I took out 20 slides by replacing image stills with screen recordings, which proved to be a more effective way to show an UX experience on a website. Not only did the second revision take a fraction of time to build as the original version did, it also gave me more confidence in what I was presenting and something my team would be proud of.
On in Fifteen
Meeting day arrived. This 8 AM teleconference call included teams from North Carolina, England, and Austin. I was both nervous and excited because I was representing the core team in my first big team playback. Research was allotted 15 minutes in the agenda, just enough time to share insights and observations, so I thought.
As I sat there on mute, anxiously waiting for the time to share, I began to realize the ebb and flow of this meeting. There didn’t seem to be much of an agenda to this meeting. At any moment, a question could spark a long discussion, in which people would share experiences, opinions, quick observations, etc. Instead of following a set plan, people discussed their research as part of this free-flowing conversation. Nearly all of the key points I had planned to bring up were being referenced in some way. In fact, while in mid discussion, one developer quickly went to the competitor’s site and relayed back their findings. It only took a few seconds to share the crux of his experience.
The call was coming to a close; I was not going to present. I was bummed, but it didn’t matter where the info came from, whether it was from me or someone else, as long as the information got out. Though I didn’t present, I did feel validated knowing my observations and analyses were consistent with others’ observations. More importantly, it was remarkable seeing how fast research could be done and shared.
Lessons learned
This team meeting taught me lessons about time and effort, and alternative ways to share research with the team. Considering these principles can lead you to become a better contributor and agile researcher.
Time is valuable. How you use your time matters. My former manager used to say “fastest path”. In one sense he meant leverage existing resources instead of building new ones (for example, templates) to save time. He also meant get to the point as quickly as possible. What did you do, why did you do it, and why is important to the stakeholder (clients, execs, team members, etc.)? Applying this mindset can help you manage and prioritize your workflow so that you can provide your deliverables in a timely fashion. This will certainly be valuable as deadlines become tighter and workloads get heftier.
No deck needed. There are alternative ways to present information. I got caught up on making a pretty slide deck that I didn’t consider other mediums. You should be open-minded and flexible in using alternative ways to share your findings. Recognizing who your audience is and the context will help you determine the best delivery method. For example, instead of a slide deck, you could show some screen shots while you talk about your subject. If your team uses collaborative tools such as Slack or Box Note, posting in the channel beforehand is a great way to bring others into the conversation early on.
Final Thoughts
My takeaways from this experience are to take the time to decide on the best approach to share your work, and make a thought-out decision before jumping into the workflow.
Make use of digital tools. They will allow you to share faster and they provide a digital archive of the artifacts and the conversation, which is always helpful if you need to reference something later.
Furthermore, using these tools tends to favor the casual over the formal. It took me an hour to organize content in order to speak on one aspect of the competitor’s experience while it took the developer on the call a few seconds to sum up his experience. He told them what he did and why it was interesting. Same topic, same conclusion, but he was able to get his point across more quickly and effectively than I was able to. Casually speaking on the competitor’s site was better for this meeting than my formal presentation.
Through it all, be agile. This is the undercurrent that runs through all of these things. It’s an attitude that influences you work process. It will help you be a better contributor and time-manager. No doubt, some work might get deleted and meetings won’t always go accordingly, but when that happens, you will still be prepared to shine like the star you are. :)
Roosevelt T. Faulkner is a Design Research Intern at IBM based in Austin, Texas. The above article is personal and does not necessarily represent IBM’s positions, strategies or opinions.
