UX Design Artifacts: Conversation Anchors not Deliverables
The focus of the user experience profession, and notably the information architecture and interaction design specialties, on deliverables is a key source of conflict with agile methodologies. The agile principle of “the last responsible moment” (more) for decisions result in one of the most common dialogues about UX in agile being agilists rejecting the “throw it over the wall” notion inherent in the word “deliverables”. Contrastingly, in waterfall development the quality and depth of the design artifacts, typically implemented in pixels, are essential to overall success.
Traditional design deliverables like wireframes, site maps, and interaction flows are highly useful in agile and a great venue for a UX professional to apply their expertise. Yet, they serve the conversation not the traditional specification role.
Design artifacts contribute early on by helping:
- Unpack user stories, revealing corner cases
- Make consistency issues with the new story and existing technology more apparent
- Communicate the story to developers and improve estimation
- Expose user experience goals (and non-goals) to both product owners and developers
Further down the process, design artifacts can serve as models for design and reference points to discuss trade-offs across alternatives. In my experience ramping up VersionOne, as often as not, my designs do not end up being the exact experience we ship due to implementation costs or other collaborative revisions.
Mike Cottmeyer
January 16th, 2009 at 1:38 pm
Great post. I get asked these questions all the time when I am introducing agile to new teams.
Here is my question… how much design is enough design to get started? None? Some? Clearly not all?
I tend to think of UX and UI design like product architecture. Build just enough early in the project to validate the critical patterns and eliminate risks.
What are your thoughts here?
andy
January 16th, 2009 at 2:50 pm
For incremental features, none may be the right answer, given a well written story and the appropriate style guide or “on the floor” UI talent to collaborate with development.
For a more complex feature or new content space, up front prototyping can facilitate dialogues with the product owner and customer.
It also depends upon the nature of the team. A user experience professional may be spread exceptionally thin if they don’t do a bit of Iteration 0 work to pave the road for development.
Focusing on risks is a good strategy for sure. In the UX field, this should be about the potential human causes of failure to achieve business goals. This might focus you on factors affecting adoption rate, retention, errors, or insuring that process optimization is effective.
Spoolcast on Beyond Deliverables / Prototyping | UX Agile
March 21st, 2009 at 6:57 am
[...] podcast with James Box and Richard Rutter visits some of the notions I expressed in the post “UX Design Artifacts: Conversation Anchors not Deliverables“. The interviewee’s do mention agile eventually and it’s a likely contributor to [...]
systemes agiles » Design with User-Stories - the curse of the technical/UI story !
April 29th, 2009 at 3:23 pm
[...] Design is finding a solution to a problem. User-stories enable us to have conversations (as in cards, conversation, confirmation by Ron Jeffries) about design : how do we solve things for users ! They are anchors for conversations [...]
Agile at UPA 2009 | UX Agile
June 4th, 2009 at 11:22 am
[...] course, I also harp on striking the word “deliverables” from the UX [...]