Agile software development methodologies steer us to forego detailed UI design before we're ready to implement. Instead, we focus on designing as we go. While this might seem sensible to development teams, there still might be some discomfort in not knowing precisely what business owners and stakeholders want. Spend too little time on beautification, and the stakeholders might not like it. Spend too much time, and the stakeholders might be disappointed by how little got done.
In Scrum, we resolve communication and expectation problems like this with the Definition of Done. The Definition of Done creates a 'contract' to level-set expectations between developers and stakeholders. But how do you write a 'contract' for something like UI/UX? Here's what our team thought:
Including a statement in the definition of done that the UI should match the acceptance criteria seems like a good idea. I consistently see scope creep introduced by UI mockups that were changed after the PBI was Acceptance Criteria’d and pointed or the UX resource doesn’t pay any attention to the acceptance criteria of a PBI at all. They end up adding features that have not yet been discussed and then confusion ensues when the team is reviewing the feature.
A vision of "done" for UX must be agreed on by the team for each story in each sprint. The owner draws the line between acceptable and overdone with input from the team. For teams in a well-developed existing environment, everybody probably already knows what "done" means for UX, and there is probably an established UX framework to make it happen, so it doesn't need to be explicitly defined for each effort. When working on the UX framework itself, the team must agree on an initial UX vision, one that will probably change before the end of the effort and the end of the project.
As a designer living on an agile team, it is my responsibility to strike a balance between usability and design within every sprint. I have yet to work on a team whereby the Definition of Done includes any mention of UI or UX. Instead, the team collaborates on when to introduce a design element or micro-interaction to achieve the appropriate user experience to meet our user’s goals. With a well-functioning team, I have found it incredibly easy to concoct great UIs that are well within the estimated effort for any given Backlog Item. If the design wanders into something grander than the team expected, we have a conversation about the differences and make appropriate choices to increase the effort or trim the ideas down.
The theory behind agile development is to produce something that a user can use to generate feedback for the next iteration. This is not entirely limited to functionality or graphic design, rather, it should focus on how effectively the user can achieve their goals using the software solution you provided. The best user interfaces get completely out of the user’s way, but feel entirely natural to use. The only way to learn what is working for the user is to let the user interact with the software in their daily life. If the software works, the UI does, too. If the software doesn’t perform well, the whole agile team collaborates to work out kinks.