Constantine on combining Agile and User Experience

Usability and Teamwork author and consultant Larry Constantinerecently wrote two articles about the “Interfaith Marriage” between experience design and agile development. The first article can be found here, and the second one here.

He discusses the fervent adherence to practices by both the UX and the agile communities and how that marriage can be fraught with difficulty and tension.As he says:

When these two meet, when experience design is married with agile development, the results can be a crisis of faith on either or both sides.

He examines the history of both agile methods - the XP focus on the “onsite customer” who might not be a real user where “customers are not, in most cases, the same as users, and the customer role is more focused on functionality than on usability.” He continues to say:

In their slight of users, the agile methods resemble most other software development methods, which have a long history of treating users, user interfaces, and usability as afterthoughts at best or at worst as irrelevant. I myself am guilty in this regard, having pretty much left users out of the equation in the now ancient techniques of structured design, a sin that I repented and for which I did penance by developing, with Lucy Lockwood, the body of techniques that came to be known as usage-centered design.

He talks about the work of professionals from both the agile and the UX community working to bring the two perspectives together:

Many professionals on both sides of the aisle—Jeff Patton, Scott Ambler, Ron Jeffries, Thomas Memmel, Don Norman, and Jakob Nielsen, among others—jumped into the role of matchmakers, promoting a relationship or rapprochement between experience design and agile development. This has been a long engagement. I’ve been writing about user interaction design and agile methods since the turn of the century (are we allowed to say that now that we are in the second decade of the millennium?), and Jeff Patton’s agile-usability forum (agile-usability at Yahoo Groups) dates from 2004

He goes on to discuss the public debates and disputes between UX and agile adherents, and how the debate has been largely one-sided:

An interesting aspect of this speed-dating dialogue has been that, for the most part, nearly all of the narrative so far has been about experience designers accommodating to the dictates of agile methods and schedules. Hardly a word is printed or spoken about what developers might do to accommodate the agenda and practices of designers. Short stand-up meetings, test-first development, 2-3 week sprints, emergent requirements, avoidance of upfront analysis or design, pair-programming, rapid incremental development with re-architecting, the customer role with user stories—all the practices and paraphernalia of agile development tend to be assumed as fixed and given, while the practices and processes of experience design are modified or mangled to fit into the particular agile method being performed.

He then examines where the incompatibilities lie between agile methods and UX:

There are many core incompatibilities in this couple. Agile methods employ rapid, iterative refinement, with short, incremental development cycles. The imperative is to produce executable code and deliver added functionality at each iteration right from the get-go. BDUF, for Big Design Up-Front, is a curse to be avoided at all cost. The single most important criteria, embodied in the test-first development approach, is that each increment of expanded code run to completion, executing correctly to produce the right output. Little or nothing is said about the usability of the results or of the means for the end-user to reach them. Test-first development does not include or address user testing, and it is arguable whether it should or even could.

User experience design, on the other hand, tends to front-load activities, often beginning with a fairly long lead-up devoted to field study and observation of users, analysis of user requirements, user modeling, prototyping, and visual and interaction design. User testing is often a fairly time- and labor-intensive activity that may sometimes be integrated with prototyping but is almost always heaviest late in a project when a beta or later version becomes available. In general, experience design assumes that a design will be completed in substantial detail before anything beyond a prototype is built, because user experience is usually shaped as much by subtle details and their precise interconnection as by overall structure and organization.

In Part 2 of the article he goes on to provide guidelines for four elements that need to be brought into the Agile-UX relationship to make them work well together:

Respect

Equality

Knowledge

Independence

Respect:

We are all professionals, yet developers too often look down on experience designers as muddle-headed, touchy-feely types drawing on soft-science impressions and unsupported opinion. To be honest, I have also known some designers who see developers as narrowly focused, socially inept techno-nerds stuck inside their code. In truth, programmers and designers alike need to learn to be better at acknowledging and deferring to each other’s expertise.

Members of both communities need to adopt a one-team attitude and respect each others’ professional credentials and knowledge. The developers understand how best to build a software product, and the UX professionals understand how people interact with systems and software – acknowledging and respecting the skills that each bring to the table will result in products that creat customer delight.

Equality:

Designers and developers need to be co-equals in the development process. I confess that I have personally come to believe that, for greatest success in most instances, experience design should drive the process and that, for the most part, user experience issues should trump implementation issues. If it comes down to the position and opinion of the developers on the one side and the designers on the other, most of the time, the outcome is better if the nod goes to the best design. However, in practice, a more workable compromise is to consider developers and their concerns and designers and theirs as equally important.

Where differences of opinion and perspective cannot be resolved between the team members there needs to be an arbiter – a role who has the responsibility of talking for the customer and making the final decision about aspects of the product under development. This role is known in Scrum as the Product Owner and is well defined, someone who has the long-term interests of the product at heart and provides strategic and technical direction for the product in the organisational context.

Knowledge:

One of the most effective ways to build mutual respect and equality is through knowledge.

He talks about the need for UX designers to understand the principles and approaches of software engineering and for software developers to gain knowledge of the principles and key aspects of usability design. Remembering that “we are not our users” and that gaining an understanding of real customer interactions will result in a vastly improved product.

Another argument for spreading the skills is that even the most thorough presentation and interaction design will not and cannot cover everything down to the lowest detail, and will always fail to anticipate some interaction or presentation issues. In practice, programmers inevitably end up making many user interface design decisions on the fly—everything from whether or not to align certain visual components to creating unanticipated error messages to deciding whether column headers on a grid display should be active to sort on that column. Not only does knowing the fundamentals of interaction design contribute to better teamwork and more successful collaboration with designers, but it is also in keeping with the ethic of cross-training and fungible skills that permeates agile methods.

Independence:

Any good marriage allows for independent thought and activity, which can be a problem for meshing the work of user experience designers and software developers. The impulse to launch immediately into productive work on day one is understandable and all but universal for both designers and developers. Designers start sketching screen layouts or product designs in first meetings, and programmers start writing little bits of code as soon as they can get their hands to the keyboard. And management makes the matter worse by pushing for visible deliverables from day one.

He discusses decoupling UX design and development – use a “one sprint ahead” mode of working where the UX design is undertaken in small slices, just ahead of the development and delivering just-in-time input to development stories.

He talks about the need to undertake SOME up-front design by separating the features, functions and content of the system into three groupings:

Interface: those areas that have a direct and substantial impact on the user experience. Interface components need to be designed up front and include the presentation layer components – screen layout, information display, menu structure, navigation architecture and so on.

Internal: those aspects of the system which are independent of interaction design or have very little user experience impact. These components can be worked on largely without input from the UX designers such as database organisation and implementation, computational elements and communication protocols.

Interdependent: anything that requires a mix of interface and internal design, or where there is currently insufficient knowledge to understand where the overlap currently belongs.

He states:

Of course, it is rarely possible to make a truly clean separation of interface, internal, and interdependent issues, but in my experience performing this triage allows a considerable amount of concurrent engineering of software along with design of user interaction while reducing risk and restricting later changes to a manageable minimum, even with an imperfect partitioning.

Constantine ends with a call for developers and UX designers to work closely together in a happy ans prosperous union.

Synchronize UX with development – run UX one sprint ahead of development

Separate modelling from design – the abstract thinking that is needed to understand the perspectives and points of view that the design must support. Design can be fast if the abstract modelling has been done in advance and the whole team has a consistent understanding of the model

Design literacy – everyone on the team needs to understand the fundamentals and basics of UX design

Collaborative design – the whole team should be able to work together on all aspects of the UX design

Lower fidelity – use wireframes and simple tools rather than spending lots of time producing elaborate detailed design documents

Book your time - be clear with the rest of the team about how much time you need for UX activities in the iterations and communicate about activities as they are undertaken

What advice can you provide for effective and productive collaboration between user experience and agile development?

More InfoQ articles on Agile and Usability can be found here and here.

If you use the XP approach of simple design and refactoring, this will not be an issue. Developer will build very simple UI to implement the most critical functionality. Then when UX designers have a better interface, the developer will simply enhance and/or refactor to implement the new UI.

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.