Here's the context
You've been in contact with a start-up working in a specific market space and they have hired you to do research and developed a solution that solves the needs and goals of the business and the people they are targeting.
You have scheduled a meeting with them on Monday to get the information you need to start working.
Here's what you need to know
// WHAT IS THIS MEETING?
// BEST TO HAVE A FACILITATOR
Anyone who is involved in
your project should meet in
a meeting before everyone
starts doing work. The kick
off meeting is made up of
business people, product
people and anyone else
that has an accountability
to the project. The meeting
helps to externalize information
that's important for everyone
to know and understand. Once
everyone in the meeting has an
understanding, we can use this
time to prioritize, align and agree
to certain priorities .
1st THE BUSINESS GOALS
2nd THE PRODUCT GOALS
5th THE DEADLINES
6th THE TEAM
4th THE STAKEHOLDERS
7th THE RISKS AND MITIGATIONS
3rd THE USERS AND THEIR GOALS
// THE BUSINESS GOALS:
Business goals are "things a business wants to accomplish" think metrics and how to measure metrics. You want to understand the business goals and how they map to milestones that the software you design will need to achieve.
You’ll want to know key performance indicators (KPI’s) that inform business analytics ex: lower # of support calls. This also helps in connecting user needs and goals, to the business needs/goals. You want to know how well your design decisions informed the business goals in small and large stages.
THE BUSINESS PEOPLE
They are all about RISKS & GOALS. You'll need to inform business folks that developing customer empathy (research) and experimenting with solutions that we will de-risk business unknowns and help to ensure product success. Knowing this will help you make decisions on different ways you can design software. The more you can align on their goals, understand their initiatives and talk their lingo the more valuable you will be at the business level of any company.
Questions YOU can ask
What do you intend to achieve by building software?
How is the business going to benefit from this software experience? - (metrics)
Let’s say the project is over, the application is out and it’s wildly successful, what does the success look like for the software business?
// THE PRODUCT GOALS:
These are what we think the product will do for it's users, that will achieve the business goals. You can’t have a photo taking app if you don’t have a camera. SO a product goal is to "allow users to take photos of their food" These goals can be changed, depending on the research and solution testing outcomes.
THE PRODUCT PEOPLE
These people are usually subject matter experts, designers, product managers and engineers. These people will understand design way more then the business people and they will have questions around specific user interface components and interaction design details. PM’s ARE HERE TO HELP YOU. Remember, your design serves as a communication tool….that's it. End users don’t see your final designs, they see what the engineers built - use your designs to validate usability and align people to the "why" we are doing certain features.
What does your product need to do, to achieve
If your product was a human what would it spend
most it’s time doing?
// THE USERS AND THEIR GOALS:
User centered design. You can also use this meeting to prioritize users if the application has many personas. This will give you the focus and starting point.
THIS IS YOUR AREA
Usually you’ll be called on to handle this part in of the meeting.
You need to capture just high level information about:
• Targeted Market
• Target Users
• Targeted Users Goals & Potential Problems
• What we want to learn about them (Learning goals)
Capture these points above
Who are the people that we are targeting to
achieve the product goals?
What do you know about them?
What problems are most important for
us to solve for them?
What are these people's most important
goals and what's motivating them?
Are they close by? Where can I find them?
Can anyone connect me to them?
What do we want to learn about them????
// THE STAKEHOLDERS:
• People who's job is to make sure this is a success.
• People that need to make decisions on budget and business
results that align & meet the company strategies and initiatives. (KPI's)
• They have a “stake in this” but can’t be with you all the time.
You’ll have design reviews to show results from research and solution experiments every 1-2 weeks. These are the people that can pop into your project and disrupt your user centered design logic with their opinions because they may not trust what’s happening on the project due to a lack of involvement from early on. Involving these people in the process like “Design Sprints” or "user interviews" or user-testing" help everyone align and shared ownership of information, decision and ideas. The more you can involve these people into the USER LOGIC & ALLOW THEM TO GAIN USER EMPATHY —EARLY ON IN THE PROCESS and not just throw them into the designs, the LESS they will tell you how to design (their opinions) and they will build trust with you. The more they trust you, the happier you will be as a designer.
Usually you’ll be called on to handle this part of meeting.
You’ll want to know the following:
– Who makes decision on product and business? - (Design reviews)
– Who has technical knowledge we can use (SME) Subject matter expert.
– Who can help us with finding users to interview?
– What are their schedules and what time is good to have design/progress reviews.
– You may want to interview them on company goals and the success of your project,
this is called a "stakeholder" interview, do this early on in the project.
// THE RISKS AND MITIGATIONS
A risk is anything that can block, disrupt or fail a project or software.
A risk can be turned into a question, and that can give you work by answering that question. Example: (Users will not want video instructions —to—Will video instructions work best for our users or what type of instruction work for our users)?
You’ll want to know what makes a project successful but just as important, you want to know what will make a project unsuccessful.
After you learned about the project context everyone should have time to call out and prioritize risks so that the teams can start focusing on activities that they will intend to mitigate/solve—the most important RISKY ASSUMPTIONS 1ST.
THE BUSINESS PEOPLE
They will love you when you do this. They will always understand the PROJECT/COMPANY problems more than you. You’re way more valuable when you can help them (the business) get answers to their questions by talking to their customers.
When the business is software, this is UX and this is where you are one of the most valuable tools the business can have!!!!!
Remember that, and make sure you get paid very well here. THIS IS NOT CHEAP WORK :)
What are the things that can happen that will make this unsuccessful and not achieve our goals?
Let’s say we failed, what are the things you think caused us to fail? (Pre-mortem)
What’s the 1st thing we can do to start mitigating these unsuccessful events? (Activities to start)