Starting a new project is an exciting endeavor. You have the opportunity to build something from scratch, apply all the learnings you acquired in previous projects, courses and articles you read, as well as fostering new relationships with stakeholders and team members.

But kicking off projects can be frightening as well. Working with people you might have not worked before, tight deadlines, scope creep, uncertainty. It can be easy to go off the rails at any given time.

After kicking off (and struggling with) a wide variety of projects, I decided to compile my learnings and create a framework that could better help me approach new endeavors.

A story told in three acts

In a nutshell, when you’re starting a new project, all the efforts should be allocated in three buckets: inquiry, foundation, and automation.

Inquiry: Finding your local maximum

The biggest misconception of new projects is thinking that they start with the kickoff meeting. This could not be further from the truth.

Unless you’re your own client, chances are that previous conversations and decisions happened before you were introduced to the project: business people, sales people, solutions architects, sales engineers, people crafting Requests for Proposals (RFPs), product managers. All of them shaping the direction of the project through the design decisions they make, whether conscious or unconsciously.

A project does not start with the kickoff meeting. It starts the night the main stakeholder has a bad sleep thinking about the problem.

This bad night is Day Zero.

Everything that happens between Day Zero and the kickoff meeting is up to you to find out. Like a detective following footsteps, you will need to uncover expectations, decisions, misconceptions, and agreements in order to get the big picture of the project before starting laying out any plan.

Of course, there might be a lot of externalities out of your control.

Maybe the client took too long to acknowledge there was a problem or didn’t know who to look for. From my experience at least, clients are used to articulating problems by stating the solutions upfront. Only a few acknowledge:

“We’ve got some weird stuff happening in the company, we need you to fix it up.”

Instead, they give you a very specific series of requirements:

“We’ve got this already figured it out, you just carry out the plan.”

This is what inquiry is all about: untangling the problem as much as possible and working backward until uncovering the underlying motivations (and fears) that triggered the project.

During this inquiry phase, you want to find your local maximum: the best position for you to kick off the project, and take the opportunity to make a great first impression with your stakeholders.

To do so, the following considerations should be on your radar.

Defining success

As designers, we are the champions of operating with an ought to be mindset. We analyze an existing situation, then figure out a preferred one by empathizing, defining, ideating, prototyping, and validating our hypotheses.

However, introducing change to an organization might be frightening. As Chris Do argues:

Clients don’t choose the best option. They choose the least risky option.

To mitigate client risk aversion, you need to define a common vision of
success – the positive outcome to achieve.

If you do not appeal to the organization’s goals, you might not get their buy-in. If you don’t consider your own company goals, the project won’t contribute to the overall vision, and if you don’t take into consideration your own definition of success, where will you find the motivation to perform at your best?

Consider the following questions:

• What does success look like for the company requesting the project?
• How will success be measured? (KPIs, OKRs)
• What does success look like for your company?
• What does success look like for yourself? What is the better version of you after the project?

About the organization

A lot of folks think that UX is all about being user-centered (my guess is that it has to do with the name). I prefer to think of my discipline as human-centered, as it not only involves users but people in a broader sense: clients, team members, customers.

Our job is to provide a fair exchange of value between all the actors, as no relationship can last if it is unbalanced.

• How are the organization’s culture and decision-making style?
• What does the org chart look like?
• What does the stakeholder ecosystem look like? Who is the decision maker?

About the team

It does not matter how well-designed and innovative your solution is, if the team is not capable of building it, it will be a huge waste of time and resources. Getting to know your team should be on top of your priorities.

• What are the team capabilities and strengths?
• What industries, technologies or frameworks do they have experience with?
• What are the team expectations?

In addition, you should consider as your allies not only the execution team but stakeholders as well, as their input (and personal agendas) might have a huge influence on the project.

As Joe Natoli says:

“Make me look good with my boss” never makes it to the requirements list, but it probably should.

Consider how to earn the trust of your team members by taking the first step and getting to know them. You never fail by appealing to somebody’s self-interest.

• What are they trying to get out of the project?
• How aligned is the outcome of the project with their aspirations?

About the brand

I haven’t known a company that doesn’t care about its brand. You should honor your clients by considering their brand guidelines and people who make branding decisions, as well as the values the brand communicates.

• What are the key brand elements of the organization?
• What are the brand resources you can get from the organization?
• Who makes brand decisions in the organization?

Time to Shine: The Kickoff Meeting

The kickoff meeting is the transitioning point between inquiry and the following phases.

The most important thing to grasp about the kickoff meeting is the opportunities it provides to take the lead of the project. By showing all your prep work and asking the right questions, you have the chance to convey a position of leadership.

Foundation: Designing the right product

Great job so far. You went through all the available information you had at hand. You exhausted all the resources in front of you on a journey to unveil the truth. And still, you left a lot of questions unanswered. But don’t worry, we have a full phase dedicated to addressing them: foundation.

In the context of a project, doing foundation (also known as discovery) never ends. It is an ongoing effort of learning and adapting in the light of new evidence.

Discovery activities

In his book Practical Design Discovery, author Dan M. Brown introduces a framework for conducting discovery efforts, divided into gathering, processing, exploring, and focusing.

• What activities can be done to gather new information?
• What activities can be done to process what the team learned?
• What activities can be done to explore different approaches?
• What activities can be done to focus on a particular approach?

Organizational research

Inquiry helped you taking the pulse of the organization you’re working with. Now it is time to run a full diagnosis and tackle some of the questions left unanswered. You might need to rephrase your research questions into interview questions at this point.

The following activities can help address the questions:

• Stakeholder interviews?
• Stakeholder maps?
• As-is Service blueprints?
• Subject-matter expert interviews?

User research

Want your users to fall in love with your designs? Fall in love with your users.
 — Dana Chisnell.

The question is not whether you should conduct user research or not; the question is how to do it effectively, as it might be difficult for stakeholders to see the value, or for the execution team to fit research efforts into the development cycle.

One piece of advice: it is not about doing big research upfront. The most effective approach is to do less research, but more often.

Instead of spending one month in advance of the development team doing research, do it for about third of that time, with all your team members. You won’t need to do any debrief, as the entire team witnessed firsthand the behaviors and struggles of the representative users. The question is: what to learn from them?

Consider the following questions:

• What does their day-to-day look like? How does context affect their behaviors?
• What motivates them? What are they trying to accomplish? What makes them feel like superheroes?
• What is getting in the middle of them and their goals?
• How are they currently solving their problems? How effective is the solution?

Inquiry might have given you some answers, but more importantly, assumptions: the known unknowns. You can define how to reduce uncertainty by conducting some of the following methods.

• User interviews?
• Contextual inquiry?
• Dairy studies?
• Competitive research?
• Behavioral metrics? Demographic metrics? Sentiment analysis?

Modeling your insights

Right after collecting sufficient information about the organization, the users, and the context around the problem, you can model the data so it is accessible to the team, as well as open for discussion and iteration. These are some artifacts you can leverage:

• Personas?
• Affinity Diagrams?
• Job Stories?
• Scenarios?
• Storyboards?

Automation: Designing the product right

While there is a clear transition between inquiry and foundation, switching between foundation and automation is a different story. In fact, there might not be a transition at all, as both foundation and automation can dance together for the rest of the project.

Think of automation as a series of activities the team will be running in the background throughout the project, in order to become more effective when performing discovery and delivery activities.

The key principle of automation is thinking in systems.

In his book Atomic Habits, James Clear emphasizes on the importance of focusing on systems instead of goals when dealing with habits, as goals might have a very short shelf-life, while well-designed systems can thrive in the long-term.

You do not rise to the level of your goals — you fall to the level of your systems.

This advice can be applied to your day-to-day work. It does not matter how well-intentioned and talented your team is, if the systems that support the collaboration are not scalable, the outcome will not be a promising one.

Automate the direction of your project by having in mind these considerations.

Cross-functional collaboration

Imagine you have a team of three members. Making decisions and collaborating should be fairly straightforward – any argument would need three points of agreement. Now think about a team of 7. They would need 21 points of agreement to move a decision forward. A team of 12? 66 points of agreement. Utter chaos.

This phenomenon is known as the points-of-agreement model. Sometimes you cannot control having large teams, but you can automate the way decisions are made, and how every team member interacts in benefit of the whole system.

Source: Meeting Design — Kevin Hoffman. Rosenfeld Media

Consider how to automate the following systems:

• A handoff between designers and developers?
• What will be the definition of ready for dev?
• How will the team keep consistency and UI scalability?
• Content handling? Who captures error messages? Where?
• How will the Design QA process work? In which environment?
• How will designers and the rest of the team file inconsistencies in the UI? Through JIRA tickets?

Two–way conversation with customers

Back in the day, when software was shipped in boxes, it was hard to gauge the value delivered to customers – there was no feedback loop.

Things have changed. We now have a wide variety of ways to gather insights from customers in order to learn about their behaviors and validate our hypotheses. This feedback loop, or in the words of Jeff Gothelf, the 2-way conversation with the market, should be systemized as well.

• What will be the cadence of discovering customer behaviors?
• How will representative users’ discovery work?
• What will be the cadence of validating product ideas with potential users?
• How will the personas be iterated in the light of new information?

Main Takeaways

We barely scratched the surface of all the activities you can perform when starting a new project. They might seem overwhelming and time-consuming at first glance, but will pay in spades over the long-run, as they will help you lay out a solid basis for you and your team to be high-performant across the entire project.

Your one-stop shop resource

Fortunately, you don’t need to memorize all these activities and questions when starting a new project. You can find them in more detail on a Trello Board I created for you to copy and tweak to suit your own requirements and circumstances.

Download this comprehensive UX guide here.

Special thanks to Elba Ornelas for her stellar editorial skills and feedback, and Itzel Barreto for crafting amazing illustrations for this story.