One challenge we are having with Agile, long term planning
Agile at my company tends to be a very heads down speedy process in which design and development are always producing customer ready work. What Agile at my company doesn’t account for yet is any kind of long term planning. We desperately need a “planning” sprint where-in the design, dev and business teams purposefully spend time on foundational and long-term needs.
In UX long-term needs are things like a sitemap, ux bugs, personas, a style guide and our primary use cases. For the longest time I kept expecting someone from the product group to create or ask me to create any one of these items. But they never did. In our Agile process it became so easy to be focused on sprinting that no one bothered to think about or define where exactly it was we were sprinting to.
In our flavor of Agile, “documentation” tends to be a swear word not unlike the bad blood Agile has towards the word “waterfall.” But the sad truth is good planning requires good documentation. This is the fatal flaw of our Agile, in our effort to eliminate time-wasting documentation we also threw out the time-saving documentation.
How I’m doing my part
I known I’ll never be given a formal opportunity to stop what I’m doing and create a foundational element like a persona or a sitemap. Instead I have to slowly build them and grow them over time, a little here and a little there.
I’ve forced my schedule to include what I call the 5 UX buckets. I make what time I can along the way to slowly build and document the following foundational UX elements. And as Dan Brown says in his book Communicating Design, these documents are meant to be living breathing documents. So I’m ok with the fact that they are never “done” but are slowing growing and evolving over time.
My five UX buckets
- Sitemap or content audit
Every time a new feature comes up no one can remember all the parts of the site that feature might impact. With a sitemap I am able to build a mental model that significantly aids in the recall of every nook and cranny of the site.
- Regular usability labs to generate what we call UX Bugs
Every other sprint we end up asking ourselves what should we do next. Without the prior groundwork of regular usability labs and a backlog generated from them, we end up guessing in the dark about what we should do.
- Personas and Customer Segments
For now this is a simple list of the types of people we encounter in our market niche. What ends up happening is we talk about them off and on here and there. And as we do I keep a master list of these features that slowly evolves as our understanding of our customers grows.
- A style guide
When we are designing in some isolated piece of the site it’s easy to get caught up in a design that is unique to that problem but that ignores the consistency of the site as a whole. Until now we’ve been rushing so fast to get something done that we haven’t had the time to create a proper style guide. It’s easy to turn a style guide into a massive time-consuming inventory project that no one will end up using. Instead, as I come across a reoccurring UI or graphics pattern that I know will be too hard to remember later, I write it down in a master list.
- Primary use cases
What are the critical paths that have to work, and work well, for our customers to get what they came for? The Primary use cases provide us with a way to prioritize the growing list of UX bugs we are generating from the usability labs. I can quickly rank a given list of UX bugs when I know which interactions of the site are more important than the others.
