Archival Encore – 2003.03.28

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.