Blank Canvas

What happens when deadlines arrive before requirements do?

Most design projects begin with some level of uncertainty.

Occasionally, they begin with almost none of the answers.

I experienced this while working on a platform for AI-powered digital media creation. The goal was clear, the deadlines were fixed, and stakeholders were ready to move forward. What wasn't clear were the workflows, feature requirements, user behaviors, and countless decisions that would eventually shape the product.

We weren't solving a familiar problem.

We were learning the domain while building the solution.

Seek Expertise Early

One of the biggest mistakes designers can make is assuming they need to have all the answers.

We are experts in design, not necessarily experts in every industry, workflow, or business domain we work with.

In this project, the people who understood the problem best were the stakeholders themselves. Instead of treating discovery as a validation exercise, we treated it as an opportunity to learn from domain experts.

The faster we asked questions, the faster ambiguity started turning into clarity.

Be Comfortable Being Wrong

When entering unfamiliar territory, some assumptions will inevitably be incorrect.

Rather than trying to avoid mistakes, we focused on making them early.

We openly aligned with stakeholders that some decisions would evolve as we learned more about users, workflows, and technical constraints.

The goal wasn't to be right immediately.

The goal was to learn quickly and adapt.

Design is rarely a straight path. Progress often comes from refining assumptions rather than defending them.

Define What Not to Build

As ideas emerged, feature requests grew rapidly.

Instead of treating every request as a requirement, we introduced a simple Parking Lot.

Features that were valuable but not critical for launch were documented separately and revisited later.

This allowed the team to stay focused on delivering a working MVP while avoiding unnecessary complexity.

Sometimes product success comes from deciding what to leave out.

Design With Engineering, Not After Engineering

From the beginning, developers were involved in discovery discussions, workflow reviews, and feature prioritization.

This helped us evaluate feasibility early, reduce rework, and make decisions that aligned with both user needs and delivery timelines.

The strongest product decisions often happen when design and engineering solve problems together rather than handing work between teams.

Clarity Before Screens

Looking back, the most valuable design work happened before the first wireframe was created.

Before flows, components, or prototypes, we needed alignment.

Alignment on goals.

Alignment on scope.

Alignment on priorities.

Only then could design move forward with confidence.

A blank canvas isn't empty.

It's simply a space where clarity hasn't emerged yet.

And sometimes, the designer's most important job isn't creating the solution.

It's helping everyone discover what the problem really is.

Closing Thoughts

Looking back, the biggest lesson wasn't about design frameworks, workshops, or deliverables.

It was about embracing uncertainty.

Not every project arrives with a clear roadmap. Sometimes the only thing you have is a destination and a deadline. In those situations, progress comes from asking questions, involving the right people, testing assumptions, and adapting quickly when you're wrong.

A blank canvas can feel uncomfortable because it forces us to move forward without complete information.

But that's often where the most meaningful product work begins.

Clarity isn't something we wait for.

It's something we create.