Emotional Design of Project Server

Like most people I always thought about the deployment of software as a technical exercise. Then I went to work for Pacific Edge Software in 1998 and I started to understand that deploying project management software was about more than just running setup.exe. I started to understand that it was at least as much art as science. The design of the deployment was less about the software and more about the users and the specific and unique (at least unique in the customer's mind) way they will use the software. My work with Project Server after leaving Pacific Edge has only confirmed this for me.

I recently found a reference to Donald Norman's new book Emotional Design and it puts even more weight behind the idea. In this book Norman examines the psychological attachment that users of products feel for them and how, to a certain extent, this 'feeling' for the product can be part of the design process of the product itself. He breaks total product design down into three parts: Visceral Design, Behavioral Design and Reflective Design. Visceral is the appearance of the product. Does the product look cool? Behavioral is the effectiveness of the product. Does the product actually DO what is expected of it? Then there is Reflective which is the personal satisfaction with the product. Does the product make you feel good. There is certainly more to Normans thoughts on these subjects but the above (grossly inadequate summary) is all you get for free from me. :-)

For sure this book focuses squarely on "real" products. It does mention products like websites but Norman spends much of his time dealing with real 'things', tangible stuff. But this does not mean that the ideas he puts forth in Emotional Design are not applicable in information systems like project management systems. Project Server for example can be broken down into these three areas of design. Some of the factors that fall into these three areas are under our control as consultants. Some of them are in the control of Microsoft.

Visceral Design:
How does it look? Is it visually appealing? When you look at it does it say something?
For the most part this is in the hands of Microsoft. Unless you want to go build your own UI for Project Web Access you get to use the one Microsoft gave us. For the most part the UI is pretty good. It has some things I would change for sure but all in all it's visual impact is a good one. Now there are things about the visual impact of the product that we as deployment consultants can have control over: The Portfolio Analyzer. These views don't come preconfigured. It is up to us to build those views. I have seen some very, very nice looking charts in the Portfolio Analyzer. I have also seen some that sent a shudder down my spine. Even if these views, after getting over their look, put forth good info it will hardly matter. As Norman discusses in his book. People don't like ugly things.

Behavioral Design:
This is the meat. Does Project Server (or Product X) do what the user is expecting it to do? Here Microsoft holds many of the cards but not nearly as many as with the Visceral stuff. Microsoft wrote the code so much of what the product does is really up to that code. However, there is much in this area that depends on our skill as consultants and really as designers. The RBS and the Group and Category security design is all up to us. If we listen to the customer and design an RBS and security deployment that is sound then the user will be happy. If we do not it will not matter how well Microsoft's works the customer will not like the product because the users will not be able to see and work with the right data!

Reflective Design:
This is the part that I still have not wrapped my head around yet. Reflective design deals with how the product makes the user feel about themselves. This is something a little more complex than just designing nice Portfolio Analyzer views or building a good RBS structure. This is about how the product affects the way the user sees themselves for having used the product. My jury is still out on how we as consultants can deal with this aspect of design.

The long and the short is that it may be well worth your time to check out Norman's book. It may just make you a better consultant.

Comments

[David Locke]

All artifacts fill emotional needs. When I look at software, I see

Concepts
Features
Tasks (tool tasks and user tasks)
What or how should I think
What should I feel
What do I do with this (beyond user tasks),
what are the perfomance standards,
what are the best practices, and
how do I obtain expertise
How to be (as a practitioner in this domain),
How does the application affect me
How do I act as a member of the community
of practitioners,
How do I act as a member of the customer
community for this particular product
How does the vendor act towards me.

When you consider that software users breakdown into two categories: conceptual model users and rote users, and consider that the only difference between the two is their focus on what they are doing.

Here I mean the geek/technical enthusiast (of software) is a conceptual model users. They discover what the software does. They consider the software as the source for the automated discipline. Discoverablity is the limit on the technical enthusiasts ability to build a model exhibiting fidelity.

Rote users, the ones typically thought of as being in need of a computer literacy class, perform computer tasks by rote. But, they use conceptual models of their discipline. They have to design the work relative to the constraints presented by the interface. This is their experience. They don't have time to discover the domain as it is interpreted by the software. They must get work done. An application offers them the ability to get things done both towards productive ends and away from productive ends.

Then, there are the issue surrounding how we learn. As we make the first step in learning, we first learn that there is much that we didn't know. We move from unconscious-unknowing to conscious-unknowing. We feel awkward. We become anxious. This is one of those places were the typical vendor education fails. I've even known some instructional designers that never realized the need to overcome this fear, the need to affirm, the need to build self confidence.

All of these issues play into the experience of using software.

Consider as well, the user's interaction with the vendor, with technical support, with billing.