One insight from Laura Klein that stuck with me is that in a minimum viable product, teams often forget the word “viable.”
A thing that surprised me while studying agile product development is how psychological it is.
We often talk about agile as if it were purely a process. There are sprints, backlogs, standups, and planning sessions. Everything seems procedural and structured. But underneath those rituals is something more uncomfortable for designers.
Agile asks designers to release work before it feels finished. This is something Laura Klein talks about directly in the course I’ve been taking. Designing small features and releasing them early sounds reasonable in theory. In practice, it often triggers one of the designers’ deepest fears: shipping something imperfect and untested. That fear is not entirely irrational.
The missing word in MVP
When teams talk about MVPs, the conversation often focuses on the word “minimum.” The goal becomes building the smallest possible thing and getting it out the door as quickly as possible. But Laura Klein repeatedly emphasizes that the most important word in MVP is viable.
The first version of a feature can absolutely be small. But it cannot be unusable. If what is being released is confusing, broken, or frustrating, we don’t learn anything meaningful from it.
Users won’t reject the idea. They’ll reject the experience.
That distinction matters because agile relies heavily on feedback loops. Teams release something, observe how people use it, and then make improvements. But if the initial version is poorly designed, the feedback becomes unreliable.
Instead of learning whether the concept works, you only learn that people don’t like bad products. Which isn’t exactly a groundbreaking insight.
The real reason designers hesitate
Interestingly, the resistance designers feel toward shipping early versions of features isn’t always about perfectionism. In interviews and discussions shared in the course, many designers said they were actually comfortable releasing imperfect work if they believed the team would come back to improve it.
The problem is that many teams don’t.
A feature gets shipped, celebrated, and then quietly abandoned. The team moves on to the next item in the backlog, and the imperfect version becomes permanent. From a designer’s perspective, that can feel like failing users.
Iteration is what makes early releases meaningful. Without it, agile becomes little more than rushing features into production.
Iteration isn’t just adding features
One of the most important distinctions I learned from the course is that iteration doesn’t simply mean adding more functionality. True iteration involves cycles of release, feedback, and improvement. Sometimes that improvement takes the form of small tweaks. Other times, it requires bigger changes to how something is structured.
This is where the idea of refactoring comes in.
In engineering, refactoring usually means changing the internal structure of code without changing how it behaves for users. Developers might rewrite parts of a system to make it more efficient, easier to maintain, or less prone to bugs.
Designers sometimes need to do something similar.
Imagine a product that started with a simple navigation structure. At first, the app only had a few sections, so a top navigation bar worked perfectly. Over time, more features are added. A section showing previously applied jobs. Another section for learning resources. Maybe tools for building stronger profiles. Eventually, the navigation starts to feel crowded. What once worked well no longer supports the growing complexity of the product.
At that point, the design may need to be refactored. The team might reorganize the navigation structure or move to a different layout that accommodates more content. The functionality hasn’t changed. Users can still access the same features. But the structure has evolved to support future growth.
Why refactoring matters
Knowing that refactoring is possible changes how designers think about early decisions. If every design choice had to support every possible future scenario, we would never release anything. The uncertainty would be paralyzing. But if the team accepts that the product will evolve, it becomes easier to focus on what works best right now.
That doesn’t mean designing carelessly. It means designing responsibly for the present while leaving room to adapt in the future. Agile teams don’t try to predict everything. They build something useful, observe how it behaves in the real world, and improve it continuously.
The balance designers have to learn
For designers, this creates a difficult balance. On one hand, we want to anticipate future needs and build systems that scale gracefully. On the other hand, we know that many assumptions will be wrong until users actually interact with the product.
Iteration allows those two realities to coexist. We design something that solves today’s problem. Then we watch, learn, and refine. Sometimes those refinements are small adjustments. Other times, they require bigger structural changes.
Either way, the product improves over time. Because the “perfect” solution we imagine before users ever touch something is usually… theoretical.
The article originally appeared on Substack.
Featured image courtesy: Glenn Carstens-Peters.
The post The Part of Agile Designers Fear the Most: Imperfect Work appeared first on UX Magazine.
This post first appeared on Read More