The Agile Manifesto for Designers

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.