Keep up-to-date…
Like to find out when new articles or book reviews are added?
Here's my email:
And just in case you're wondering, your email address will never be sold or given out to anyone. We hate spam as much as anyone else.

Think like a consultantJune 20, 2001
Just got back from a trip to San Francisco, where I was able to join the San Francisco IA cocktail hour for a fascinating discussion about the differences between being an information architect as an employee within a company, as a consultant, or as for an outside developer (or agency).

Having done all three, I'll have some more thoughts coming up on this, but here's a few initial ones…

» To large degree, an information architect (or UX architect, or usabilty expert, etc.) is a consultant regardless of where they work. Rarely do they have final decision-making authority over the development process, consequently they need to be able persuade others about why certain things need to be done.

» Since UX is a new field, introducing a user-focused process often means changing how companies—and more importantly, people—are used to doing things. So the UX architect also needs to have skills as a "change agent."

» Consultants often have an advantage in introducing change because something's paying for their advice. Needless to say this aggravating for in-house people who'd been saying exactly the same thing previously and been ignored. However, rather than getting angry at the consultants, which all too often happens, it's an ideal time to enlist their help in building credibility of the in-house UX person—who will be there long after the consultants are gone. There is some potential tension there, because consultants are interested in making themselves and their consultancy appear valuable to the client, but smart consultants recognize that even more important than delivering a good deliverable is creating successes within the client's organization (especially for those who hired you, needless to say…)

» One of the main difference between being an UX in different working environments of is the degree of "transparency." Working with an outside developer is like ordering a meal in a restaurant, you place your order, the chefs do their work, and then the meal appears. Clients may not know what's going on in the kitchen, but they do recognize when the food is burnt. Being a consultant is more like being one of those chefs who prepares food at your table. The customers may not know you, but they can not only judge the meal itself but how it's prepared. (That said, they may not know exactly what you're doing, and consultants like table-side chefs aren't above the occasional "flashy" technique intended to impress.) Working in-house, is similiar to cooking a meal with your friends—they're intimately involved and they know your history (or at least they think they know.)

» When it comes to proving their value, internal UX people need to think more like external consultants, who are careful to demonstrate their value since they need to justify why the company is spending money on them. Too often, companies take internal UX people for granted, but this is in part because internal people all too often don't sell themselves. So pose the question: if I were being hired an external consultant, how would I justify my fees in terms of creating value for the business—from the viewpoint of my "clients" (i.e. what business goals is better UX serving?).

» For both consultants and in-house employees, finding a "champion" for your work is crucial. Ideally, it's the CEO, since when CEOs talk about things, they expect to see action on it. But it's just as important to get buy-in all the way down the line, since an entrenched bureaucracy can defeat even the most hard-charging CEO.