— 28 March 2003 —

Scenario-Based Design

When you work in a corporation that develops software, everything seems to be about how the system works. The user is second. If the app works “on my machine” it should work for everyone. And it does. You double-click to open the app and it appears on your screen. You may or may not know what to do next depending on how much the development team looked at user needs.

I watch the way people talk in meetings during the product lifecycle. System, system, system. I am there to remind them that if the people for whom they are developing this product cannot use said product, then they have created a piece of crap. I tend not to use the word crap, unless the project is an overhaul of an existing product. So there I am, the User Interface Designer. I am not entirely happy with that title though. I practice User-Centered Design. Not happy with that title either. Nothing I do fits neatly within the methodology of software development. And that is sad.

But like I said, I watch the way people talk in meetings. And the other day, as I was watching, I realized what part of the problems was. I don’t do “devspeak,” and the developers don’t speak UCD. And neither of us should have to. But the one thing everyone talks about (or the way they talk about things) is, “Suppose something like this happens… I want to find a file, so I go to the homepage, click the file attachments link, look at the list, find the one I want, click on it and there it is.” And I nod, saying, “That’s how we intend the interaction to work.”

So I think, I shouldn’t be a User Interface Designer, I should be an Interaction Designer. And there are plenty of people in the “industry” who have Interaction Designer as a title. But, I still think that is too industry-centric. So I think again, “What did he just describe?” A scenario. Scenario-based Design. But I don’t want to be a Scenario-based Designer. I think I still like Interaction Designer as a job title, but I am liking Scenario-based Design as a substitute for User-Centered Design more and more.

Too much software has been developed as a collection of functionality. And over the years, if that piece of software has survived the many trials and tribulations that software often goes through, that functionality turns into a collection of things to do. I think that software development needs to focus more on solving problems, rather than provide functionality. The people who build this stuff talk in the mode of scenarios in order to explain to each other what they expect the system to be able to do. I talk in scenarios about what the user should be able to accomplish. So, Scenario-based Design. In my happy place, no business requirements are allowed to be gathered until the scenarios of use are defined. These would invariably produce business requirements. But the scenarios would be built by a team that included an Interaction Designer, a Business Analyst, and a Developer. This small team would look at feedback from the current product; conduct user interviews; look at click-streams, onpage times et al. Then they would sit down and come up with a list of things than need solutions.

The users are having problems with A. The users want to be able to do B. The list would essentially be a bunch of narratives on what should be provided by the functionality in scenario form. It would have a bit of high level goals of the users. It would have a bit of the business information. It would have some suggestions as to the functionality. But it would be something that everyone on the project team could get their mind around. This group could relatively quickly figure out whether anything actually needs to be done. If they couldn’t come up with any scenarios, or the scenarios they did come up with didn’t fit the direction of the business needs, no project would be initiated.

Today we have Charters, and Scope Descriptors, and Plans that are all separate documents and are usually put together by someone who won’t actually be on the project, or that doesn’t have any experience with user, business, or system issues. And too much time is spent trying to fit functionality (separate from purpose) into the scope, which may or may not be what actually gets done on the project. I have been on too many projects that spend 600 hours at (conservatively) 80$ per hour to find out that another project was scoped to do the same work. Or that the cost of doing the work would be too high so the project is stopped.

A scenario-based process would also help with the badly needed fragmenting of software development. Instead of a project building a tool for a user group, you look at the scenarios of use and see how they apply across the enterprise. Then you design a solution to that usage scenario that all of a sudden many user groups can have access to.

Yikes, I am writing a lot. I should get back to my non-scenario, non-solution world of work. This idea still needs so work, but I think I am getting close to a good idea. But will I change the world with it? Dunno. Is this taking place elsewhere? Let me know.

Respond Eloquently Below

April 2008 March 2008 February 2008 January 2008 December 2007 November 2007 October 2007 September 2007 August 2007 July 2007 June 2007 April 2007 March 2007 February 2007 January 2007 December 2006 November 2006 October 2006 September 2006 August 2006 July 2006 June 2006 May 2006 April 2006 March 2006 February 2006 January 2006 December 2005 November 2005 October 2005 September 2005 August 2005 July 2005 June 2005 May 2005 April 2005 March 2005 February 2005 January 2005 December 2004 November 2004 October 2004 September 2004 August 2004 July 2004 June 2004 May 2004 April 2004 March 2004 February 2004 January 2004 December 2003 October 2003 September 2003 August 2003 July 2003 June 2003 May 2003 April 2003 March 2003 February 2003 January 2003 December 2002 November 2002 October 2002 September 2002
Snook Approved!