When I work on a small and simple project, it’s usually easy to manage. There aren’t many people involved, and it’s easier to estimate timelines and keep the budget under control. However, when you move to larger, more complex projects — like redesigning an entire app or tackling a technically challenging feature — the dynamics change. These projects demand more planning, clearer communication, and closer coordination across teams.
You can’t just hope things work out on their own. If you don’t pay attention to the details or stay involved throughout the process, things can go wrong quickly.
In this article, I’ll show you how to manage complex design projects more effectively. We’ll look not just at the design side, but also at communication, budgets, and timelines.
When we talk about complex projects, the first thing that usually comes to mind is the design challenge itself. For example:
These are all examples of design work that feels big and complex.
But if we look closer, we’ll see that complexity is not only about the design itself. Many other factors can make a project feel more difficult, especially on a large scale. Here are a few:
As you can see, project complexity isn’t only about how big a project is. Communication, time pressure, unclear roles, and expectations all add layers of challenge.
Being aware of these factors helps you plan better, work more smoothly, and avoid surprises along the way.
The first step in any complex design process is to understand what needs to be done clearly. If this step is not handled properly, the entire project can become complicated, and the people involved may become confused.
To avoid this, it’s important to sit down with the project members and define the project’s goals, objectives, and constraints. Aligning the goal early ensures that everyone is aligned and working in the same direction.
Think of it like the roots. When the roots are strong, the tree stands tall and stable. The same applies to your project; a clear understanding at the outset builds a strong foundation. A great way to bring this clarity is to hold a kickoff meeting. In this meeting, key questions are answered, and important information is shared. After the meeting, it’s very important to write everything down in a clear and organized way, and then share it with everyone involved. This helps ensure that everyone understands the plan and agrees with it before the design work begins.
Starting the design phase without clarity can lead to confusion, extra work, and delays. In complex projects, setting things clearly from the start is even more critical.
When you’re working on a large project, it’s important to break it down into smaller tasks to make it easier to manage.
For example, I once worked on a project to organize the design system elements in our app. Sometimes, during implementation, developers fail to utilize the design system’s tokens or components. This can cause problems, such as different typography styles or inconsistent colors throughout the product.
To fix this, I decided to take a step-by-step approach. Our system had many parts:
Instead of trying to fix everything at once, I started with typography. Once the typography was fully aligned, I moved on to colors, then cards, and finally dashboards.
Doing one task at a time helped me manage the project better. It also gave the team more confidence, because we saw progress at each step.
Think of it like eating a big sandwich. You don’t eat it all at once. You cut it into smaller pieces and enjoy it one bite at a time. The same idea works for your project. Break the big task into smaller steps, complete one, and then move to the next. It’s easier, faster, and less stressful that way.
Show your progress regularly. Big projects can be stressful, and people want to stay informed about them. They want to know what’s happening at each step and feel that things are under control.
What really matters here is building trust. Everyone involved, product managers, developers, and the CEO, needs to feel confident that the process is moving in the right direction. You don’t always need to set up meetings to share updates. In fact, meetings can be a waste of time if no decisions need to be made. Instead, use simple and quick ways to show your work.
For example, I like to record a short video where I share my screen and walk through what I’ve done. Then, I send the video in a Slack message to the stakeholders. That way, everyone stays in the loop. A message like this works well:
“This week, I worked on the upload file manager. Here’s what I’ve done so far. You can see the results in the video/image.
If you have any questions, please don’t hesitate to ask. Everything is going well and we’re on the right track.”
Updates like this keep everyone informed and confident about the progress.
Please don’t work like a beginner who hides everything and only shows the work at the end, hoping everyone will be happy. That almost never works. Instead, show your work step by step. If there’s a problem, it’s easier to fix it early. If you wait until the end (after a month or two), you might run into a lot of feedback and need to redo a big part of the work. That’s painful and unnecessary.
Don’t wait until the last minute. Always share your work in small pieces, early and often. And remember — it’s always better to communicate too much than too little.
I always recommend releasing updates in small steps.
I know that’s not always possible. Sometimes, such as during a full redesign to match a new brand, it makes sense to ship a major update so the entire product looks and feels consistent. But most of the time, it’s better to release small pieces over time. Every time you ship something that brings value, you’re moving the product forward. Step by step, you build momentum. Start small, then build on it.
Let’s say you’re building a new writing app, like Google Docs or Microsoft Word.
You won’t be able to launch all the features at once. So you start with the basics: people can write plain text. Next, you add editing options, bold, italic, underline, and colors. Then come the integrations and advanced features. This approach has two big advantages:
Keeping a good rhythm matters. When the team sees results often, they feel more engaged and excited. And if something breaks, the team can fix it fast and keep moving. So when you’re tackling big projects, release them in small parts, often. It’s better for your users, your product, and your team.
Communication is the most crucial aspect of any design project, particularly large ones. Large projects are complex and involve many people, which makes clear communication essential.
Here are some common problems and how to fix them:
Everyone involved needs to understand the domain and context of the project. When the team shares the same understanding, communication becomes smoother and more consistent.
In complex projects, I usually run a session to explain the domain and record it. That way, when someone new joins the team, they can just watch the recording. It saves me from having to repeat the same explanation over and over.
Decisions need to be documented and stored in one location. I use a document called “User Story Notes” to track all the important choices the team makes.
After every meeting, I update the doc with what we decided and why. A day later, most people forget the details, but this doc keeps everything clear.
If we change direction or a decision becomes irrelevant, I remove it. Keeping this document up to date prevents confusion, avoids repeating the same discussions, and provides the team with a clear source of truth.
People sometimes don’t know who is responsible for what. That leads to confusion and missed tasks.
I like to create a simple team chart that shows who’s involved in the project and what each person is responsible for. If anything is unclear, we can set up a quick meeting to align.
For example, if it’s not clear who should write the PRD, is it the product manager, designer, developer, or CEO, we talk it through and agree on it together. Everyone should be on the same page from the start.
Stakeholders sometimes give vague feedback. Don’t just say “OK” and move on. Ask follow-up questions to understand what they really mean.
If you don’t, you risk going in the wrong direction. Then, in the next meeting, they’ll expect changes you didn’t catch, and that creates delays.
Design and development teams work closely, and a significant amount of information is exchanged between them. That’s why it’s so important for both sides to collaborate closely throughout a complex project.
I always say developers are not just there to “build” what designers create. I like to involve them in every stage of the project, especially in complex work where technical decisions are critical. But this isn’t just about solving technical problems. It’s also about making developers feel like they’re part of the project. When they help shape the design, they understand it better and feel a deeper connection to the outcome. This leads to better and more accurate implementation.
I recall a project where I designed a complex tool for developers. The technical challenges were big, so I made sure to involve the dev team early.
In this specific case, the tool was built for developers, making their input essential. I shared questions during meetings and followed up with brief Slack messages or short videos to clarify ideas or solicit feedback. That helped us make decisions together in real-time. Because they were part of the design process, not just the build, the developers understood the goals clearly. And because I understood their constraints better, we worked faster and built a better product.
When you’re working on a big project, I strongly recommend creating a roadmap.
A roadmap gives your team confidence. It shows there’s a clear plan to get the work done and helps everyone understand what’s coming next.
Think of it like planning a trip. Before you go, you map out where you’re going and the order in which you’ll visit each place. A product roadmap works the same way. It breaks the journey into steps, helping everyone see how you’ll get from start to finish.
Let’s take an example. Imagine you’re building a new task management app. The ultimate goal is for users to manage all their tasks across web, iOS, and Android platforms. But instead of trying to do everything at once, you can create a roadmap like this:
A roadmap like this builds trust. It demonstrates to the team, leadership, and stakeholders that there is a real plan and progress is being made. It also helps you plan public releases in a smart, structured way. Without a roadmap, people can feel lost. That’s especially true when the project is big and the goal feels far away. So use a roadmap to show the path forward. It keeps your team, stakeholders, and users aligned and confident.
Pro tip — When I need to build a roadmap, I record a meeting with the key people involved. Then I run the transcript through an AI tool to generate a first draft. It doesn’t do everything, but it gets me 65% of the way there. After that, I edit the rest to make sure it matches the actual plan.
Before releasing a feature, especially in large projects, it’s important to test carefully in the test environment. I know there’s usually a QA process with testers. But what I’m talking about here is Design QA, a separate step where the designer checks if the feature was built as planned and matches the visual design in Figma.
This step helps catch any gaps between design and development, and it improves the overall quality of the final result. Here’s how I like to do it:
I added a column in the Trello board between “Development” and “QA” called “Design QA”. When the development team finishes a task, I test it before it is passed on to the QA team. In this step, I often find parts of the design that weren’t implemented correctly or small bugs that can be fixed right away. That means the QA team starts testing something that’s already closer to the final, polished version. It keeps the process smoother and leads to more accurate, high-quality results for the user.
Large projects often come with tight deadlines. Clients and stakeholders usually want to see results quickly.
For small projects, estimating the time required is usually straightforward. But for bigger or more complex projects, it’s much harder to predict the timeline.
One way to manage this is to break the work into smaller steps. When tasks are smaller, it’s easier to estimate how long each one will take. This also makes it easier to show progress along the way. After finishing each step, you can share updates with the team or the client. That helps everyone see continuous progress, which builds trust and keeps the momentum going.
This is how I like to work, because it makes the process feel more manageable.
I also recommend creating a simple flow or plan, such as a roadmap, that outlines what will be done and when. Share this with stakeholders so they always know what to expect. Here’s a trick I use often.
If you can’t confidently estimate a task, break it into smaller tasks. Smaller tasks are easier to plan and schedule. Think of it like building a house. You may not know exactly how long the entire project will take, but you can estimate the time it will take to paint a single room. That’s much easier to plan around.
This approach helps you stay ahead of deadlines. And if you do need more time, you’ll know that earlier and can communicate it clearly.
Another option is to reduce the project size to fit the time you have. In that case, focus on the core features that bring the most value. For example, if you’re building a text editor, the essential features might be:
That’s enough to launch a useful version on time. So, if the deadline can’t be moved, make the project smaller. Focus on the most important parts, finish them well, and deliver on time.
Metrics help you understand if what you’re building is actually working. Here are a few things to keep in mind when using them:
1. Start with a clear success metric — Big projects take time and effort, so you need a way to measure success. If you don’t set a metric at the beginning, you might launch something without knowing whether it really worked. Even if the feature looks good or feels complete, the team won’t know if it actually solved the problem
2. Measure what matters, not just what’s easy — It’s tempting to track easy metrics like clicks, but they don’t always reflect real impact. Instead of asking, “How many users clicked the button?” ask, “How many started and completed the payment process?” That tells you if the design is doing its job. Before choosing a metric, step back and ask — What’s the actual goal? What outcome matters most? Pick a metric that tracks that goal — and don’t worry if it takes a few tries to get it right
3. Align the team around the same metric — Everyone on the team, designers, developers, product managers, and QA testers, should know the main metric. When the whole team understands the goal and how it’s being measured, it becomes easier to make decisions. You can ask questions like, “Will this change help improve the metric?” If the answer is yes, you move forward. If not, it might be worth rethinking. When everyone is aligned on the metric, the team moves more efficiently, collaborates more effectively, and builds stronger products
Clients often come with big ideas but small budgets. It’s more of a business issue than a design issue, and it requires careful handling. Some people try to deal with this by negotiating the price. But the question is — How far can you go with price negotiation? At some point, the price may no longer match the value of your work.
In my view, a better solution is not to lower your price, but to scale down the project to match the client’s budget. That way, you still get paid fairly, and the client still gets something valuable.
Let me give you an example. A client once asked me to design a very advanced automation process for their app. But their budget was too small, not just for my design work, but also for hiring an automation expert. So instead, we worked together to scale down the project. We focused on a simpler version of the solution that still gave value and fit their budget.
Of course, this won’t work in every case. Some clients are challenging to manage and expect a comprehensive solution at a low price. However, in most cases, adjusting the scope, rather than the price, is the best way to keep things fair. It protects your income and, more importantly, it keeps you comfortable and motivated to do the work. No one wants to build a huge project and get paid like it’s a small one.
Managing large, complex UX projects isn’t just about tackling big design challenges — it’s about leading the whole process with intention. From unclear ownership to tight deadlines, these projects come with moving parts that demand structure, alignment, and momentum.
Here’s how to stay in control:
In short, lead with clarity, communicate often, and deliver in layers. That’s how you make complex UX projects feel less overwhelming — and far more successful.
LogRocket's Galileo AI watches sessions and understands user feedback for you, automating the most time-intensive parts of your job and giving you more time to focus on great design.
See how design choices, interactions, and issues affect your users — get a demo of LogRocket today.
We’ve all made silly mistakes in apps — clicked the wrong thing, deleted a file too soon. This guide walks through 12 real UX examples that help users avoid those moments entirely.
Users rarely welcome change, even when it improves their experience. Learn how to communicate updates, handle pushback, and keep users from jumping ship.
Documentation may not be your favorite part of the UX design process, but it’s crucial to the success of any design project.
I’ve spent enough time designing with WCAG 2.2 to know it’s not enough. Here’s why I’m skeptical and cautiously hopeful about WCAG 3.0.
Learn more →
