UX at stuff.co.nz: We don’t always work ahead, but when we do...
I’m a UX’er at stuff.co.nz, but you can’t quite see what I’ve been doing yet.
I started at stuff.co.nz towards the end of a huge, 2 year migration project where most of the site was transferred like for like into a new content management system. The migration project effectively placed design and UI development on hold, and there was no UX. Around 3 months before the migration project finished we formed the Stuff Exploratory team, combining the skills of UX’ers, designers, developers and testers from across Product Technology.
Because of the migration project, we had no access to the platform we were redeveloping and designing for. We had to work ahead of development.
NB: I need to stress, this article doesn’t advocate one means of integrating UX & design into Agile over any others. We employ many different approaches and tools depending on what we’re working on - I’ll write about that another day...
So, we were working ahead of development. We had a bunch of big ideas to explore, validate and design solutions for, heaps of enthusiasm, and a fear that we wouldn’t find out all the answers before the migration development work was complete.
Underlying panic: “what if we start working on redevelopment and we don’t have enough to build!?”
This fear felt very real at the time, in hindsight, it was completely unfounded.
So how far ahead is too far ahead?
...well, it depends.
Some of the work the exploratory team undertook whilst waiting for the migration project to end absolutely needed this extra time. It enabled us to introduce our key stakeholders to the idea of working in Agile and allowed us to gain their trust and allay their fears of a “phase never”. It afforded us time to found user testing panels and work with and learn from our research team and Product owners.
But when it came to designing, prototyping and developing actual features we found that working ahead of the delivery team was sometimes like driving to a destination and getting a friend who’s never been there before to follow you.
Sometimes, the road was clear, they followed directly behind us and we all got to our destination together. Sometimes, we’d arrange to stop at service stations to get an ice cream, the sun was shining and it was lovely to hang out on our road trip. Sometimes we’d encounter traffic in busy city centres, with horrendous one way systems, floor it through an orange light and totally lose each other.
Judging how far ahead and at what speed to drive is key to arriving safely at your destination without getting lost along the way.
Some exploratory work needs upfront research, user testing for validation, more design thinking than other work. It’s totally appropriate to do this work ahead of, but not in isolation from development. And this really doesn’t mean that you can’t user test or adapt a design when working with developers - but again, that’s another blog post.
Ask yourself if the answers you’re getting to the questions you’re asking now are likely to change in the future - or will the questions themselves change? As time moves on user and stakeholder needs change. Is the thing you designed 3 months ago still what your users need or have your stakeholders decided they want [insert successful tech start up] instead?
Some exploratory work needs to be documented so that everyone remembers why certain decisions were made. Remember to check that the decisions made back then, meet our business objectives and user needs now. With the exploratory work completed more than 4 weeks out from working with the dev team, we found we often revisited decisions and that - even with the most glorious of Jira comments - we couldn’t figure out why they were still important.
Generally, our big decisions have been on track, they haven’t changed and still meet our business objectives and user needs. But the smaller decisions made early on, often make no sense now and it would have been better to leave these decisions until later and work on them with the full team to find a solution.
We’re now in the position where we have a reasonable view of our delivery horizon and we have the luxury of being able to work directly with developers or ahead of development sprints. We don’t have the all of the answers and we haven’t achieved continuous delivery, but we are continually learning from and evolving the ways we work.
Regardless of if you’re working 3 sprints or 1 sprint ahead, or if you’ve reached cross-functional-lean-continuous-delivery-squad-nirvana, the most important thing is to continually check in with your business objectives and user needs to make sure that the decisions you’re making directly relate to your goals.
Slow down for roundabouts and don’t jump the lights.