I recently had lunch with a senior design lead who made a comment that, “Design doesn’t work in an Agile world”.
Agile development is an alternative to traditional project management where emphasis is placed on empowering people to collaborate and make team decisions in addition to continuous planning, continuous testing and continuous integration.1
As digital products become more complex, fluid and ever evolving, it has become an expectation among users that they will continuously innovate and improve the experience for the end user. Products that stagnate will get left behind as technology marches forward and users find other products that more effectively and efficiently meet, (or exceed), their needs.
An agile development process works extremely well in defining the MVP, and to continually deliver feature additions and improvements and much has been discussed about “just in time design” to support an agile development process. But can design truly work “agile” and deliver an inspiring experience upon initial launch? Remember, you only get one chance to make a first impression. 25% of users will switch to another provider after just one bad experience, and 30% will share a bad experience.2 Keeping in mind that there’s been a definite upward trend in consumers reading reviews to determine a company’s quality, (over 80% make decisions based on reviews, and these reviews are as trusted as a personal recommendation3), it’s clear that the experience of a product counts the very first time a user engages with it.
Designers want to design the experience, think holistically about the journey, the micro and macro interactions. We need to do our homework ahead of simply supplying assets for building a checklist of features and functions from a product roadmap.
Time is needed to understand the users; who are they, what do they want to do, what context are they using the product in, what would delight them, what would frustrate them? We want to conduct user interviews, observe them completing tasks. Designers want research to help inform their design decisions – Are there analytics? Survey results? Should we do a heuristic analysis? Content audit? Journey Map? Can we talk to customer support? What are the current pain points? We want to know what the product landscape is like, do benchmarking and competitive reviews. We need to understand the brand’s vision, mission and values. And then, we want to sketch, explore and problem solve.
So how does this fit into an agile development process? In comes Design Sprint 0. At a somewhat high level, this is what a Design Sprint 0 looks like:
- Design starts by getting a solid understanding of the product, business goals, and users (who they are, what they want to do, what context they are in, etc).
- Then the team and stakeholders work to define the product vision, and determines what the most impactful MVP looks like. What are the key tasks that need to be completed? What features are critical? What do we need to design and build that will result in an inspiring experience that will lead users down the path of trust, loyalty and advocacy4?
- We then work on the information architecture, task flows and wireframes for the key screens and workflows.
- Eventually moving into full fidelity mockups, assets and defined elements to be used when building.
An important thing to note here is that Design Sprint 0 is not meant to be a “big reveal” at the end of X weeks. Throughout the Design Sprint, we are producing deliverables for review to both the internal team and to other stakeholders from product management, to architecture, development, marketing and any other relevant parties. Design does not work in a vacuum. The deliverables produced inform and facilitate architecture, development and product management.
It’s important to note that while Agile Development places significant value on ‘working code’ as proof of value delivered, design deliverables that drive clarity, set expectations, allow for testing before coding (talk about reducing waste!) is also of significant value and agile in nature. Design Sprint deliverables fall in line with the agile methodology as far as design, review, (test as appropriate), and iterate as well as collaboration, and communication over documentation. It is also not expected that what has been designed is 100% done and will not need to be touched once coding starts. That’s where lean UX, or just in-time design, comes in. By having a holistic view of the product and a defined experience, we find that we are able to pivot as needed during Agile development, iterate on both micro and macro interactions, as well as create new screens or interactions, as we find out what we didn’t know we didn’t know.
So, perhaps it’s not that design doesn’t work in an agile world but rather the lens through which design works and delivers needs to be adjusted to reflect the critical importance of the product experience that we are building in an agile process. And that both are on the same team working towards the same goal: using continuous innovation to create, and evolve, inspiring experiences that build brand advocacy.
1. http://www.webopedia.com/TERM/A/agile_software_development.html
2. https://www.thunderhead.com/the-cost-of-crappy-customer-experiences-infographic/
https://www.brightlocal.com/learn/local-consumer-review-survey/
3. http://searchengineland.com/88-consumers-trust-online-reviews-much-personal-recommendations-195803
4. https://itx.com/ITX-Blog/Article/377/Customer-Loyalty-is-Not-a-Transaction
