Web teams: an interview with Jesse James Garrett

Gerry Gaffney Teams Leave a Comment

Download (mp3: 8.65MB, 18:53) What makes a good web development team? Jesse describes the strategic and tactical elements in his “Nine Pillars” model.


Transcript

Gerry Gaffney:

My guest on the User Experience Podcast today is well known among web developers and designers. He developed the Elements of User Experience diagram in 2000, and subsequently developed the ideas into an excellent book. He also coined the term Ajax, and writes and speaks extensively on web design, information architecture, and related topics.

Jesse James Garrett, welcome to the User Experience Podcast.

Jesse James Garrett:

Thank you for having me.

Gerry:

I guess you’re probably best known for Ajax and the Elements of User Experience work but today I wanted to ask you about a model you developed and which you named the Nine Pillars of Successful Web Teams. Firstly, can you tell me how that model came about?

Jesse:

I’ve been working as a consultant, with a variety of organisations, for several years. I found myself being asked more and more frequently by my clients to advise them on issues that you might consider to be unrelated to user experience – issues having to do with how they structure their teams, how they structure their processes. They were asking me to review job descriptions and things like that, and that was how I first started getting interested in the problem of what makes web teams successful, and it was in the course of exploring that problem that I developed this model that I call the Nine Pillars.

Gerry:

Was there much information out there to help you or did it have to really develop it from scratch, and from your experience and your peers’ and colleagues’ experience?

Jesse:

Well, the difficulty with creating a generalised model like this is that when people talk about the ideal way to set up a team or a process, it’s always particular to a certain kind of project or a certain kind of product. There were some resources out there that were oriented toward the best ways that a large IT organisation could approach web design and development, and there were other ones out there that were about how a small company could manage the production of their website, but when you look at these models they had very little in common with one another, and the real challenge to my mind was how do you move beyond those specific cases and be able to talk generally about what makes web teams successful.

Gerry:

And before I ask you to actually tell us a little bit about the Nine Pillars, I’ll just point out to listeners that the diagram is available at your website. But can you take a moment to introduce us to what the nine pillars are?

Jesse:

Well, in my exploration of this subject I came to realise that by focusing on roles and the definition of roles, or focusing on the definition of stages in a development process, people were kind of missing the point, that they were actually asking the wrong questions.

Gerry:

So they were looking at a linear process whereas you’ve got a completely different model – is that correct?

Jesse:

Well, it’s not so much the linearity of it as it is the focus on roles and steps. The idea being, well, you know if we follow the same set of steps every single time that will ensure success, or if we have the same set of roles on every team, that will ensure success. And in my experience it hasn’t, it hasn’t ever worked that way. I’ve worked with very large teams that were greatly diversified and had a lot of highly specialised people on them, that were able to produce terrific results. And at the same time I’ve been able to work with very small teams of just a couple of people who brought a more kind of generalist approach to their work, and they were also very successful. And so I kind of got the sense that it wasn’t about the definition of roles or about the definition of processes, but rather it was about the underlying competencies and understanding what the competencies were that a project required, what the competencies were that the team brought to bear on the project, and making sure that the process where the team and the project come together enabled those competencies to be implemented, to be used successfully.

So in the Nine Pillars model… It’s a visual model, so it’s a little bit difficult to describe because there are relationships between pillars that are indicated visually in the model, but generally speaking, I talk about strategic competencies and tactical competencies. The importance of having competencies in planning and setting the long-term direction for the product, those are the strategic competencies, as well as competencies in execution and actually delivering the product, and those are the tactical ones.

There are four competencies that I consider to be purely strategic. The first one of those is user research… people sometimes kind of scratch their heads when they see that I consider user research a strategic competency, but from what I’ve seen, the most successful organisations are the ones who do consider user research to be fundamentally a strategic function. They go out and they talk to users and they allow their understanding of users, their observation of user behaviour, their understanding of user needs and expectations, to inform the long-term vision and the strategic direction for the website. So not just the kind of research… where we’re trying to figure out do we need to make that button a little bit bigger, should it go on the left rather than on the right, those kind of questions, but actually doing the analysis of the underlying user behaviour that will allow us to set a long-term strategy for the product.

Gerry:

So at the strategic level then you’ve got the user research, the technology strategy, site strategy and content strategy and then you’ve got sort of a central pillar which is abstract design.

Jesse:

So, right, building on the user research you have the manifestations of that strategy in what I call the site strategy, which is really about understanding that long-term product direction, the technology strategy which leverages the user research, as well as the site strategy to identify the technologies that are going to come into play, and the content strategy – what is the information that we need to have on the website, and what are the resources that we are going to bring to bear to produce that information or gather that information.

And all of these, all of these strategic considerations feed this competency that I call abstract design, and this one in the visualisation of the Pillars model actually straddles the line between the strategic and tactical competencies. Because abstract design is really the focal point where we take all of this input, everything that we know about the users, everything that we’ve decided about the direction of the product, the technologies that are going to be employed, the content that’s going to be incorporated and it all kind of comes to this focal point in the development of the design direction that in the Elements model – which is another model that I developed that a lot of people are probably familiar with – corresponds to the structure plane, the issues of information architecture, the structural relationships between content elements as well as interaction design, the structure of the flow of the experience for the users. And the development of all of this represents really the crystallisation of those strategic considerations into something that is actionable as we move from strategy into tactics.

Gerry:

Can you tell us then about the tactical pillars?

Jesse:

So that abstract design then is a driver of the tactical work in what I call technology implementation – that’s taking that technology strategy that’s been developed and actually writing the code, producing the HTML, building the database, getting all the servers set up, all of that kind of stuff. Then you’ve got the content production, so taking that content strategy and really going out there and writing the copy and taking the photographs and gathering up whatever data you want to have incorporated on the site. And then finally on top of the abstract design you have the concrete design, the specifics of the layout of the pages, the selection of colours and typography and brand-related elements in the production of those graphics. The competency that really ties all of these tactical competencies together is project management and project management is a competency that I think is often overlooked, especially in small organisations, people don’t often recognise the vital importance of having this competency in project management to the successful delivery of a project. And as a result I thought it was really important to call out project management as the driver of all of these tactical competencies.

Gerry:

Okay, thanks for that run-through of the model. I know it’s very difficult to present a visual model over the phone [laughs] so I think you’ve done very well – that’s today’s challenge for you. But can you tell me Jesse, are all the pillars equally important?

Jesse:

Well, the way that I really devised the model was as a tool that you could use at the beginning of a project to evaluate what the needs of the project were, because different projects are going to need the pillars in different proportions. You’ll have some projects that are going to be very heavy on strategy and they’re going to be deep into user research and technology strategy and content strategy. You’ll have other projects that are going to be really heavy on the tactics. It’s going to be all about implementing new technologies, producing new content and so on, and this also will vary from product to product. Some products are more technology driven products, and they’re going to require heavier emphasis on those technology oriented pillars, technology strategy, technology implementation. Other products are more content driven products and require a greater emphasis on content. The other way that you can use the Pillars model is as a diagnostic tool at the end of the project if you get to the end of the project and everyone’s kind of wondering “wow how did we end up here?”.

Gerry:

[Laughs].

“Our product ended up being you know, three months late, $300,000 dollars over budget and how do we make sure that this doesn’t happen again, where did we go wrong?” The Pillars is one way you can look at it, you can profile the needs of the project, profile the competencies of the team, and then look at the process and say well, we had somebody who was good at content strategy but we didn’t have a phase in our project plan for the content strategy work to actually happen and so as a result, maybe the product that we ended up delivering ended up suffering. So, as a long way of answering your question, the balance between the pillars is going to vary and in fact having the Pillars model is a way to evaluate exactly what kind of variance you’re looking at from project to project.

Gerry:

There seems to be a common thread, Jesse, between the Nine Pillars and the Five Elements of User Experience and in fact you’ve already alluded to that in today’s discussion by relating the abstract design across to the Elements model. Have you ever tried to combine then?

Jesse:

Well, you know the pillars model actually came about as a result of this, the desire of a lot of people to apply elements to their teams, and they would look at the five planes of the Elements model: structure, scope, I’m sorry, I can’t even remember.

Gerry:

[Laughter]. Strategy.

Jesse:

Strategy, scope, structure, skeleton and surface.

Gerry:

My students would be proud of you, Jesse, for remembering all five. [Laughter].

Jesse:

You would think that at this point the model is a little over six years old, you would think that I would have them down by now. Anyway the people look at that five plane model and they look at the little boxes in there for information architecture and interaction design and information design so on and they saw those potentially as a way of defining roles on their team. Okay and you be the strategy person and you be the scope person and you be the structure person and so on.

I was made uncomfortable by trying to apply Elements to teams because that’s not what Elements was intended for. Elements is about the considerations that go into creating successful experiences on the web. Elements is kind of this laundry list of things that you should think about in order to deliver successful experiences. Pillars is kind of orthogonal to elements in that Pillars is about the skills that you bring to bear in thinking about the elements contained in the Elements model.

Gerry:

Can you tell me, Jesse, why is it in your opinion that the Nine Pillars seem to be very much less well known than the Elements concept. Is it less important, is it less significant, is it too hard to grasp, too hard to implement, or do you have a take on that?

Jesse:

Well, [laughs], it’s an interesting question. I think that Elements by virtue of the time at which it was developed, became very widely known because there were very few models available at the time for thinking about delivering successful user experiences on the web. Whereas by the time I developed Nine Pillars… I did Nine Pillars, published it in 2003. It was the result of several years of kind of working through and thinking about these issues. By that time there were quite a lot more resources available for people and so there’s in a sense there’s a lot more competition for Nine Pillars and I think that also it is something that… Nine Pillars is intended to address a particular set of problems that a lot of people may not even recognise that they have, and if you don’t know that you have a particular problem it can be difficult to see the value of the solution when it’s presented to you.

You know I will say that I travel all over the world giving an all-day seminar based on Elements and Pillars as well as some of the other concepts that I developed, and almost invariably Pillars is the most popular segment of that talk, it’s the one that gets people most animated and it generates the most discussion from people about how their teams work and how they can make them work more successfully.

Gerry:

I must say, and we had this discussion by email prior to getting together today, I found that the Nine Pillars is very applicable to many of the disastrous projects that I’ve been involved in.

Jesse:

Yeah, well I’ve actually heard that from a lot of people. A lot of people don’t really get it, don’t really understand the value of the model until they run into one of these calamitous situations, and I get email from people saying from time to time saying you know, “we got to the end of the project and it just, it just completely went off the rails and we didn’t know what to do about it, and then we looked at the Pillars model and realised oh, here’s how we can address this going forward”.

Gerry:

[Laughs]. And finally, and obviously this is a topic that we could talk about at great length and in fact I’ve heard you talk about it at great length and it’s been extremely interesting but because of our time constraints we can’t really do that. But finally I’d love to ask you, do you have any advice, and this is a really difficult one I think, do you have any advice for people who are working with teams that are missing some of these pillars and who may not be in a position to address the problem directly for, you know, budgetary or political reasons or whatever.

Jesse:

Well you know, the one thing about the Pillars… On my website I’ve got a nice single sheet, printable version of the Pillars model that contains descriptions of all the pillars and why these competencies are important and it was deliberately designed to be frankly a little piece of propaganda that people could hand over to the people who did have that kind of decision making power and just start kind of planting this idea in their heads, and on a project by project basis when these kinds of issues came up, that it could be something that they could refer back to and say “you know, remember that thing that I showed you, well you know maybe we do need some content strategy here”, or what have you. So really what this is about for me is putting tools in the hand of people to try to persuade others to do the right thing.

Gerry:

Okay, and that propaganda material is available on your website.

Jesse James Garrett, thank you very much for joining me today on the User Experience Podcast.

Jesse:

Thank you for having me.

Note:

Gerry highly recommends Jesse James Garrett’s book The Elements of User Experience: User-Centered Design for the Web.

Audio first published: September 2006

A note on the transcripts

We make verbatim transcripts of the User Experience podcast. We then edit the transcripts to remove speech-specific elements that interfere with meaning in print (primarily space-fillers such as “you know…”, “um…”).

Gerry GaffneyWeb teams: an interview with Jesse James Garrett

Leave a Reply

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