Without doubt, one of the trickier aspects of agile software development is finding a way to keep the “just enough design” component from turning your product ugly. An aeroplane made from car parts.

These days, user interface design is a specialty field. It is recognised as an important aspect of software delivery, largely responsible for the satisfaction (or otherwise) a user feels in using your product. In my view, the agile development idea of allowing features to evolve, even within the development period, does not allow for the application of considered UX design.

It simply does not cater for the working needs of the creative individuals involved. It’s taken a lot (believe me!) for me to come to terms with this, but no, you can’t rush design. Not if you want to look good. Development’s the same, but the tasks involved there are more easily identified and quantified. Designers think differently from function driven developers or project managers. Beautiful design makes them feel good. They see it around them, and they strive to produce it. You can’t tell them that it needs to be done by 3PM tomorrow.

On the other hand, every design studio in the world works to deadlines. At least those that get paid regularly enough to keep the doors open. So how to integrate UX creativity into Scrum?

We’ve tried at all. We wrote separate user stories just for the design aspect, linking them to development user stories. Unmanageable. We assembled user story cards that required interface design on a Kanban wall, having the designers estimate, prioritise and pull them. This led to a disconnection between designers and developers. We tried not touching the UX until the iteration began, ensuring that designers were present during estimation, to give their view on the complexity of their component. Of course, during iteration, developers waited and waited and waited, held up by the nobly lofty goals of the UX guy.

The solution, as is the case with so many workflow issues in Scrum, came down to a well-groomed product backlog, and the commitment of a team.

Embed your UX designer within the scrum team. Given that team should have “all of the skills requisite for the delivery of an increment of working software”, this should be obvious, but given the difficulty we all seem to have with this issue, it’s obviously not a first glance screamer.

The product owner must be organised, keeping the top of the backlog well detailed, sufficient for it least 1 to 2 sprints of potential commitment. UX designers then work ahead of future sprints, closely with the product owner, and in consultation with developers. The key is for the designer to understand the role of his designs as user story detail. They provide clarity and points for further discussion during sprint planning, and make a user story infinitely more estimable.

The designer’s deadline is the first day of a sprint. They can set their own pace, allowing an idea to ruminate and evolve without the pressure of a waiting developer. Aim to have all user stories accompanied by the minimum UX design acceptable to the team by the time preplanning commences. The good part is, that if you’ve only got 90% of stories in this state (a work of art takes time!) Then the sprint can commence, while the designer ties off the loose ends and perfects the remaining 10%.

With the right designer, mindful of his role in delivering team goals, (working software), not just the isolated development ofconceptual diagrams, this works tremendously. Co-locating the designer with the developers and testers makes it even better.