Many say that UX design processes do not fit well into the agile methodology. As a UX designer who has experience working on both waterfall and agile projects—and many variants in between—I object to this assertion.
The Agile Manifesto outlines twelve principles that guide the agile methodology. One by one, I’ll explain how each of these principles not only fails to conflict with good UX design practice, but can even improve it.
Champion Advertisement
Continue Reading…
Principle 1: Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Perhaps it is the “early and continuous” part of this statement that ruffles the feathers of many UX designers. While some might endlessly brood in isolation over a particular design issue, this is a way to lose all perspective.
The continuous delivery of valuable design solutions enables us to maintain a tight loop with real user feedback. The sooner people can interact with a design, the sooner our false assumptions meet the light of day. We can generate real value instead of perceived value, with confidence rather than guesswork.
Principle 2: Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.
Change is inevitable, so you had better get used to it. If the world has taught us anything, it is that environments change—and sometimes very quickly. Any design solution we create should take into account the possibility that the user’s needs and goals might change. A design solution that is too rigid to adapt is also brittle, so its utility could break under the pressure of a changing environment.
Looking at this from another angle, the objection to changing requirements may just be an unwillingness to revisit past design decisions—a fear of exposing one’s own mistakes. A system of design that embraces change does not mind owning a few mistakes now and again.
Principle 3: Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
This principle is very much related to the first one. What it adds is an emphasis on working software and short time scales. We can apply these ideas to design by ensuring that our deliverables focus on utility over style. Form follows function, after all. While aesthetics are certainly important, they’re perhaps not as important as designers tend to think.
Don’t expend more effort on purely stylistic concerns than is proportional to their relevance to functional concerns. Avoiding this will help shorten time scales because you’ll be spending your design capital on solving the most important issue, and you can deliver a product sooner.
Principle 4: Business people and developers must work together daily throughout the project.
Change this to: business people, developers, and designers must work together daily throughout the project. For everyone to feel a sense of ownership, understanding, and dedication, team members from all disciplines should be involved at every step.
It’s also extremely important to recognize that no designer has all the answers. Nor should anyone in that role ever claim that he does. It’s one of a designer’s primary jobs to seek out and distill good ideas from everyone and everywhere. Engineers and product owners have unique perspectives and experiences and often contribute good ideas.
Principle 5: Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
This principle applies to designers as well as engineers—or really any team member—so it should not be controversial. Every member of a team has a unique set of skills that he or she brings to the table. Trusting people to harness those skills is the best way to motivate a project team. A working environment in which mistrust reigns is a toxic one that will kill any incentive to do good work.
This is certainly not to say that a UX designer—or any other team member—can do no wrong. A UX designer should actively solicit critical feedback from every contributing team member. This prevents anyone from feeling the need to shove feedback down their throat. A UX designer who does not ask for criticism cannot possibly improve. However, criticism should always be offered in a constructive way and in a supportive environment.
Principle 6: The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
The same holds true for a design team—or for designers working on a multidisciplinary product team. As much as we might like to think that screen-based communication is sufficient for our millennial lifestyle, humans have evolved to communicate with our voices, hands, and faces.
For UX designers, this means explaining our design decisions to others with words—preferably while everyone is in the same room, so there is sufficient eye contact and the ability to gesture. By communicating in this way, you can expose details and questions that might otherwise remain hidden beneath the surface. You can settle issues and internalize solutions in minutes or hours rather than days or weeks—or never.
Principle 7: Working software is the primary measure of progress.
It’s certainly necessary for designers to spend some time creating static assets such as wireframes, workflow diagrams, or mockups. Design deliverables such as wireframes and diagrams can help stakeholders to analyze high-level concepts and see the forest above the trees. Mockups let us inspect and iterate on the details inexpensively, without undue commitment.
However, design deliverables can do only so much to communicate how a user would behave during a particular interaction. The sooner we can implement interactivity—by actually building a prototype or working solution for a problem—the sooner we can understand how far we have progressed in solving that problem.
Principle 8: Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Some designers lose interest in a project if they’re not solving a fresh, new problem that they find interesting or engaging. However, this might just be a side effect of a defective development process and the consequent buildup of UX design debt.
Each design decision that gets made without applying the proper design principles, without validating the solution, or without scrutinizing critical assumptions contributes to design debt. Making poor choices on top of other poor choices compounds issues, making each choice more painful and difficult than the last. Sustaining a design effort in this kind of context is untenable and is a sure cause of burnout.
Principle 9: Continuous attention to technical excellence and good design enhances agility.
This principle actually includes the word design, so it’s an easy one. We should emphasize the parity of quality code with quality design. A common criticism of the agile methodology is that its focus is on software and speed. People often assume that agile is detrimental to good design.
As I explained under the previous agile principle, poor design choices compound, making it increasingly difficult to adapt and pivot with each iteration. Conversely, the best design decisions often have cascading implications that positively affect an entire product. Patterns emerge that become part of a unifying, shared design vernacular, subsequently making similar design decisions increasingly effortless and efficient.
Principle 10: Simplicity—the art of maximizing the amount of work not done—is essential.
Both good design and good code require simplicity. If we adhere to the principle of “less is more,” we can focus on solving only the problems that really need solving and reduce cognitive friction.
However, this principle seems to focus on the simplicity of the work a development team performs rather than—or perhaps in addition to—the simplicity of the work a solution generates. In short, spend as little time as possible working on any given problem, but achieve this without sacrificing quality. Focusing on reusable design patterns makes your future workload lighter. Face-to-face communication and frequent delivery ensure a constant source of actionable feedback. Frequent critiques help you to avoid needlessly circular ideation, lacking perspective or guidance.
Principle 11: The best architectures, requirements, and designs emerge from self-organizing teams.
Earlier, I mentioned how important it is to engender trust among the members of a development team. Each person’s skillset and expertise are unique, and the way in which the members of a team interact dictates the group’s dynamics.
While the members of a team will certainly have some semblance of defined roles, their roles must be allowed to flex and overlap to whatever extent everyone’s skills require. A UX designer, for example, may have a particular knack for understanding architectural concepts, or a software engineer may have a particularly good eye for color. The team should be free to interact openly with one another, without putting up artificial walls around their job descriptions.
Principle 12: At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
The cornerstone of any good team is its adaptability and willingness to self-reflect and accept change. Every team and every project is unique, so no prescribed process will fit in all cases. We should remember that UX design, just like programming, is about finding solutions that fix problems—not about forcing problems to fit our solutions. No popular graphics software, trendy design style, or hot, new development methodology should determine the way we work.
If something doesn’t work, change it! Change is inevitable—changing requirements, changing user needs, changing budgets, changing deadlines, changes in the very people who make up your team. Being an agile team means being flexible and ready for these changes. It’s not about sticking to a predefined set of best practices that have been handed down from the development gods. Such lofty practices lack the vital context you need for real innovation.
While this is a pretty good take on transforming agile principles to include design, it fails to take into account design ramp up and problem setting. If Engineering starts building right away, you’re likely to get stuck into a particular viewpoint—especially as most teams don’t revisit previous decisions well and instead focus on getting all the things done faster. Giving Design a head start allows a better understanding of the problem and at least a semblance of what should be built. All designs have a point of view, and projects should give designers and teams time to understand and shape that point of view.
Well put. As a coach, I can totally relate to what you are encouraging as your thoughts have been mine—albeit not stated as eloquently. I’ll definitely be pointing people to reading this. Thanks for sharing!
I personally have found huge benefit through Principles 4-6. Having projects and teams where requirements, design, and engineering concerns were being refined together regularly was very much a boon to success. The ability of these teams to understand each others’ concerns and compromise during meetings—grooming—keeps the pace quick and, in my experience, significantly reduces the number and severity of gotchas that come up as the project gets closer to completion.
Andrew is a user experience and user interface designer, a graphic artist, and a front-end developer who has crafted mobile apps, Web applications, and Web sites of all kinds. For him, design is, first and foremost, about solving problems for people, while also satisfying practical business requirements and constraints. Read More