Working without a due date
Overview
This framework helps designers navigate projects that don't have a clearly defined due date, ensuring productive use of time while maintaining alignment with project goals.
🎯 Key Rule
"We are never ahead of schedule for a project."
If you have time and clarity, there's always valuable design work to be done. The goal is to keep your wireframes as updated and advanced as possible based on the information you have.
🤔 The Situation
You're working on a project that doesn't have a firm deadline or due date. You might be wondering:
Should I slow down?
How much should I work on this?
What if I "finish" too early?
Is there a risk of doing too much?
Common scenario: This typically happens when we have Refinement running in parallel with Design. While the PM and client are still refining requirements, you're designing based on the information available.
The answer: Keep advancing your design work as long as you have clarity about what needs to be designed.
⚙️ Understanding Parallel Workflows
Refinement + Design in Parallel
This is a common situation at LowCode where:
The PM is actively refining requirements with the client
Details are still being discussed and clarified
You have enough information to start designing
But the full picture isn't complete yet
What this means for you:
You'll receive information gradually
Requirements may evolve as refinement progresses
There won't be a fixed "design phase end date" initially
Your work informs and supports the refinement process
Your role in this scenario:
Design based on current understanding
Document questions that arise from your design work
These questions help the PM refine requirements with the client
Keep advancing as new information becomes available
💡 The Value of Questions That Emerge During Design
Why Starting the Wireframe is Critical
Here's the reality: Documentation like PRDs, user flows, and data sheets can seem complete and clear on paper. You might not have any questions when reading them. But the real questions emerge when you start translating that information into actual screens.
What Happens When You Design:
Abstract concepts become concrete interfaces
Edge cases reveal themselves
Missing information becomes obvious
User flow gaps appear
Technical constraints surface
Business logic questions arise
This is why advancing the wireframe is so valuable—even without a due date. The act of designing generates the questions that need to be answered.
Examples of Questions That Emerge:
From a PRD that seemed clear:
"The PRD says users can 'manage their team'—but what specific actions can they take? Add, remove, edit roles, change permissions?"
"It mentions 'notifications'—but where do users see them? A bell icon? A dedicated page? Both?"
"The flow shows 'admin approval'—but what does the admin see? How do they approve or reject?"
From user flows that seemed complete:
"The flow shows 'User submits form'—but what happens if they leave fields empty? Is there inline validation? What are the fields that the user needs to complete?"
"After submission, it goes to 'Success'—but can users edit their submission after? Where's that action?"
"The flow splits between 'New User' and 'Existing User'—but how does the system know? What's the logic?"
From technical requirements:
"The data sheet lists 'User Permissions'—but how granular are they? Can admins customize them?"
"It mentions 'real-time updates'—is this actually feasible? Should we design an auto-refresh instead?"
✅ What This Means in Practice
Always Move Forward
If you have clarity on any aspect of the project, continue designing:
Refine existing wireframes
Add more detail to flows
Design additional screens or states
Document edge cases
Improve interaction patterns
Polish visual hierarchy
Clarity is Your Guide
The only thing that should pause your work is lack of clarity, not lack of urgency.
You should keep working when:
You understand the user needs for a feature
You have information about user flows
You know what screens or components are needed
You can make educated assumptions and document them
There are obvious next steps in the design
You should pause or shift focus when:
Critical information is missing that would invalidate your work
You're waiting for stakeholder alignment
Technical constraints are unclear and need confirmation
You've designed everything you have clarity on
🚀 How to Use Your Time Effectively
1. Advance the Wireframes
Keep your wireframes as complete and updated as possible:
Design all known screens and states
Add loading states, empty states, error states
Document interactions and transitions
Flesh out edge cases
Add notes following the LC color coding
2. Increase Fidelity
If low-fidelity wireframes are done, consider:
Adding more detail to existing screens
Creating higher-fidelity versions (when applicable)
Refining layouts and visual hierarchy
3. Fill in the Gaps
Look for missing pieces:
Standard screens (Profile, Settings, Help)
Onboarding flows
Success and confirmation messages
Navigation patterns
Responsive considerations
4. Improve Quality
Polish what you have:
Review consistency across screens
Improve accessibility considerations
Refine copy and microcopy
Ensure design system alignment
5. Prepare for Development
Make the handoff easier:
Add detailed specifications
Document component states
Prepare assets and resources
Organize your Figma file clearly
🔄 Remember
We are never ahead of schedule. If you have clarity and time, there's always valuable design work to be done. The more complete and polished your wireframes are, the smoother the development process will be.
Set internal milestones proactively. Even when hard deadlines don't exist, you and your PM should establish checkpoints to keep work flowing and prevent surprise requests.
The questions you uncover while designing are just as valuable as the designs themselves. Documentation can seem complete on paper, but the act of designing reveals the gaps, edge cases, and missing details that need to be addressed.
Your role: Design actively, question constantly, document thoroughly, communicate clearly, and stay aligned with your team through regular checkpoints.
This framework is living documentation. If you encounter situations not covered here or have suggestions for improvement, share feedback with the team.