I spent a couple of days with the web crowd last week at Web Directions in Atlanta. Design matters on a website, where attention to user engagement can mean the difference between a flop and a million dollars.
I live in the software world, mostly around agile software development. When I talk about agile (and I think this is generally the case), I talk about benefits to the business and benefits to the team (though creating great teams has a business payoff as well).
Why Agile? Heart Reasons and Head Reasons
We talk about a close relationship with the customer or product owner. I don’t know about you, but I’ve met lots of customers who know what they want, but not what they need. And I’ve met product owners who don’t know much about interface and interaction design. I don’t say that to blame them.
Hierarchy of User Interaction (Aarron Walter)
Aarron Walter (@aarron) had a little graphic that crystalized what I’d been thinking.
Agile methods manage business risk. They can bring back enjoyment and pride in work for development teams. For the people who use our software, they make work life maybe less frustrating, because the software isn’t buggy, and maybe a little easier because the software does what it’s supposed to do. But I think we are aiming too low. Can we also make software a pleasure to use?
I’d like to collect some more information. How has your team incorporated UX/ID into short iterations?
Aiming too low. Deffo.
Few folks seem interested in the “making pleasurable” (and related aspects) – to which I assign the term “emotioneering”. Perhaps there will come a day when these aspects of product development are as embedded in the development process as coding is today. But, given the decades that it has taken for e.g. quantification of qualitative requirements, a la Gilb, to gain even a toehold, I’ll not be holding my breath for emotioneering :{
– Bob
Great post. Always looking to figure out best ways to add design into sprints. I blogged about this a while ago:
http://bit.ly/aDkOP4
We like to have iteration 0’s in that we have a design iteration up front!
The team I’m working with now has started using Balsamiq to create low-fi prototypes that they get direct customer feedback on.
Given the current state of the organization, the best we can support now is a sprint of analysis and mockups followed by implementing the scenarios.
Over the last month or so we’ve been focusing much more on thinking about how the user is using the software and getting rapid feedback before releasing but it’s taken a looooong time to get to that point.
The “business” and customers are finding this change in behaviour valuable so far.
We had a pretty good agile UX process at my last project. I wrote it up in a blog post at http://canoo.com/blog/2010/03/19/10-lessons-learned-from-usability-testing/
Here is the relevant part:
“Here’s a process that has worked great for me in the past: with 2 week iterations the designer worked ahead one iteration, working with the users and testing his mockups. At the end of the iteration, we developers presented our working and finished software to the users, and the designer presented the system that was going to be produced in the next iteration. A dude writing some stuff on THE LENS! Whoa.Then development took the mockups into iteration planning where we used the artifacts as a key guide to producing estimates and work breakdowns, while QA used the mockups as input and guidance for test creation. We didn’t start with this process, but after a few iterations of tweaking we were all quite happy with what we ended up with. If you’re new to usability then use the by-the-book approach at first, but revise the process to fit your team and your company.”
Personally, I like to extend the idea of pair programming to design and code. For me, it’s all about the collaboration. I take JIT design literally, and prefer to spend half my time during the sprint, working directly with developers side-by-side or interacting over a whiteboard.
Using a Scrum example, it works like this:
10% up front design, big picture framework, personas & scenarios, at the release level. Includes research & analysis, understand the customer, what’s the target.
25% before sprint, work out user flows, business logic. Documentation is whiteboard pics.
50% during the sprint, make detailed design decisions immediate and in context. Lots of guerilla usability testing.
15% post sprint, light weight usability testing (think Steve Krug). Insights feed back into the process.
Now, to digress. Sorry for the length, I didn’t have time to make it shorter 🙂
This last part, post-sprint feedback, is what I find most lacking in agile implementations. Agile is supposed to be incremental and iterative. We’ve done really well on incremental, not so good on iterative.
One root cause is that done done is meaningful in development. Code can be tested, you pass or fail. Not so with design. Done is just another step in the design discovery process. You finish it, put it in front of users, learn a bit more, and refine the design. But how does that feed back find its way back into the sprint?
Technically, it just goes on the backlog and gets prioritized. But there are two problems with this theory: focus and tools.
Practically, the focus in agile is on new features and functions. Feature bloat is all too common. Spending time and effort to go from functional to usable is typically hard to sell, especially when the code is done, tested, shippable, and you are faced with a well-prioritized backlog of MMRs.
Hence, my preference for lightweight and continuous design feedback during development.
As for tools, agile gives us great methods for managing development work during a sprint. But for the most part, it pre-supposes a well-groomed backlog where stories magically come into the sprint well-defined. The whole process of going from concept to well-defined is severely lacking, especially when compared to the great tools and support agile provides developers.
Expanding the scope beyond backlog management, there’s even less agile tools and support for the creative process or managing design decisions.
That said, there’s been a tremendous influx of interest and progress in agile UX just in the last few years. I really think it’s “the next great frontier.”