Notes on the role of project managers in Interface design

This is a post I made to the chi-web public dlist a few years ago. It’s surfaced here to help answer a common question I get: how do you integrate design into a development team? It’s a good description of the role that project managers can play in the design and engineering process. Remember it’s an extended anecdote, YMMV, and I no longer have this particular job or role. If you want to know what I’m doing now, read this.

Date:Fri, 18 Jun 1999 16:27:57 -0700
Reply-To:Scott Berkun
Sender:<CHIWEB@ACM.ORG>
From: Scott Berkun
Subject: Re: “The Gap from User Requirement and Design”

Here’s a short description about my experience when I worked as a Program Manager on Internet Explorer 5.0, which I think turned out pretty well.
Two disclaimers:

1. This is my rough personal recollection and description, so other folks on the team might not have the same perspective
2. This is just one team of many at Microsoft, and different teams here have very different ways of getting things done
3. (bonus disclaimer) This is about software, and while many of the design/process issues remain the same for the web, the timelines may differ. We released code publically 3 times, two betas and a final release, and each milestone was very roughly 4 months in length.

My job title is Program Manager. I’m expected to do two basic things: project management for certain areas of the project, and some level of interaction design or design thinking. I am not a developer and do not write production code. I have a degree in Logic & Computation (CS+Philosophy) with a concentration in Human Computer Interaction from CMU. I was a usability specialist for over a year (IE 1.0 and 2.0) before I became a Program Manager – this is not typical, but not unique.

For project management, it’s my job early in the product cycle to work with usability and sometimes marketing folks to gather and understand the data about our users. Often this is usability studies, surveys, market research, site visits or other techniques, if possible applied to the last version of our product. We take that data and work it into problem statements, often ranking them in severity and priority. Usability is the primary driver in obtaining and analyzing data. Product Designers are often involved in at least digesting and understanding the data. Our group manager will work with all of the data and come to some consensus on the user’s we’re targeting for the entire product, what the key problems are and how we’ll invest our development effort across the product. This is high level, cross website/product thinking. But within my area(s) of the product I’m expected to drive the prioritization of effort and problems we’re targeting.

Then we’ll move into the design phases. I’ll spend a lot of time working with the product designer sketching out ideas to solve the problems that we have. Depending on how much interaction design or visual design skill the designer has, I may contribute a lot in the interaction design since I’m skilled at it, or only influence things. (If I had no skill at interaction design, I’d yield much of the process and decision making to them). We’ll go through dozens of ideas, and when we have two or three well conceived ones, it’s my job again to co-ordinate with usability to figure out how we can examine our designs and possibly make decisions on which approaches work better.

Periodically we’ll review our set of ideas with the feature team to get feedback, and explain why we think one or two of them are the ones to try out. We’ll also put up our screenshots in the hallway to encourage folks to drop by with comments or other ideas. Once we have more data from usability, we’ll iterate and examine again, possibly repeating this sequence many times. The designer and myself work tightly together to cycle through lots of ideas. We try to keep it tight, so we can cover a lot of ground, but we’ll pull in usability, user assistance, the developer or other designers to get feedback and different perspectives. Again, it’s open door, so if people care enough they can drop by and look at the hallway screenshots, or give us their opinion in email or over lunch.

Functional flow, terminology, navigation, information architecture, all get covered as we discuss each idea. These are all attributes of good design, and they get manifested either in our drawings, or as comments folks make when we show our ideas. We use different analysis and creation techniques as apporpriate for the situation and nature of the problem. There is no way to sketch out the design for something without describing with some level of specificity how these specific attributes will be fulfilled, so we don’t invest specific time in following a single model or protocol. We focus on the designs themselves, and our expectations for the interaction qualities. As our ideas get support and detail, it’s my job as the Program Manager to write the specification.

I’ll work with the developer and tester as I write drafts, so that as I write the document I understand what the relative costs of choices are, and so that the document reflects the reality of what the team thinks we will do, not just a fantasy of what I’d like to do. It also gets dev and test bought in to the process, so the ideas are as much theirs as mine and the designer’s. Often I’ll start this document at the beginning of the design phase, and update it periodically as we develop the ideas. We’ll have a spec review to close out the design phase, where I present the spec to the team (dev/test/ua/marketing/etc.), and take any feedback on decisions. If I’ve done my job, and communicated things well along the way, with support for key issues from usability, the spec review is a relatively painless process where detail problems are flagged, or issues raised, but no major approach arguments arise. If there are problems, it’s my job to define the path to resolution, and make it happen.

As the stuff gets built, I work directly with the developer and tester to answer questions not covered in the spec, and make tradeoff decisions that we missed during the spec process. The designer may spend a lot of time with the developer to ensure the visual and behavior details come out right, or helping answer questions. We’re almost always continuing to usability test specific things, and it’s my job to figure out how we adjust and respond to the things we learn. Usability jumps in as appropriate to make sure we haven’t missed things, or created new problems as we go. As we trail off in the schedule, I’ll drive the decision making process for bug fix decisions, working with dev and test to make the right decisions and drive the product out the door.

Throughout the whole process, it’s mostly my job to make sure the right decisions get made – I may not make the call myself, but I make sure that there is a good process, and a good final call gets made. The fact that I’m the project manager, but I have HCI knowledge puts me in the position of understanding all of the tradeoffs, and how they will impact the user experience. In tie-breakers I’m usually the one expected to make the call or figure out how to move things forward.

In summary, I think one key to success is to enable a very small set of folks to drive the design thinking. I would much rather have one product designer that has medium proficiency in information design, visual design, and interaction design, than three individuals each contributing only those independent perspectives. You want a small number of people to be able to go and iterate quickly, trying out lots of ideas without hoops, bureaucracy or design by committee, but balanced by input or contributions from all of the disciplines you need. Regular meetings of the key folks, hallway screenshots, and a healthy attitude will draw in all of the other people that need to contribute. But there has to be a nugget of 2 or 3 people that will go and drive the design effort, and pave the way for discussion and commentary from everyone else. If you have a set of people that work particularly well, you can maybe stretch it to 3 or 5.

The role of Program Management (PM) at Microsoft has been documented before, I think in one of those Microsoft Secret’s books, despite our lack of secrecy about it, but I forget which one. The main difference is that I’m called a UI PM – which means I’m expected to have aptitude and understanding for interaction design issues in addition to project management and technical knowledge. The majority of PMs in the company focus on the project management aspects or designs of the technical infrastructure for their products, and do not have a background in interaction design.
-Scott

---

Have a comment on this essay? Let me know in the forums.
Scott’s best selling book, the art of project management, all about successfully leading and managing teams of people, has two free chapters: How to figure out what to do and How to make things happen, you can read them here.