Boxes and Arrows: Comments by Joseph Selbie

Joseph Selbie — Thu, 19 Feb 2009 19:37:27 GMT

Terry,

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

Joseph Selbie — Thu, 19 Feb 2009 19:49:24 GMT

Benjamin,

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

Joseph Selbie — Fri, 20 Feb 2009 17:29:23 GMT

Jamie,

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

Joseph Selbie — Sat, 07 Mar 2009 22:35:11 GMT

Steven,

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

Joseph Selbie — Sat, 07 Mar 2009 22:42:32 GMT

Bryan,

Thanks for your comment. An ounce of planning is always worth a pound of work. But these days, with the ever increasing pressures to produce products and solutions faster, there is less ansd less time allowed for planning. Agile programming is just an example. The challenge these days is to make planning an ongoing process, to fit in with faster release cycles, and shared holistic awareness across all domains becomes even more important when decisions and planning need to come at a faster rate. The shorter the cycle time it takes your team to synch up on new goals and apply the creativity needed to support them the better.

Best regards,
Joseph

Joseph Selbie — Sat, 07 Mar 2009 22:48:47 GMT

Qin Han,

I am not as aware of the field of service design as I am of experience and interactive design, but it seems to me that the equivalent domain to IT capabilities in the world of service design is whatever physical otr electronic aids the service providers need in order to provide their service. This could be telephony, real-time knowledgebase provision, check out systems, hand-held wireless tablets, on screen or printed script reminders, etc.

I hope that is helpful.

Best regards,
Joseph