The first UX Cambridge event was run by Software Acumen and took place on the 10th and 11th November at Clare College’s new Gillespie Conference Centre. The event was primarily aimed at the East of England User Experience and Design community although it ended up attracting UX and Design professionals from as far afield as Bristol, Dublin and Nîmes.
The event was a huge success and as almost our whole UX team was present at the event, many of the sessions that took place will hopefully be discussed on our blog over the next few weeks. To start off I have written a summary of the discussion that took place at the Agile/UX Panel, the final item on the 2-day programme.
Our very own Richard Muscat (RM) ran the session, whilst the Agile/UX Panel consisted of (from left to right):
Darci Dutcher (DD) – IG Group
Eewei Chan (EC) – BSkyB
Darius Kumana (DK) – ThoughtWorks
Jeremy Sutherland (JS) – ThoughtWorks
The Agile/UX Panel [Image courtesy of Richard Morris]
The interactive session was aimed at Agile advocates and critics alike, with the main aim of discussing the issues that surround Agile UX, as well as people’s views and experiences.
Questions were crowd-sourced from Twitter (#uxcampanel and #uxcam) as well as from the event itself.
Question 1: Why Agile UX? F*** Agile. I’m a designer!
DK: Agile UX is important if delivering a good user experience is important to you.
JS: I agree. Agile UX is not important if you only care about design. If UX matters to you then you’re missing out. Agile allows you to do it faster and better.
EC: It is important to have empathy to work well together.
JS: Agile is a way of delivering stuff. There are other ways and methods and Agile is not right for everyone. Agile allows a Minimum Viable Product, it allows user feedback to be fed into future releases and it enables you to deliver value to your customer more quickly.
DK: The transparency of Agile also allows you to collaborate more successfully. Also, good design is designing within constraints, even if you consider Agile to be one of the constraints in your team.
Question 2: What is it we’re upset about re: Agile? Are we worried someone is stealing our thunder?
DD: The transparency of Agile means we have to show all the work we might otherwise just throw away when using other processes.
JS: UX traditionally doesn’t always have the time to do everything that needs to be done in Agile. This means we need to find the time in the development process, which isn’t always easy. It is important to take the time to do the things you need to do.
Question 3. How can I come up with a tactical solution when I’m busy helping my team deliver the goods?
DK: You need to be able to relate your day-to-day pieces of work to the big picture.
DD: Find the time upfront to do enough of the big picture to be able to communicate it with your team and get them involved. Agile doesn’t stop you from doing this.
EC: Get people together, show what you’re working on, develop a set vision.
DK: And it is important to remember that a shared vision also includes the users when creating software.
Question 4. How do you fit UX testing and research into tight sprint deadlines?
DK: Research should always run on a separate track to maintain an understanding of your users. User testing should run alongside your project in order to test your designs.
JS: Plan for it! It may change your overall delivery plan but you should still incorporate it. If you’re really working Agile then put the changes from your UX testing on a backlog and wait for business approval. If you’re less Agile, improve your project right away based on the feedback. If neither of these then it’s a bucket of spare resources you can save for later.
EC: If you don’t have it planned in, you can’t justify it needs to be there.
RM: How do you plan it in? In an extra sprint?
EC: Not necessarily. Just make sure it’s been allocated time and resource.
DD: I have found that it works to explicitly set in story point cards to cater for UX testing and then play them when necessary.
DK: What tends to happen is that there’s a UX test and then the two days after that are spent fixing the problems that arise. We need to accept that everything we do might need to be done again!
JS: Two weeks spent doing things upfront is perfectly acceptable. If you don’t incorporate this at the cheap, paper stage then you will cost yourself a lot more later on during the development stage. It’s not necessary to do everything, just enough to take the big risk away. Nowhere in Agile does it say ‘don’t do X’, just don’t do more than you need to do.
Question 5. UX and Agile are both evolving and I think we can safely say they’re not going away. What do you predict will be happening in 2 years’ time?
DK: There have been real convergences in disciplines lately. I think it will become more and more about cross-over and collaboration between disciplines.
EC: There are loads of advocates doing the work for us. We can see the resurgence of the power of design at a higher level. I mean, look at Apple’s Jonathan Ives- he’s a God! It’s about being strong and passionate, otherwise what’s the point?
DD: Other disciplines such as marketing are adopting Agile, not because it is Agile but because it is a good set of principles to work from. Talk to others, change when the world changes, let your stakeholders know what’s going on; these are all good principles to work from.
Question 6. What does the UX look like on a Minimum Viable Product?
JS: A Minimum Viable Product is the minimum feature set to go live; the thing you would be happy to put live to get investment and feedback to enhance the product. It also depends on your competition, your environment and your customers’ level of choice. It is best to say upfront what it’s going to do, schedule this into release and decide what the first of these will look like (the MVP). Know the overall vision from the start, what the UX is within this and how it will evolve over time. This vision will be delivered in chunks along a roadmap. Work out enough upfront to know what will have to evolve as things change. Your job is to determine how much they can change without affecting your customer base.
EC: There is potential to launch with a crap MVP. Make sure it’s an experience and not just a car crash.
DK: I agree. We need to know minimum features that are of value to our customers.
JS: Release a feature to delight. There will be pain in the short term in that the user may take longer and be less happy in their work. However, the aim is to make it easier and more simple to use after that.
What do you think of Agile UX? What works? What doesn’t? Is Agile just another buzzword or a fundamental shift in the way UX professionals will be expected to work?