How To Take Charge Of A UX Kickoff Meeting
Email Newsletter
Weekly tips on front-end & UX.
Trusted by 200,000+ folks.
Take a break with a 3D game built on Netlify!
Check the frontend report!
Sponsor OWD on GitHub
Click here to kickstart your project for free in a matter of minutes.I once worked with a digital agency that didn’t know how to hold a kickoff meeting. And they didn’t even know that they didn’t know. Weeks into every project, they’d simply find themselves frustrated over how they’d ended up in a position of following rather than leading.
They would fight to get their good ideas out the door but end up on defense all the time when their clients came back screaming with arguments based on whim and vapor. The agency just couldn’t figure out how to establish itself as the UX leader of its projects, despite being hired to play exactly that role. I’m not even sure they recognized what it meant to lead.
Some think the notion comes off as a little too command-and-control and would prefer something more collaborative. This outlook is a common effect of dealing with bad leadership. You get jaded. You get convinced that leadership is a problem. You want the world to be flat and to lack job titles.
That’s sweet. But it’s a joke.
Leadership is not a dirty word. It’s not about ditching collaboration. It’s not about commandeering the room and shelling out mandates. Leadership is a natural, normal human craving. For a group to succeed — for design to succeed — someone has to establish a vision, a goal, a destination, and help the team get there — inspire the team to get there.
In-house teams often suffer unease over the idea of offending someone through so-called leadership. In fact, if your “clients” are internal, you might have an even harder time getting out in front of a project than a consultant. I understand that. You worry for your job. You worry about upsetting people you have to work with over and over for months, maybe years, to come.
Let’s make this better. Let’s look at how to run a kickoff — how to get yourself into a positive position, where you can steer the ship, rather than crash it into the dock.
The kickoff is where it can all go wrong. You haven’t even started yet, and you’re already stuffing yourself into a position to fight for every recommendation before you even make one.
Literally everything that happens after the kickoff is contingent on what you do during it. For the wealth of information online about how to wireframe, prototype, code and run a usability test, much less is out there to tell a designer how to run a useful kickoff meeting. Even less focuses on the truth about them.
Kickoffs are for far more than laying out a project. They’re for putting yourself into a leadership position.
Here’s how you do it. First, the logistics, then the clincher.
Prep, But Not So Much
As I explained in my Field Guide to UX Strategy, it starts with a project inquiry. Someone comes to you and says, “We’re launching an app,” or, “We’re having trouble getting to the next level,” or even something specific, like, “We want to increase our sign-ups.”
You think you can help — it falls under the UX purview — but first you have to get a whole bunch of information. So, you set up a phone call or in-person meeting. You check out the current website or app, if there is one. You check out other websites like it. You go where Google takes you.
Beyond that are the simple details of scheduling how and when you’ll meet, whether by phone or video or in an office or coffee shop someplace. (This might be the first conversation you have with a client, or you might schedule a more formal session to meet with the whole team and start thinking through an approach to the project.)
This is enough for now. The first thing you’re going to do is ask a lot of questions that Google can’t answer.
Ask The Right Questions
This is the secondary purpose of the kickoff, right behind establishing your leadership position.
Essential, yes — you can’t design a thing without answering all of these questions. But you also can’t design a thing without putting yourself in charge, and you can always ask questions another time.
The gist is this: You need to know what they do, why they’re doing it, what they’ve done, why they did it, what happened, what they hope will happen next, and who’s around to do it.
“Raison D’Être?”
The reason for being.
This bit, pending some research, will feed directly into your UX strategy, which in turn will feed into all of your design decisions. So, yeah, pretty important stuff.
It’s not even a question, actually. Just say it:
“So, tell me about Acme Widgets.”
This usually prompts a decent history of the company, as well as an introduction to the product they want to create or improve. Rarely, though, in the case of startups anyway, does it answer this:
“How do you make money?”
This is partly because not a lot of startups have the answer just yet. It’s partly because they assume you’ll know when a website is ad-supported. It’s partly because, as staff, they think a lot about the currency their service deals in but know next to nothing about how to get more of it — which, let’s face it, is why they called you.
The answer to this question is a major factor in your future decisions. Asking this question not only gives you something to focus on, but lets the stakeholders know you’re focused on the most important of their concerns.
Don’t let them get away with cursory explanations. You need to know how this product should fit into its users’ lives. How it should compare to its competition. Is it different because it’s cheaper? Or because it does a magic trick no one else has pulled off?
This is the heart of a good user experience vision. The “user” part is just as vital as the business’ goals.
“Where Are You Now?”
If they haven’t specified already, you’ll need to ask about the current status of the website or app.
“So, is this new section of the site up now? In the works? Are we starting from scratch?”
This is where you find out about one of the two biggest constraints of every project: time and money. In answering your question, the stakeholder will likely tell you they’re three weeks behind, that they’ve just hired their second programmer after the previous one quit, and that they’ve been planning to launch at the end of the month (which rarely goes as planned).
“Where Have You Been?”
Nothing complicated about this one. But asking this question can help put you several steps ahead:
“What statistics and interviews and other research has been done already? What do you have now that I can review to get up to speed with everything you already know?”
Follow that up with questions like these:
“What approaches have you taken previously?
What has worked?
What hasn’t?
How did you make those decisions?
How did they turn out?
What do you think went wrong in that case?”
Not only will questions like these help to familiarize you with the full scope of the project and its history — likely revealing a whole bunch of politics and skills limitations you need to know about — but it means you can start out by making decisions no one has made before. You will not be recommending things they’ve already thought up. You’re past that point.
“Where Do You Want To Be?”
They’ve probably filled you in a bit already on where they’d like to get to, but getting there means being specific. If it’s an improvement project, don’t rest on answers like, “We just want traffic. As much as we can get.”
Put numbers on it. You can increase a conversion rate by 5%. You can decrease the bounce rate by 10%. Increase sharing. Increase unique page views. Increase completion rates. Decrease completion time. Increase the number of tasks completed per visit. Increase visit frequency. All by some percentage.
If you get specific about these numbers, then you can have a real conversation about what will be affected, as well as about the philosophical considerations. For example:
- Increasing a conversion rate could mean weakening retention rates. Getting more sign-ups is a cakewalk if you don’t care about keeping people around long-term. If you do, it’s a more nuanced problem.
- Increasing unique page views (say, on a content website) could mean increasing the server’s workload. Distributing content across more pages is sleazy, but it works. One alternative is better content.
Anything you do will have an effect, and the good can bring some bad along with it. Pay attention to all of the effects. Detailing what the company wants to achieve lets you sort out what unintended consequences might come up afterward, so that you can decide whether you really want that or not.
“Who’s With Me?”
The fewer the number of people involved, the speedier the communication will be. The fewer decision-makers in charge, the faster the decisions will be. It’s time to find out who’s on the team and who’s an obstacle to it.
For a typical UX project, you want as few decision-makers as possible. Ideally, it’s whoever’s in charge and maybe one other person. Determine who these people are and how you’ll communicate most effectively.
Here are other things you want to know (and take notes because you’ll be talking to all of these people at some point, and each one can affect your decisions):
- the name of everyone on the team;
- their title and role in this project;
- their skill level;
- any constraints at all, whether time zone issues for remote teams, preferred communication and work methods, how efficient each person may or may not be, who has the most history with the company or product — anything you can find out.
Set the expectation right from the start that the UX decision-makers should be two to three people at most, including you (or a senior-level designer, like a vice-president of product design), and that this will speed communication along. Decide how you’ll communicate, how frequently, when to have check-in calls and so on, so that everyone is comfortable.
During the strategy definition phase, keep everyone else informed as needed, and not one bit more. You want their opinions and insights — that’s what stakeholder interviews are for — but you do not want 10 people chiming in on every decision you make. There’s no time for that, plus you’ll risk design by committee.
Establishing the decision-making crew will prime your clients and stakeholders to let you lead. Which brings me to my last point.
Lay It Down
This is the clincher, the primary purpose of the meeting, the part where you get to lay out how you’ll proceed, how you’ll get them through the process, what your part is, what their part is and what happens next. Basically, this tells them that you got this.
The key is to leave no doubt here that the stakeholders are in capable hands. Your relationship will be collaborative, for sure, but you are leading this thing.
What you say here depends entirely on how you’ve decided through the course of this conversation to approach the project. You know what’s been researched, what they’ve tried, how you can learn more — generally, where things are at. By now, you should have a good idea how to arrange a stack of your favorite research and design activities to get to the answer you both need, and to a design you can be proud of later.
It goes something like this. Adapt accordingly.
“Well, here’s how I’d like to approach this. We already have a good amount of stats from existing users and some interviews with power users, so I’ll start by getting familiar with all that. Then, we’ll talk through which users might be good for additional information, and I’ll set up interviews with them. From there, we’ll talk again about any disconnects or similarities we see that could affect the overall vision of the product. I’ll draft a version of a product vision statement, along with some design principles that I think will be important for making you competitive, and some success metrics we can use to track how the design is doing over time.”
Heads up. This next part is key.
“Next, I’ll work on some initial wireframes and prototypes to get a direction going. I’ll post each version of these in the project management app so that we can discuss and agree on them while I start on something else. These will be low-res at first to make sure we have it right before going further. I’ll go over each one with you and explain each recommendation I make, but if you have questions beyond that, definitely let me know so that we can think through them together.”
See what happened there? You set the expectation that you’ll be making recommendations, not taking orders. You made it clear that you’ll be discussing and agreeing on ideas before anything gets refined.
You are now in charge.
This little difference in mindset is all it takes. From now on, demands can be fought off by referring to the kickoff meeting. And they can be prevented altogether by sticking to that last part: presenting and explaining your work, rather than letting the stakeholders view it and get back on the offense when you do something they don’t like.
Do this here and now — during the kickoff, when you have the best chance of establishing your leadership — and you’ll be singing all the way through the project.
Lay It Down
You know what happens here, right? It’s not a question. It’s a statement.
“Here’s what we’ll do first. You send me the research you mentioned, so that I can look that over, and then I’ll check in with you tomorrow with my responses to it and to coordinate the first round of user research.”
And just like that, you’re in the lead.
Read Robert Hoekman Jr’s newest book, Experience Required (New Riders), about how to become a UX leader regardless of your role. Robert also recently authored the free Field Guide to UX Strategy. The free ebook spans 7 chapters based on his 15+ years designing experiences for companies like Adobe, Automattic, Dodge, Intuit, Rackspace and others.
Further Reading
- Hold A Kickoff Meeting Before Diving Into The Design
- Becoming A Better Facilitator
- Involving Clients In Your Mobile Workflow
- Is John The Client Dense or Are You Failing Him?
(cc, jb, al, il, mrn)
