Fortunately, for all participants in an Agile project, UX designers have a tendency to be user or customer-centric, whether we realize it or not. One of Agile’s core principles is about stepping out of the office and presenting work in front of a customer for validation. It’s not hard for UX-ers to feel at home gaining that validation and interaction with users. Most designers crave the research and change resulting from a sit down with users in order to understand their pain points, behaviors, desires and gaps where they’d like a product or service to improve. Developers and core team members are beginning to understand how invaluable this direct contact truly is. Perhaps the correct comparison here would be inviting guests to enjoy our lasagna with us through every step, from preheating to plating.
The Agile Process arose due to problems in the Waterfall system of developing large scale documentation, like functional requirements bibles. These documents – tomes, really – would be incredibly detailed and great for building a system – but were often obsolete. The issue here was that the actual project and requirements for a system would change right from the beginning, when the functional requirements were being built. Additionally, the technical team – devs, QA and folks set to make it all work – may not have been involved in creating those documents and by the time they’d receive it, little of the functional req’s would assist them. At its core, building products is about the transition from theory and text into practical, visual solutions – and that means creating more visual forms of documentation, such as Agile’s emphasis on prototyping. That’s where UX has excelled, and always will – we bring the theory into practical via the visual. We turn the pages of a recipe book to the right page, and bring it to life.
The era of Agile as an established, mature methodology is here, along with some concern and push back. Ironically, much of these negative views resulted from the rush to build before having a proper plan in place. An idea that Agile strongly advocates for, while many other methodologies focus elsewhere. There is some misinterpretation that Agile means “no documentation”. Here, we need to be careful that the pendulum hasn’t swung the other way – from far too much initial documentation and design, to not enough of either, which would create a rush to code. There is a concept for developers known as “code as documentation” which is nice in theory but Agile pushes for a layer on the bottom of our lasagna, the foundation, to be explored first. Better to look into the right path, confirm content, and design approaches before any level of build occurs. This is a layer where UX adds value by sorting through the various paths available and presenting them.
What can documentation outside of code look like? Agile promotes the use of tools such as wireframes and prototypes to ensure that we are moving in the right direction before committing to code, which could require later rework. This added layer, documentation, ensures that all of our cooks know the layout of the kitchen and what is being cooked before a single ingredient is cut. Tools, like prototyping, simulate enough of the experience for users that we can begin product testing – and validation. Even if this occurs in a rougher fidelity, the results allow us to confirm our path – a task harder to complete with more transactional Web applications where data visualization are part of the project. Thanks to integrated tools, such as Sketch and Invision, we now have ways for UX designers to quickly create pseudo-products which can be tested right in front of users. This process allows us to gain valuable suggestions and insight from real customers before any piece of code is written. Much like a chef will taste a spoonful of his pasta sauce as he cooks to ensure the right mix, having these prototypes can ensure the right balance of ingredients.
There are issues around how to best integrate UX and Agile – on a day to day level, it can be tricky to rapidly iterate and integrate both within the same project, as well as the other disciplines of product marketing, stakeholders and team members. Smart teams sit down together to identify the who, what, why, how and when of every project. An agreement must be achieved beforehand on the standards and fidelity needed in UX deliverables and where it fits into the development sprint. The goal here is to ensure that everyone receives what they need before the process begins thus preventing the need to run back to the store for additional ingredients once the kitchen has been opened. Like any methodology, tool or recipe, integrating UX into Agile takes practice, commitment, infrastructure and shared understanding to make it all work. Like every great meal, it requires planning and a vision of what we want to create for our customers before they even set foot inside the restaurant. The products and services we create may not always be as memorable and emotionally satisfying as our favorite lasagna, latte, creme brulee or other tasty treat, but with the right planning – great products and services can happen – thanks to the tasty mix of Agile and UX. Bon Appétit!
Written by Rachel Murray