One question that came to mind as I was reading is how to factor in the inherent complexity of the domain in which the product sits. Obviously, one of the reasons why team members might avoid learning about other people’s work is if that work is ridiculously difficult to understand. I’ve experienced projects where, for example, the underlying technology was so complex that even within the IT segment, few developers understood what their development colleagues were doing. I’m not sure they all understood their OWN work. =) In situations like this, the lack of holistic awareness is clearly a big problem, but I suspect that creating a holistic awareness would involve so much effort that it would be counter-productive. For practical reasons, there may be a point when the complexity of the domain requires a team to shift from holistic awareness to trust in one’s teammates in order to be successful.

However, for #5, I must disagree. Designing in a group I found to be very counter productive. There’s too many ideas floating around even if there’s less than a dozen people. Focus also isn’t achieved because there’s no real structure and there’s too many people (from too many disciplines) wanting to design but don’t have the skills to design. Instead, I suggest leaving the designing to the designer. Do it in iterations where a group may be able to review. Or better yet, have a design tested and have the group review the test results. And in order to come up with an initial mockup, have the designer listen to a requirements discussion or at least review the requirements before creating it.

I found that as a designer, it’s better to not design until I pull out key phrases and words to form what needs to be achieved. Only then can you start designing anything.

Sounds like you’ve been there .

In the main I agree with your comment. Even in less complex environments than the one you describe I don’t think it is possible for all team members to *fully* understand the complexities of the IT environment — and harder still in the scenario you describe. But at a minimum I think it is still possible, and very important, that all team members are given enough information from the programmers/programming lead that they know what can and cannot be done at the interface and interaction level (i.e. drag and drop?, fixed javascript library?, custom javascript effects, .net extensions?) and any significant data limitations, in order for the user experience to be designed in such a way that it can be built as designed.

There are few things more damaging to the final outcome of a project than to have the design spec come unraveled when it gets to the development stage. When that happens, less well thought out (and almost always less user centered) solutions are substituted for the ones in the original design, and due to press of time, these solutions cannot be iterated again with the full team.

Better by far to be able to perform the user experience design process with a shared holistic awareness of what *can* be done — even if many team members can’t fully appreciate the “why” the limitations.

Best regards,
Joseph

I can sympathize with your description of a group design process. They can go way off purpose. We call them “goat rodeos” when that happens. However, a well planned collaborative session, sometimes lasting several days, can move through issues, problems and iterations very rapidly, which would otherwise take weeks (or not be done at all).

The secret we have found is preparation. We are very careful to get real decison makers in the room from all three domains. We make sure that business goals are clear before we start. We also have some ideas already “in our pockets” that we can begin sketching on the white board to get things going. And we make sure that the scope of the session is clearly delineated — a particualr work flow is usually how we focus it.

It is also very important that whoever facilitates the sessions can bring things back to focus when they (inevitably) go off on tangents, and knows when to “table” certain important discussions for future resolution.

Don’t give up on collaborative sessions . Done right they can give magical results!

Best regards,
Joseph

“Goat rodeos”, huh? How classic!

I think the big challenge we have is thinking in terms of work flow. Unfortunately, we don’t operate so much that way – which is why we’re on the track to develop Personas to get us on track. (We never used to really think about the user either.)

I’m glad you gave tips on how to get people to collaborate in such design sessions. So far, I can say with confidence that we’ve only completed ONE design session successfully. To get everyone focused is a huge challenge too.

Thanks for describing the jigsaw approach. I can see us using it in future.

Your post also gives me the opportunity to emphasize (and empathize with) the point you make about the additional challenges of geographically dispersed teams. In our study we found that geographically dispersed teams, in order to be successful, needed to make extra effort to acheive a shared holistic awareness of their project. Teams that enjoy close proximity can develop a certain amount of shared awareness simply because they have conversations in the hall, or can easily sit down for 10 minutes to go over a specific point, but this natural communication process is missing when teams are separated.

Geographically dispersed teams are especially helped by the intensive focus of shared collaborative workshops. Budget constraints and schedules militate against workshops, and of course teams need to work within the realities imposed on them by circumstances. But if at all possible, I highly recommend having at least one multi-day collaborative session as described in my article. It does wonders to bring things into focus.

Best regards,
Joseph

I really wish more companies GOT this concept, because it can easily be applied to so many more disciplines than Web Design. With downsizing running rampant (and the resulting job paranoia predictably going unchecked), I am seeing more and more the application of what I call the “Three Lock Box” approach to nearly everything. Every member of the diminishing team owns/excels in one aspect of a given project, but none understands the overall project goal. Most times, we cannot even come to agreement on the most effective approach. The catch-phrase “you OWN IT” is still slung around like beans and hash by middle management, but how can “ownership” even be conceived of when one cannot contribute anything to the project substantively while the other team members are out skiing, taking a mental health day, or home tending to a sick kid?

I think I’ll pass a link to this article on to my boss tomorrow.
Best regards,
– Steve Pomeroy
Manchester, NH

I am inspired by this post and actually made a another one to help understand the holistic approach to Service Design… But yet have some confusion over what I can use to replace the right corner where the ‘IT Capabilities’ was in your graph, since the technology Service Designer use varies largely according in individual projects… My assumption is that they use techniques such as observation and visual communication to stimulate conversations among stakeholders… well… wonder if you have any oppinon or suggestions?

Comments welcomed in my blog post on the topic as well

http://designgeneralist.blogspot.com/2009/03/holistic-view-for-service-design-team.html

Thanks!

Qin

I feel your pain . As an outside consultancy, my company (Tristream) is often brought in when a high-value or mission-critical project is showing distinct signs of upcoming failure. The project is nearly always heading for failure because of really basic reasons — poor communication, lack of clarity in the business goals, missing expertise, and no real project leadership to facilitate the holistic understanding of the project across all the affected domains. Fixing these problems doesn’t always require adding significantly more resources, pushing out the deadlines, or anything that has a high negative impact on the company. The fixes are usually just a matter of focusing the project.

Good luck,
Joseph