Search
  • Shira Kates

Before Kickoff - Time to Align & Define





Before you Begin

The first successful step of any product or service design project is assembling the right team. As a team, you should spend some time forming; that is, talking about roles and getting clarity on responsibilities, tools, ways of working, and how often you’ll meet. Most teams intend to do this but never actually do it because they imagine everyone is already on the same page (they’re not) or there’s not enough time (there is).


You’ll want to know who is responsible for making decisions on the team. In teams where the hierarchies are fairly flat or you have a culture of consensus, you may wish to designate a decider; someone who can get the team unstuck, if needed. This person doesn’t need to have any particular power or seniority; they need only to be willing to decide.


Now that you have a team, it’s time to define the vision.


Have you ever worked on a project where conflict was the norm and, despite attempts to be agile, the team moved at the speed of a sloth? Chances are, you have because it happens all the time. Why? Usually it’s because the vision is unformed or unclear, the team isn’t motivated to achieve the vision, or there’s a failure of leadership.


As a designer, you can help prevent these situations by asking the team to adopt a very simple kickoff meeting format, called the Vision Alignment Brief (VAB) kickoff. The VAB is not just place to capture the vision. It’s also a central hub for all project documentation, with links to user stories, past research, discussion guides, research trackers, wireframes, notes, and recordings.


Schedule 60 minutes with no more than five stakeholders to define the what, why, and how of a project. In the meeting, you’ll interview the stakeholders and writing down their answers. Ask questions like:

  • What is the problem we’re solving or the opportunity we’re exploring?

  • Why this? Why now?

  • What do we know? What do we wish to know?

  • What’s in or out of scope?

  • What approach will we take?

  • What’s the best thing that could happen? The worst?

Call out any dissenting views as an opportunity to align and decide.

Your goal is to understand the underlying assumptions and hypotheses. We do this, not to hold yet another meeting, but to get the whole team on the same page and to force us to memorialize, in writing, all the ingredients we need to be successful: clear goals, clear scope, our unanswered questions, what success looks, and how we’ll assess the impact of our work.

We believe that [doing something] will allow [specific segment] to [benefit to be achieved]. We’ll know this is true when [measurable result occurs].

As seen above, the fill-in-your-own-answer Madlibs format allows hypotheses to be conveyed as simple statements, so the research team can plan useful studies. Vision Statements are the heart of the VAB and must be crafted with care, usually by the Product Owner. So ask your Product Owner to craft about four of them (no more than six) before the meeting for best results. If not, you can write them together, live, but doing so can give some folks performance anxiety. Preparation will save you the hassle of word-smithing in realtime.


The VAB stays in the forefront throughout the project. It’s revisited whenever new information is added or when milestones are completed. Without this revisit-able alignment exercise, the project can start to veer out of scope.


Try to start every design engagement by taking this time to understand the problem, look for the biggest perceived opportunities, and write up a few (preferably data-informed) hypotheses you can test. It’s important that everyone knows what’s being explored and why.


You may find that hypotheses started as a hunch in the Product Owner’s head. Work with these if you like, but also strive to generate hypotheses informed by data. In an ideal world, a hypothesis is formed by looking at a variety of quantitative and qualitative input. Ideally, some generative or needs-finding research has led you to this point. Hypotheses founded in data are likely to represent a slice of reality about the market and your customer.


In most cases though, someone, usually the Product Owner or CEO, has simply come to a conclusion as a result of a conversation, buzzword overheard, or a competitor’s actions. And now they need you to stop everything because THIS IDEA IS THE NEXT BIG THING AND WE HAVE TO START DOING IT RIGHT NOW. In fact, they’re ready to just skip to the design — or maybe even development (yikes!).


But if you’re lucky, they’ve decided to engage you for further research, to investigate the opportunity, to go broad before narrowing — and to understand the particulars of the central scenario, use case, and features. Either way, you’ll want to align the team and define the vision before planning your research.


_________

About the author:

Shira Kates is the Chief Design Officer for CivicActions, where her team applies research insights to design more delightful, accessible, and inclusive government experiences. For over 15 years, Shira worked with agencies, startups, and world-leading companies in Silicon Valley. At Google, she helped design Maps local Immersive Search experiences and later led product design for Yahoo Ads & Data. She’s also consulted with HP, Facebook, and Microsoft as a Senior Strategist at Accenture Interactive (formerly Wirestone). As a lover of coffee and culture, Shira also co-owns The Granddaddy cafe in NYC. She earned an MBA in Design Strategy from California College of the Arts.

0 views0 comments

Recent Posts

See All