An agile team values shipping working software in order to gain customer feedback and respond to it. This emphasis on shipping working software, combined with short timelines to ship it in, often only a week or two, puts excessive pressure on designers to deliver designs to engineers in unrealistic time frames. How can a designer survive, let alone succeed in such a team? The key lies in a shift in mindset — to embrace imperfection. Let’s see why.
One of the biggest challenges facing UX designers in agile teams is time. If you feel that it is unrealistic to deliver polished designs within a week, then you’re right! It may not be possible to churn out pixel-perfect mockups at speed, all the time. And it is this expectation that often burns out designers. But it needn’t be this way. Agile teams function in a fundamentally different way than a design agency, and so, as a designer, you must adapt your work accordingly. This doesn’t mean skipping research or getting burned out in handing over polished assets. It’s somewhere in between — letting go of “perfection,” especially when it comes to mockups and functional prototypes.
Every professional strives to put their best foot forward, and designers are no exception. However, agile teams are not great places to be perfectionists, partly because there isn’t much time for it, but mostly because we rarely know what makes something perfect. And, what designers think of as “perfect” is almost never the same as what a user would consider “perfect.”
Instead of aiming for some nebulous version of a perfect design, aim for getting things good enough to learn from and iterate.
In this video, Laura Klein uses the analogy of a familiar household activity to explain how you can train yourself to think in terms of good enough, instead of “perfect.”
The Take Away
Teams that can learn from user feedback and iterate on features tend to stress less about making a product “perfect” before it gets released. They know that, as long as it’s good enough, solves a user problem, and can be learned from, they can go back and make it better later.
Unfortunately, a lot of teams that call themselves agile don’t ever go back and iterate, which makes this a tricky thing to implement. Work with your team to find out what “good enough” means for any given feature and then commit to going back and improving it once you have a better idea of what “perfect” looks like. You may still never make it perfect, but at least you won’t waste a lot of time adding things that make the product worse!
Images
© Interaction Design Foundation, CC BY-SA 3.0
