“With time and money, it is possible to do anything.”
This is something that one of the developers I worked with always told me when it comes to designing applications. It is true for almost everything in the world.
The problem is that we always need more time and money. Because of that, design planning and project management are important aspects of the design process. Often, people start a project and do not plan it well, which makes the process challenging to manage. This results in higher costs and longer time spent than expected.
Apart from these two factors — which are easy to see because they are represented with a clear value — poor design planning can affect people’s quality of life (who said extra work hours?) and the relationships among the team members.
In this article, we’ll talk about the design planning process and why projects fail without it. We’ll go over the necessary elements of design planning so you can be ready to implement it in your current organization.
Design planning helps create a sense of togetherness among the people working on a project. If the people collaborating know each other and (hopefully) get along well, the process will be much easier. Further, team members will be open to helping each other within the team, and the negotiation process around prioritizing will be much easier.
Some people try to create “ceremonies” for every habit to contribute to this sense of togetherness — for example, having weekly meetings where everyone talks about what they did over the weekend. This sometimes feels artificial, so my trick is to start every meeting by asking how the other person is and what they’ve been up to. This is a great way to get to know your colleagues during group meetings or 1:1s before the meeting agenda begins.
Creating this environment in your team will improve deliverables.
First, let’s highlight the main problems that cause project planning to fail. This way, you can identify whether your product or design team is experiencing this first-hand:
Despite its importance for a project’s success, people do not plan well (or do not plan at all) because they are unaware of its importance. Sometimes, they simply don’t have enough time for strategic thinking.
Planning is much more than a nice thing to do. It is the first thing you must do before opening a Figma file and working on design concepts.
A lack of communication is a major reason for failure. Good communication can prevent many problems from happening.
For example, some years ago, I worked on a developers’ team. My direct manager was the developer’s manager. In one sprint meeting, the product manager assigned me to design a small app for Python developers. The project, I thought, needed to be ready in three weeks.
Though I needed to finish in three weeks, my manager thought that we needed to investigate for one week, reach an agreement on the scope, and then design it for two weeks. After five days, he saw that I was working with Figma and designing the high-fidelity screens. He said, “Why are you working on high-fidelity design when you only need to show some sketches?” That’s when we realized the communication gap.
The best advice I can give is to communicate in small chunks to ensure the information is accurate and aligns with the project goals; even though the planning may be written well, not everyone understands it the same way.
Do you ever see a football coach who plays a match with seven forward players? It doesn’t make sense.
It’s the same in a product team. Not everyone can perform the same tasks, so we must ensure that each person has their own tasks. If not, it will be chaos — there will be no source of truth, and everything will be confusing.
For example, who writes the document with all the planning information? If two people write it separately, we will end up with two plans, which leads to confusion. In this case, the team has to agree on who manages the planning. It can be the PM or the UX designer, but one person must do it, and all team members must know it.
Deadlines help us make decisions and avoid wasting time, and a project that doesn’t have a deadline will never end on time. This is because deadlines help people to make decisions faster. Without them, people will take the time without choosing action.
If team members can’t answer, “What is the goal?” they do not know the task’s mission and will not know how to make decisions.
When I know the goal, I can select where to add the information on the page, how to make it more noticeable, and so on. If I don’t understand the goal, I will make decisions that do not align with it, and apart from that, I won’t be able to explain to other people why I made this decision.
The technology may make sense for the development team, but not for other team members.
For example, designers often want to add animation to a product but don’t understand the technology well. Thus, they don’t realize how long it will take to add it and how it affects the page’s loading speed.
As a result, after a certain point in the process, the developers may say something is not feasible to implement in the time available, so the team needs to redesign and adjust.
Understanding technology must be part of the plan, and all team members must discuss it before making decisions to avoid rework.
Now, we’ll go over the complete design plan process:
Communication is always relevant, especially in processes when many people need to communicate lots of information.
It’s not only what we need to communicate but also how we communicate. You can create brainstorming sessions with your team (especially in new teams with no structure) to deal with all the communication details within the team.
I did this in the past when I joined a team built from scratch. I created a design thinking session to answer questions about communication:
It’s OK if you don’t have all the answers the first time; things will evolve. Just talking about the issues makes it much clearer where the gaps are and that solves many of the future challenges.
The first step is to understand the project goal.
For example, a company’s goal may be to increase the number of people who subscribe to the product after the free trial. Once we know what the company wants to achieve, we have a starting point.
If the goal is unclear, they cannot plan well because the planning starting point is based on the goal. If the goal is more complex, the planning will have more stages; if the goal is smaller, it will have fewer stages.
In addition to understanding what we want to achieve, it is important to ask how we measure the project’s success. This will tell us if we have reached our goal or not.
For example, to improve a user’s conversion from free to paid, we must set a number, like an increase of 15 percent over three months. We have the time and the percentage, which means we can say whether the project is successful or not.
It is like the score in a basketball game. The numbers tell who won and who lost.
Understanding the users, what they want, and why they want it is a basic step in design planning. This research is critical for the process because knowing these three questions is necessary to make good decisions.
The research you need to do depends on the stage of the product and the size of the problem you need to solve. This takes more time for a new product because there are more things to define, such as who the users are.
Add the research step to the design planning, which can include conducting user interviews, examining data from a third party tool, and talking with the product manager, customer success, or other stakeholders about the information.
Also, many designers put a lot of effort and time into this process because they think that more time in this process means better solutions. However, a good solution evaluation only happens when the product is in the user’s hands.
After you have defined these three questions well, you can continue on:
Asking people to understand the domain isn’t in the core planning process, but if the domain is complex and the people need to dig into it to be able to make the design, it should be added to the process.
When I designed the Python product for developers, I didn’t have to be a Python developer to design it, but I did need to understand the topic well. It took me 2–3 days to understand the task because I lack the knowledge. So, if that’s your case, add it to the planning.
We like to design cool things, but not all things are possible — especially for complex products with complicated logic. Plan time for the developers to test and see if the technology supports the idea and the solution. Typically, developers conduct their tests and usually quickly come up with a response on what is possible to do and what is not.
In design and software development, we cannot set a final deadline and be strict with it because we can’t predict all the issues we will have during the process.
But, setting deadlines for the project and the steps is necessary because the deadline forces us to make decisions faster. No one will wait forever for someone to finish the work. During the planning process, I set deadlines to make the process better and faster.
Pro tip: set a deadline for each step in the process, not just the ones at the end.
When we develop a product, everyone wants to add more to it to make it better, but in the end, we have a limited time. Not everything can be delivered in one step, so prioritizing is critical.
We must prioritize and write what we design and what does not. For example:
Popular prioritization frameworks include MoSCoW and a priority matrix.
Feedback is an important step in the process and we need to remember to add it to the planning process. When we need feedback from our product team, we can show them and get feedback whenever we want.
The issue is stakeholders with less time (such as the CEO or CTO) want to see the work, and we can not reach them at any given moment. If this is the case, you can schedule feedback so that everyone sets aside time for it.
After you have all the information, add it to one document that summarizes it well. I like to use the user story and the acceptance criteria format as a base and add more information if needed.
You do not need to use all the sections I show in the example. Still, the three musts for me are:
They are the document’s core and contain the most important information.
You can access a link to the document I use on Google Docs here:
As always, not everything goes according to plan. However, having a plan helps organize the process and resolve any issues more efficiently.
If things change during the process, adapt the planning. For example, if the developers cannot develop your design on time, ask yourself what can be removed from the design that will not hurt too much but can be added next time.
Each time you work with a clear plan, you will see how the design and development process becomes much easier. Even so, you can always improve, so take notes on what did not work well and improve it next time.
A good idea is to hold a retrospective meeting with the team every 2–3 months to discuss how to improve the planning process.
In this article, we talked about the design planning process and how to create it to achieve great results with less effort.
We started by reviewing the issues that make project planning fail, and then we looked at how you can make great project planning for your product with your team.
We reviewed the importance of communication and good relationships between people. Then, we saw the planning process, which included understanding the user and company needs and the goals we must set for the project to make design decisions that align with them.
In the end, I showed you a format to which you can add all the information to have a clear project plan for your next project.
LogRocket lets you replay users' product experiences to visualize struggle, see issues affecting adoption, and combine qualitative and quantitative data so you can create amazing digital experiences.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
Nostalgia-driven aesthetics is a real thing. In this blog, I talk all about 90s website designs — from grunge-inspired typography to quirky GIFs and clashing colors — and what you can learn from them.
You’ll need to read this blog through and through to know what’s working and what’s not in your design. In this one, I break down key performance metrics like task error rates and system performance.
Users see a product; designers see layers. The 5 UX design layers — strategy, scope, structure, skeleton, and surface — help build UIs step by step.
This blog’s all about learning to set up, manage, and use design tokens in design system — all to enable scalable, consistent, and efficient collaboration between designers and developers.
Learn more →
