Maintaining UI integrity within the agile framework

Designers devote a ton of time and effort ensuring that user interface (UI) elements operate within a set of constraints. We set type, adjust alignment and spacing, and use color theory—among many other conventions.

Every designer understands that a clean UI is analogous to a compelling user experience. Yet when it comes to agile development and Scrum, there are no guidelines to support such efforts.

As a designer in the digital space, I’ve watched my pristine mockups move through a 2-week development sprint, only to find the UI compromised. With an emphasis on speedy delivery, it’d seem that Scrum does not have time for “low priority,” cosmetic UI refinements.

For fear of being labeled as an unpopular pixel-perfectionist, designers throw up their hands, mutter an expletive or 2, and resolve to upload mockups (rather than live screenshots) to Dribbble.

While Jeff Gothelf’s impactful work on lean UX has been a much needed breath of fresh air in the UX community, there’s still lots of work to do as UX gains prominence in the enterprise.

Rather than fuming in our frustration, we designers have a unique opportunity to shape UX as we know it—and to define best practices for future UXers.

From Blackberry to iOS9, from waterfall to Agile, I’ve tried anything and everything over the past several years to deliver products that embody excellence in both form and function. While many of my efforts failed, I learned invaluable lessons along the way. This can be an uphill battle for many designers, particularly in consultancies where there’s an emphasis on speed-to-market delivery and a prioritization of how well it works over how good it looks.

How can we deliver both at equal value without compromising one over the other? I’ve found that the most effective way to integrate UX and the agile framework is simply to apply UX practices throughout the Scrumban model.

Here are some practical, tried-and-true tips to achieve UI excellence within the agile framework—all while eliminating waste and creating business value.

Start with communication

As cliche as it sounds, no other efforts will work if communication doesn’t happen first (and, of course, if communication isn’t ongoing). Luckily, Scrum can help.

Scrum outlines specific guidelines for teams to conduct retrospectives at the end of each sprint. The timing of retros between sprints is significant, as trying to implement a new process mid-sprint is like asking someone to join you for a drive while they’re fishing in the ocean.

The purpose of the retro is to inspect and adapt so that teams can be ever-improving. Leverage it as a way to bring UI integrity challenges to light. Involve the entire team and agree on possible solutions to try out over the next sprint.

A core tenet of the agile manifesto: “responding to change over following a plan.” So if you tried something that didn’t work, the good news is that you can change it and try something else. Designers are trained to iterate, so why not iterate on a better process?

In his book Scrum, Jeff Sutherland emphasizes that problems are rooted in processes and not people. It’s important to value the individuals on your team and center your retro on process improvements rather than pointing fingers. Too often we waste retros by turning them into rant sessions without actionable takeaways.

Properly investing in the retrospective can produce powerful results. A game-changing moment in one of our team retros was when a developer suddenly understood that a clean UI to a designer is like clean code to a developer. If code is hacky or bug-ridden, then it’s considered broken. The same can be said for the UI. These small interactions are the beginnings of great collaboration.

Create smaller units of work

In software development, the heart of being Lean is the idea of moving small units of work across the finish line to complete a sprint with an increment of working software.

In practice, the process of grooming UI is often far from lean. A typical process might involve a designer seeking out a developer so that the 2 of them can look over a number of screens or features that were just developed. The designer reviews and presents UI revisions, and the developer proceeds to address them.

Before you know it, an hour or more has passed and the developer jots down revision notes to address at a later time. Further attempts might be made to conduct a UI review, but inevitably the sprint ends, UI revisions are forgotten, and the designer makes a mental note to save their mockups for their online portfolio.

This process fails time and time again because it attempts to accomplish a large chunk of work without any planning increment in place. In other words, it closely resembles the waterfall process.

Once again, the agile framework has a solution to leverage. If you work on an agile team, chances are that your team tasks user stories. One practical way to break down the UI review process is to create UI review tasks per user story. In the spirit of being lean, it’s important to note that the smaller the user story, the better. Adjusting the placement of one icon is a minor effort compared to adjusting every UI element on a screen. We’ve found that allotting 15-minute timeboxes works well for each UI review task. Short tasks mean incremental effort and thereby provide a definition of done. No longer will designers have to mourn over incomplete UI revisions.

Tasking also creates a shared responsibility so that the designer is no longer the sole team member accountable to quality assurance in the UI. Moreover, tasks are visible to the entire team so they cannot get lost in the sprint.

While some may be concerned that bringing in UX effort may negatively impact a sprint’s velocity, getting the UI right is a core part of the front-end development process. There’s proven value in taking time to build the UI according to the design intent, as every $1 spent on UX brings in between $2 to $100 in return.

Pair vs. meet

Pair programming is a best practice when it comes to agile software development, and you can apply the same practice when collaborating on the UI. Rather than scheduling meetings, designers and developers can sit knee-to-knee as needed to complete UI review tasks together. The daily standup is a great time to communicate when you’re ready to pair. And it’s even better if your team can sit together and constantly communicate.

Pairing has allowed my team to build a shared understanding and empathy across disciplines. I’ve gained a huge appreciation of the development process, and I can confidently say that my developers have gained a similar posture towards design.

We’ve gotten into such a rhythm that the developer can predict what UI adjustments I’ll be looking for and will preemptively make the UI adjustments himself. This kind of efficient collaboration makes both of our jobs more enjoyable, and it’s a clear picture of what it looks like to perform at an ever-increasing velocity while delivering a better quality product.

Leverage your team kanban board

It’s common for scrum teams to use kanban boards. Whether your team uses a tool like Trello, or just a whiteboard, the purpose of a kanban board is to track progress during a sprint. Your team kanban can also be used to track whether a UI review task has been completed or if it’s blocking a user story. It allows full transparency and visibility so that a team can swarm where necessary to meet a sprint goal.

Teams may choose different ways to use their kanban board and arrive at a “definition of ready” for a UI review. Some may create a column especially for UI reviews. Or some may use the testing phase as the time to review the UI.

Our developers got into the habit of seeking out a UI review before submitting a pull request, and marking a story ready for testing. We’ve found that sitting together for 15-minute chunks is enough to knock out most UI-related issues. But if more effort is needed, and the issue isn’t critical, a practical solution is to create an independent UI defect to track the issue. This allows the user story to continue moving through the kanban without any blockages. It remains visible and accountable to the team and can be addressed when there’s capacity in the sprint, or it can be deferred and re-prioritized.

Determine what workflow works best for your team, and continue to inspect and adapt as you go.

Use an inspection tool

Tell a developer to move something 2 pixels, and watch them cringe. Repeat that statement for countless UI elements, across many screens, and watch the war on pixel perfection begin.

Inspection tools save the day here—use your preferred one to take a source file and automatically specify UI dimensions, spacing, and styling.

Delivering a better, market-ready product

These tips aren’t meant to be prescriptive or bulletproof, but rather working examples to adopt and adapt.

In line with the classic agile example, Scrum teams don’t go from developing wheels, to an engine, to a car—we build working products that are viable in and of themselves at every point of delivery.

So whether you’re building a basic skateboard, a mountain bike, or a self-driving car, make sure it’s fully painted, polished, and packaged up. Because clean UI doesn’t need to be limited by speedy delivery. Instead, we can use Lean principles to celebrate both design and functionality—ultimately resulting in a higher quality product.