Agile + UX = Agile UX

Traditional Cascade Design Pattern

We know that agile is about changing the development cycle to adapt to changing market needs, avoiding the low-quality products and long development cycles that result from waterfall development.

This requires breaking the traditional "silo culture" among our departments and more involvement of developers in building the product vision and user stories. However, the UX team is not more involved in the agile development process than the central idea that "we should put user needs at the centre of the design process".

I have seen many teams in agile practice where development can quickly build an agile team with the product. Still, due to staffing issues, the design team often needs to support multiple agile teams simultaneously. It works internally as a separate department in a small waterfall model.

Even agile practices are a bigger disaster for many design teams, who need more time to output more rule description documents or do detailed user research work.

The most familiar traditional waterfall design is the Double Diamond model, which divides the design process into four phases: Discover, Define, Develop, and Deliver, a design approach known as the Cascade Model, where Cascade means Waterfall. This method is also called Cascade Model, and Cascade means Waterfall.

Agile UX Mode

In response to the above problems, there has been the rise of the concept of Lean UX. Although it is still in its infancy, it's core " test what you have" is still worth learning from. Today I want to take the UX team through the Agile Manifesto to understand the first steps of Agile from the perspective of the Agile UX model and briefly describe several aspects of UX Agile change.

People and interactions, more important than processes and tools

UX people are often distant from the rest of the team because of their expertise; they are more concerned with their work, and design work is a black box for the rest of the team.

Agile UX requires that the first step for designers is to keep an open mind, allowing other team members to contribute to the UX effort and be able to improve the overall design and make more products. It also greatly enhances the team's ownership of the design and acknowledges their contribution to the UX.

Developers also take specific time to work with design to solve problems and can also use pair programming as developed in agile methods. Pair a designer with a developer to work. This real-time collaboration can significantly accelerate the design and implementation process, just as pairing two coders can increase the quality of generated code and reduce coding time.

And by adding one or two design reviews per iteration to get constant feedback and adjustments and by only sketching in parallel with development, the UX staff can work with the development team to solve design problems in real time. At the same time, the code is being developed, which also reduces the burden on the UX team.

One thing to note here is that in the same job, UX people do not mean that they have to devote one or several full sprint cycles to planning, outlining or design ideation or user surveys, nor does it mean that they cannot take time for other work in the iteration cycle, but rather that each UX person must estimate their workload and track the speed of existing development, which can be combined to balance the two methods.

Software that can work

Traditional UX teams require large designs to be completed in advance. A specification is often considered a deliverable created by the design team. It ranges from a short description of a feature to a novel-like specification describing the details of interactions in the product.

But in an agile environment, this unwieldy documentation needs to be discarded. Still, unlike discarding product requirements documents, the design's specification has always been the most direct and concrete output of the designer's contribution and discarding it can lead to a perceived failure of skills by UX people.

This requires a shift in thinking among UX people. Replacing paperwork with real communication takes getting used to, and one can start trying to replace it with lightweight specs. Or replace functional specs with story cards and wireframes before the team develops them, no more drawing weighty documents to communicate design intent, and spend less effort to get a complete handle on the ability to pace agile methods. Remember that no matter what form your spec document takes, it only represents part of the story. It's a collaborative process.

Lightweight specs can also be simple prototypes that illustrate screen interactions, which eliminates the interpretation of static images and can be used for usability testing simultaneously.

Customer collaboration is more important than contract negotiation

Agile UX requires designers to change the relationship between themselves and their clients by integrating clients into the design team and using a flexible approach to incorporate client ideas and feedback into every stage of the design process, allowing the design team to make changes on the fly.

Compared to traditional design models, Agile UX identifies real pain points, gets customer feedback faster, and helps UX staff and customers establish better communication.

Data shows that projects using the Agile UX model have a much higher success rate than traditional design models when they are brought to market. For example, Google's design projects follow the agile UX approach. In the foreign design world, especially in startups, the ability to use Agile UX is a basic requirement for designers.

Survey activities, proactive use of RITE, card sorting, brainstorming, and cognitive walks to solve design problems with clients, along with usability testing, can allow users to influence the design process and express their needs directly. The participatory design encourages users to engage with their current environment fully, imagine the ideal future, and create the ideal expression.

Such interesting practices allow customers to focus more on their own experiences and needs and are open to their knowledge and expectations of the software.

Be ready for change than to follow a plan

As you can see, the Agile Manifesto calls for Agile UX to emphasize efficient and continuous design to meet customer satisfaction standards. This value requires an individual passion for design and the collaboration and interaction of each team member to achieve the goal.

In the traditional design model, everyone in the team has a different division of labor. After conducting user and market research, the initial team analyzes the research results and summarizes them, then designs, makes models, tests the models, analyzes the problems in the tests and then improves them, and finally creates the final product. The design team first needs to understand the customer's needs to complete a work that the designer thinks is perfect. This design process often takes months, and the result may differ from what the client wants.

While the traditional design process is a one-time activity, the Agile UX model is a sustainable design process. Testing is another beginning of UX design. Only by breaking through, testing, and refining, can agile UX design play a bigger role and provide more support for later design and development. The agile design emphasizes "make a real change" instead of "make a report", and frequent testing and modification is the primary principle of the agile UX model.

Conclusion

Designers need to rethink their skills and focus in an agile environment. Moreover, if you are looking for a remote job as a UX designer, please visit the Jooble. 

Agile UX describes the contextual scenario of agile development methodology in UX design, unifying the agile process of development and designers in product development. It is a collaborative, cross-functional approach that places less emphasis on complete documentation and more focus on a shared understanding of the true experience of the product being designed.

---

Need more help? Check out the Zentao blog. They have more articles on project management tools, software management, building cross-functional teams, and so much more.