Session Title
Nailing It Down: Specifying IxD So It Can Be Built
Presenter
Joe Sokohl, Regular Joe Consulting, LLC
Session Type: Discussion
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 a honkin’ meeting 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? Let’s discuss moving from research to design, with a concentration on specifying interaction for those who have to glean meaning from our work: developers, business stakeholders, and other teams. How does interaction design specify its output in a way that developers can code and business can understand how the IxD relates to business requirements?
I’ll start with some ideas for discussion, but let’s share what works, what doesn’t, and come up with some killer ideas.
Biography
For 17 years, Joe Sokohl has concentrated on crafting excellent user experiences, using information architecture, interaction design, and user research. He leads teams in effective integration of user experience into product development. Currently the principal UX architect for Regular Joe Consulting, LLC, Mr. Sokohl has previously held UX-oriented positions based in Boston, MA; Hamburg, Germany; Richmond, VA; Chicago, IL; and Durham, NC.
His UX writings have appeared in the SIGCHI newsletter, UXMatters.com, and STC’s Intercom. He has presented at the European Information Design Conference, the Society for Technical Communication’s international conference, the Information Architecture Summit, and Agile. He is a cofounder of RUX (RichmondUX.com).
Oh, and he’s been a soldier, cook, radio DJ, blues road manager, and reporter once upon a time.
2 Comments
Dear Joe,
This is my third project in Keane where I am working with BAs. Over the time, we all (IAs and BAs) have realized the glitches and pain points that prevailed during the process. Of course, we started as distinct groups without coherence, however, over time we have modified our process to include new teams.
Even if we do not like it, BAs will be there on the projects. If not in one company, you would find in other. Instead of running away, together we worked as a team – of course with lot of fights and heated arguments) and redefined the process.
BAs need to collect only business requirements and nothing more than that. In some circumstances, they might also collect system requirements but shall stay aloof from user interface requirements.
Our process dictates 1 BA to 1 IA. We go together in requirement gathering meetings and try to do quick white boarding sessions followed by paper prototypes. This way, the process of collecting requirements become faster. Client also understands wireframe much better than usecases.
IAs: They create wireframes and document all the interactions with all possible flows using screenshots in Interaction Gudieline documents. This document evolves as it goes from IA to VD, who updates it with visually designed screenshots and also updates for any new changes introduced by her.
The development team finally gets two documents: usecases and interaction guidelines for each usecase.
This has helped us at Keane and I am sure it would work everywhere.
-Praveen Verma
Thanks, Praveen. Good points.
I’m curious too about ownership/responsibility and work products. Are you in fact producing use cases? I feel we need to be involved in whatever artifacts specify interaction–if we don’t “own” them, at least we have right of refusal. Whenever use cases or user stories are written by non-UX people, I feel there’s a disjunct between the intended interaction design and the realized one.