This paper was written as Hugh Dubberly's explanation of Alan Cooper and Alan Cooper's Goal Directed Design Process. It receives a Gaming Imperatrix Thumbs Up.
Style and Contents
This paper was written in an instructive/explanatory/educational format. It was smooth reading even though it contained a great deal of useful insights, and was generally a pleasurable paper to read. The paper is structured with a page of introductory material.
It introduces the reader to Alan Cooper, who he is, what he cares about, what his goals are, what is background was, and what his driving forces were, which let's the reader get a good sense of where the paper is going to go.
After this, it highlights in bold the five steps of his goal-directed design process. In each section, it writes in italics the old methodology, that this bold step replaces. Then it explains the reasoning for the approach in plain text.
After this phase, he goes into a further study of the goal-directed design process, homing in on useful details. For example, the Designer + Design Communicator core that Alan Cooper advocated building teams around, the evolution of the design process and the necessity of putting design before programming, the different dimensions of design, an input/output table for the software development process concerning persons on the team, and then a final overview of Goal Directed Design and a methodology for how to build a successful product by using GDD. The paper is covered in graphics, tables, and charts, all of which are fairly easy to synthesize.
Interesting Observations
I liked this paper, and learned a bunch of interesting little tidbits from it. Although I knew that software development had gone from lone-wolf programmers up to an elaborate design process, I hadn't thought of it in discrete steps before, or realized that the step we are currently unseating (or have just recently unseated) was a phase of doing design and code work at the same time.
I noted with interest that Alan cooper (or Hugh Dubberly, I'm not sure which) considered Art and Design to be more-or-less the same thing! This was a useful insight for me, because I am interested in being a game designer, not a game artist. In the movie industry, movies usually always have distinct producer, director, art, and technical roles. In an analogy, I want to be the director for a video game. I've been coming to the realization over the years that this role is still working to manifest itself clearly in the industry. One would hardly think of shooting a movie without a director, but for some reason it seems okay to build a game without one? Nonsense!
I have also been listening to how gaming companies are structured, and have noticed that the role of director/designer frequently gets mistaken for or folded in to other roles. Sometimes it is the lead programmer, other times it is the 'Creative Lead.' Now I understand why anyone would fold 'Designer' into 'Creative Lead,' as there is a theoretical precedent for it!
Hugh explains- and I think his phrasing/Alan's idea is superb- that there is a conflict of interest between Programmers and Designers. Programmers want something to be easy to program, and Designers want it to be easy to use. If you use that means of thinking, then obviously there must also be a conflict of interest between Designers and Artists. But the conflict of interest is deeper than just how much work a person has to do.
A Programmer has a conflict of interest with a Designer because the Programmer wants something to have good, functional code that he/she is proud of. He wants to show off his programming. His programming becomes his center of focus, instead of design. Likewise, the artist's art becomes the center of focus for them, instead of design. Design- the composition of all of the game's various interrelated elements, from the data gathered by market researchers for use in HCI, to programming, to art, to user requirements, to producer requirements- that composition job is a job all in its own, and should be kept free from any other job that might try to claim it.
I love the idea of pairing a Designer- or really any job- with a dedicated communicator. Usually the people who have technical skills are not necessarily the best communicators!
I enjoyed looking at how the individual rules on the software development process interrelate based on the input/output chart, but some of my favorite graphics were about Cooper's People/Technology/Buisness model. At my old school, Architecture and Design were of course grouped together, and our Games students presented their final projects with Archtiecture students.
I agree that they share many attributes- although I feel Architecture is more closely related to Level Design and Installation Art than to Game Design as a whole. In the end, Architecture is about designing spaces, and the usability of spaces; but Game Design also requires Interior Decorators to make the art, Physicists to make gravity work, and a Director to make sure they're all working on the same project.
I also like how the paper compared Cooper's specific software-design model to the original model and derivations thereof. He showed us the abstract version (Desirability/Capability/Visibility) with its abstract-y words next to a more functional and applicable version, to show how the abstract version could be instanced into a functional model. Cooper's explanation of Apple, Microsoft, and Novell using this system extended its ease-of-use even further.
All in all a pleasurable read. A+
No comments:
Post a Comment