Regarding Confluence

Mia Ridge, as she always does, makes a ton of sense out of a few of the major problems museum tech-folks face today in her post Confluence on digital channels; technologists and organisational change?  As I’m putting the finishing touches on my proposals for Museums and the Web 2013, I find there’s quite a bit of overlap between the topics I’m interested in writing about and what Mia has written about here.  I won’t (yet) comment on the larger themes of the essay, however, I do have a different perspective (coming from the IT side of the house), which I feel differs slightly from Mia’s perspective.

Creative is Still a Service Department

In her post, Mia writes:

In museums there’s often a perception that digital teams are a service department (perhaps because of their roots in IT departments) while digital teams see themselves as creative departments, commissioning content and design, producing innovative experiences and consulting within the museum on digital projects.

Pointing out the tension between the creative side of the house and the IT-rooted technical side of the house is fantastic – this tension is often the 800 pound gorilla in the room.  I think the reality of functioning in a modern organization of any variety, particularly museums, is that there are few (if any) departments who truly have final, absolute say in content and delivery, and for good reason.  If there are any departments like that in your organization, they better be curatorial (put down your pitchforks, open authority folks ;)).

Tech folks can generally all agree, though, that content folks and other stakeholders have traditionally been, and are still today, too close to website implementation; the contract between web teams and stakeholders is too low-level.  As it stands, most work orders sound something like this:

Stakeholder: On the About The Museum Page, we need to bulk up the section on our trustees.  Add a new page under the about menu with a grid of headshots and then the names, and after the names put what committee they are on.

Whereas ideally, the contract would be higher up, and focused more on goals, not on tasks, like so:

Stakeholder: One of the trustees was unhappy about the amount of coverage the board gets on the about page. We would like there to be more information about the trustees on the about section, particularly their names, faces, and committees.  What can be done about that, and how can we show this trustee that the page is doing an appropriate job in educating visitors about the board?

Bingo.  This is what we want.  We get to use our formidable expertise in Problem Solving, SEO, Information Architecture, Page Design, etc.  Stakeholder gets an awesome solution, backed by metrics that directly measure the results.  If it underperforms, we can start split testing different versions until we start getting to one that meets all the requirements.

Why They Need it Bold, Red & Blinky

(And Can We Make Them Stop?)

It seems a surprising percentage of web folks actually believe in their heart of hearts that stakeholders come with strong ideas for implementation to spite them.

Mostly, I reckon it’s because page design is fun.  Many people that make requests for creative development don’t get to do very much of it, and the website in almost every institution was a wild west (where this level of buy-in was encouraged!). As such, it’s very difficult to move that boundary back from task-centric to goal-centric, and to basically tell people to not bother you with their ideas.. it’s a difficult situation for technologists because, well, most of us are better at talking to computers than people.

IT departments generally solve it with process: change requests processes, procedural review of requests by an information architect, and all the hoops and trappings of IT-dom.  This technique can be effective, but result in poor customer satisfaction, and it invites stakeholders to be just interested enough to cover the basics, not interested enough in building the best solution.  Who likes dealing with tech-reaucracy?

The same demoralizing effect can be felt through mandate by executive order.  This can also lead to rebellion: marketing trying to out-source micro sites or other small web things, development angling to get their ‘own’ website, etc.  Particularly in small institutions, these types of behaviors can quickly fracture a cohesive web strategy, and it seems to occur all too often utilizing the mandate approach.

The secret, as it turns out, is held by graphic designers (go figure).

In Ken Reynolds‘ inspirational article There’s No Such Thing As A Bad Client for Smashing Magazine, he writes:

A lot of client conflicts arise from a lack of knowledge. Sometimes the client just doesn’t understand what we do as creative professionals, and this accounts for many of their crazy requests. Our job as designers is to help them with their particular goals. They always have a target in sight; they just don’t know how to hit it. Communication is all-important. You have to understand what the client wants, and the client has to know what you need to do to make it happen.

Every client is different, and each has to be handled a different way. You’ll have to be attentive to some; others will require a standoff-ish approach. The important thing is finding a way to draw clear lines of communication, so that both parties know exactly what they’re getting out of the business transaction. Hopefully, the client will educate you as much as you do them.

Wait, what?  Every client is different?  There’s not a magic solution?  The good news is, as a department, we will deal with the same [2,6,10,20,40] stakeholders time and time again.  That makes it at least a little bit easier.  The ideal solution should leverage stakeholder’s enthusiasm, and utilize our privileged position as web experts to educate, explain and collaborate.

We Need Customer Service!

To enable handling a wide-variety of customers, web teams need customer service staff.  In some institutions this staff can be project management staff, or a central coordinator in smaller institutions.  Some customers will want to be present for the web design process, or at least for regular status updates, some will be content with giving you goals and expecting great delivery.

Kevin Hoffman wrote an outline for the basics of this process in A List Apart, in an article entitled Facilitating Great Design:

  1. Provide clear guidance through a series of steps intended to reach an agreed-upon end result.
  2. Always follow this pattern: allow for divergence of opinion, permit participants to explore those opinions within constraints, and then force ideas to converge.
  3. Provide a real-time representation of what’s going on during the meeting where people can see it.
  4. Keep in mind that everyone in the room, no matter what they say, believes that their recommended action equates to doing the right thing.
There’s a lot more that goes into these processes, and a thorough understanding of the intricacies with dealing with difficult customers can take a real time commitment to master.  It’s not something that happens overnight, cultural change is slow and steady, most times.
It’s easy to just say we should get autonomy, stakeholders should deal with it, and the World will be happy.  In reality, that scenario is rarely possible, and in situations where it is possible, it’s often unwise (due to the issues stated above re: bureaucracy and resentment).  It’s the harder road, but we should slowly, purposefully and permanently move the culture towards thinking about web projects in terms of solving problems with measurable results, not with making the trustee names bold, red and blinky.  This is not to say, however, that the process should be opaque, transparency is a good thing.  Involve stakeholders in the process, for it is through this way, with excellent facilitation and customer service, that your teammates at your institution can begin to see exactly what expertise you bring.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>