Nailing it down: Specifying experience design so it can be built
by Regular Joe Consulting on Aug 29, 2010
- 1,952 views
...
So you’ve done ethnographic user research. You’ve also analyzed log files. You’ve interviewed help desk and customer service folks, You’ve had heaps of meetings with stakeholders. And you’ve nailed a sense of the user, so you’ve got some great personas. You even held some design sketching sessions.
NOW what? While Dan Brown, Ginny Redish, and others have codified the early phases of experience documentation, there’s a disjunction that often happens when business analysts write requirements documents or developers and product managers write user stories. Despite the best personas and user/task grids and wireframes, other documents override the best UX intentions. We need to get back in the game and stay there in some role as products are developed. Design doesn’t end with design; development is the fruition of design.
Let’s discuss moving from design to development, with a concentration on specifying experience design artifacts for those who have to glean meaning from our work: developers, business stakeholders, and other teams. How does experience design specify its output in a way that developers can code and business can understand how the UX relates to business requirements? And are specifications the definition of design?
After quickly reviewing typical deliverables such as use cases, annotated wireframes, requirements specifications, and user stories, we’ll discuss where we should create, where we should influence, and where we should keep the hell away.
Accessibility
Categories
Tags
More...Upload Details
Uploaded via SlideShare as Adobe PDF
Usage Rights
© All Rights Reserved
Statistics
- Favorites
- 8
- Downloads
- 77
- Comments
- 0
- Embed Views
- Views on SlideShare
- 1,798
- Total Views
- 1,952
Rachel M. Murray