lanehalley

Modified version of post in http://www.ixda.org/discuss.php?post=2513

My first interaction design experience came from a game company. Back in the mid 90's I worked as a Producer for a company that produced educational, fantasy and sports titles. I was asked to join the project because a dev team was working on "the best college football game ever" but they couldn't tell management what it was going to look like "until it was done." I didn't know it at the time, but I was about to have my first adventure as an interaction designer.

I started by asking what the game was going to be like, and through naive questions pointed out areas that needed more thought. Eventually, I created a "storyboard" for the game with a flowchart of game scenes, sketches of key screens and descriptions of movement commands. We then used this document to get buy-in from management for our development schedule and coordinate the packaging and the publicity with the marketing group.

Once we had a written plan, I kept working with the dev team. We solved interaction questions as they arose. I prepared libraries of sound and art assets, wrote help files in RoboHelp, researched and licensed music, and hired and managed contractors (art/voice) talents. After the PC CD-ROM games market tanked ~'96 (long live the Web!) I spent a short term as a Web designer, and then joined Cooper in '97.

Looking back on the situation, I think my product responsibilities gave me a better working relationship with the dev team than many of the other Producers I knew, many of whom were more marketing oriented. However, if you want to get into the game industry as a bridge to an Interaction Design career these days, you might consider looking for "Producer" or "Associate Producer" openings. The concept of IxD is more widely known now than it was when I started, and you may not get quite so many raised eyebrows whey you suggest it is a necessary part of the process.

In a recent post on Core77 Out of the Frying Pan, into the Fire: Life lessons from consulting to academia, and back again, Jon Kolko has some interesting things to say about the design process, design communication and how they relate to successful projects. He frames it in terms of a cultural difference between academia and consulting, but I think he touches on a larger issue, the need for IxDesigners to facilitate the design process. We must communicate about and and gain consensus for the problem definition as well as the design solution.

Although I can't tell when John says "Design" if he means Industrial Design, or Interaction Design, or some combination of both, he certainly has identified pain points that I've seen at consultancies that do ID and/or IxD.

As I know from painful personal experience, when the business requirements are shifting throughout the project, you can't create any sort of cohesive design solution. However, the insights of IxD can be used for more than just wireframes and screen design. IxD can help organizations understand clearly the opportunities that exist--who is served, what they need to be happy, as well as how the solution can be presented in the best way.

"While teaching, I emphasized cohesive process and strong documentation because I saw the value of instilling a repeatable and user-centered design methodology as a base upon which individual design skills could then be built. Yet, this type of education occurs in an envirnoment [sic] that is sheltered and artificial—by definition. Even the most industry-focused academic programs emphasize and teach a "clean" process, with deliverables that are defined in advance, requirements that generally don't change, and participants who are competent, articulate and well-mannered. Students make "good" design decisions because they have a rigid and confined set of constraints in which to work, and as it should, the safety net of academia provides a positive environment in which to fail."

Although I wouldn't say we have a perfect process, Cooper projects actually function in a way that's pretty close to to Jon's "ideal." Deliverables are defined in advance, requirements are relatively stable (because we define UI requirements as a balance of business and user requirements). Once the entire team (Cooper and the client project team) understand the research findings, personas and scenarios, we all start to pull in the same direction. There are fewer arguments when we all agree what we're trying to accomplish and simply vary in approach.

"Design consulting operates in a dramatically different world. While a statement of work may attempt to define concrete deliverables, even the most well-intentioned presales and planning effort can't cohesively estimate the proper amount of sketches, wireframes, documents, or deliverables that will "solve" a given design problem and communicate the solution. Changing requirements lead to slipped deadlines; changing budgets alter design scope in mid-step; even changing attitudes and the constant banging of the burn-rate drum begin to introduce arbitrary design constraints (such as emotions) into an already messy process."

Again, Jon has identified a real challenge, but I disagree that it is a necessary part of consulting. At Cooper, our process works through the consensus building process in a methodical way, starting with a presentation of business stakeholder and user research findings, along with models of workflows and personas who represent user patterns. Using this information, we describe an ideal "user experience" and gain early consensus on what problem we're solving, who it's for and what is important about the solution. We then create a small set of high-level sketches that tell a story and illustrate an ideal user experience. I have seen these sketches have an almost magical effect on an organization. Business stakeholders can see how the solution could work, and start to believe in it. Technical stakeholders can see how they could build the solution, and start to believe in it. We can predict how much effort it will take to get to this level before we start a project. Once we're at this level, we can pretty precisely scope the effort it will take to get the design to the level sufficient to start building it.

"This world of design-in-business isn't "bad;" it's just fundamentally different than the thing called Design that is taught in academia. Design decisions by their very definition aren't logical—they are imbued with preference—and if we are to prepare students for the realities of the business of design, the methods we teach in school should be broadened to include the facilitation and communication skills necessary to substantiate, persuade and illustrate the contextual relevance of a particular solution to a particular problem. Put a different way, designers today spend a great deal more time defining, illustrating, and selling their design solutions than actually designing. Our educational system needs to adapt, and realize that, in business, a slick Powerpoint deck is just as important as a slick Alias rendering."

I strongly agree with Jon's conclusion, but for a different reason. In addition to user research and design skills, IxDesigners must also excel at communication, facilitation and consensus building to help the entire project team understand what we are doing, and why.