Goal Directed Design Process

December 13, 2012 3:25 AM

Alan Cooper and the Goal Directed Design Process The heart of the problem, he concludes, is that the people responsible for developing software products don’t know precisely what constitutes a good product. It follows that they also do not know what processes lead to a good product. In short, they are operating by trial and error, with outcomes like customer satisfaction achieved by little more than blind luck. By Hugh Dubberly, first published AIGA GAIN Journal, 2001
posted by infini (28 comments total)

In short, the waterfall method plus pairing.
posted by 3.2.3 at 3:41 AM on December 13, 2012 [1 favorite]

Heavy up front design rarely survive the customer. Decent description of the problem, very dubious of the practically of his solution.
posted by KaizenSoze at 4:19 AM on December 13, 2012

Rapid iteration is the key.

1) Build the simplest thing that will solve 80% of the remaining problem.
2) Try it.
3) If not satisfied, goto 1.

This, combined with a willingness to tear out a subsystem and rework it from scratch (which usually takes less time in the long run) will solve all your problems. Well, the technical ones. If you have political problems with managers, you are screwed.
posted by DU at 4:29 AM on December 13, 2012 [4 favorites]

You can view Alan speaking at a conference I threw this year here and here (other videos here); his talk is great.
posted by jkolko at 4:39 AM on December 13, 2012 [1 favorite]

Decent description of the problem, very dubious of the practically of his solution.
posted by KaizenSoze

What areas seem to be the sticking point in the practicality of his solution?
posted by infini at 4:45 AM on December 13, 2012

Heavy up front design rarely survive the customer. Decent description of the problem, very dubious of the practically of his solution.

Depends on who your customer is, which is related to your business model. If you design and build software in a professional services context, then you may well be absolutely right. But if you design and build software within a product company, then your customer may be a market, or a market segment (which I've also seen referred to, cutely, as a markette), and their involvement in the approval process may not come until after the product has been released (ahem).

This applies even more starkly when the product combines hardware with embedded software, like an MP3 player, a phone, a digital camera or a GPS receiver - in these contexts, it is both crucial to get the software design absolutely right, and it's also reasonable to expend considerable design effort to interview potential and actual end-users, create personas and then design to those personas.

I worked for IBM/Tivoli for several years as a product manager, and during that time, IBM (well, Tivoli, anyway) adopted Cooper's Interaction Design methodology pretty whole-heartedly. The biggest problem we found with it was one of scalability - the method allows you to design software that works much more intuitively, that people are more effective with, and which also looks great, but it can take considerable time to design a "screen" - it can be very process-heavy. If your product has, say, 5 or 10 screens of information, that's probably do-able. 100 screens and you're in trouble. A 1000 screens? Yeeah. You're going to have to find a different way.
posted by kcds at 4:58 AM on December 13, 2012 [2 favorites]

What areas seem to be the sticking point in the practicality of his solution?

Fundamentally, there are two schools of thought in software development. One is collect requirements, design, code. This is called "waterfall". The other is code while collecting requirements and designing. This is "agile". Waterfall tends to be a long process, and people often completely fuck up the requirements phase. Agile tends to be fast, but you end up with a mosh mash of code and features, and the design often is rough because it was done on the fly, if at all.

Agile fanatics talk about Functional Requirements, which can be defined as "This must do task X to Y" and Non-functional requirements, which can't be defined that way - things like stability, performance, UI design, etc.

The problem with Waterfall is that it is slow and collecting requirements is hard. The problem with Agile is that Agile programmers cannot hear the word "Functional", which means there are requirements and non-requirements. You know, like stability, performance, consistent UI.

What this guy is saying to me is "get good designers who can collect requirements well. Architect a solid design, then code in rapid iterations."

He's also saying that your designers need to be different than your coders, and have the authority to enforce the design. Agile's design as you go means the design can be violated at will by the coder, because they are doing both.

In my career in operations and sysadmin, I've found rule.

Competent programmers are rare. They write good software in both methodologies. Bad coder write crap in both. But Agile gives you half-done code fast, so it seems faster.
posted by eriko at 5:01 AM on December 13, 2012 [9 favorites]

...with outcomes like customer satisfaction achieved by little more than blind luck.

I dunno. In the years I spent working in a software company, I saw a whole lot of outright condescension and dismissal toward the customer and UX on the part of the developers. If customer satisfaction was achieved, it was despite the developers, rather than devs stumbling across it by luck.
posted by Thorzdad at 5:21 AM on December 13, 2012

What areas seem to be the sticking point in the practicality of his solution?

The article seems to make the case that because software is so easier to make minor changes to, there's a tendency for software to build up a lot of cruft through seemingly harmless features which eventually makes the software over-complicated and difficult to use. The solution seems to be to do as much designing as possible before any of the code is written, which I don't think really helps that much. The fact that software is easy to change means that it's always going to change, and you have to plan around that. So you can't count on getting the design absolutely right to begin with, you have to come up with a good enough design to start with and make sure that when you inevitably make changes, you make them in ways that follow good design decisions. If minor changes have a tendency to ruin software, the focus should be on making minor changes that don't ruin the software, rather than pretending that the minor changes won't happen.

He's also saying that your designers need to be different than your coders, and have the authority to enforce the design. Agile's design as you go means the design can be violated at will by the coder, because they are doing both.

One thing that makes the article a little confusing is that Cooper's concept of "design" is more related to visual or user experience design, whereas the concept of "design" in an Agile software methodology is usually about software design/architecture. For example when writing server software with Agile there would be practically no design in terms of what Cooper is talking about except for things like configuration, whereas on a software design level there would be a lot of decisions like whether to use async or threading models.
posted by burnmp3s at 5:25 AM on December 13, 2012 [1 favorite]

I can't be the only person that misread this as "Alice Cooper and the Goal Directed Design Process".

I was looking forward to finally understanding the heuristics behind "Lace and Whiskey".
posted by ryanshepard at 5:25 AM on December 13, 2012 [6 favorites]

My interest was also piqued by Alice Cooper, but no.

A sticking point could be the role of a design communicator, who seems to get the short stick on all of the fun parts of the design work. Also when you put a programmer with some interest in design in a position where he doesn't have any power over design, you get a very unhappy programmer.

These role-giving theories are like trying to argue which kind of band composition with what responsibilities is best for a successful rock band. Easy to build theories that look sensible, but difficult to follow with real people.
posted by Free word order! at 5:28 AM on December 13, 2012

A sticking point could be the role of a design communicator, who seems to get the short stick on all of the fun parts of the design work. Also when you put a programmer with some interest in design in a position where he doesn't have any power over design, you get a very unhappy programmer.

Having worked as an account executive in an advertising agency with exactly this paired model of Creative + Accounts, I have two observations.

Yes, creatives (makers) are always unhappy and part of the job is managing their happiness in order to find a balance between what they want and what the client (user?) wants.

Two, the team talks and brainstorms together, its rarely so dictatorial IRL, so perhaps that's our read of the "process" in writing rather than our observation of the actual "process"?

I'd also like to ask in which category of development do purely consumer facing solutions like social networks fall into?
posted by infini at 5:39 AM on December 13, 2012 [1 favorite]

Suppose there actually ISN't anything better than trial and error. Is that so bad?
posted by thelonius at 5:48 AM on December 13, 2012 [2 favorites]

This article is 11 years old. So calling it "the waterfall method plus pairing" is a fairly close description.

Also, it's dated March 1, 2001, and reproduces an already-published article. The term "Agile Software Development" had only been coined a couple of weeks earlier but the approach grew out of a number of methodologies including extreme programming. Since then, UI/UX design has become a job title in its own right.

What I find so surprising is that people here are talking about the same problems now as they were then. Solutions remain incomplete and theoretical. Disclaimer: I write and design software for designers as my day job. But still.
posted by tel3path at 5:55 AM on December 13, 2012 [2 favorites]

If you have political problems with managers, you are screwed.

"If?"
posted by gorbichov at 5:58 AM on December 13, 2012 [2 favorites]

What I find so surprising is that people here are talking about the same problems now as they were then.

Actually, people are still talking about the same problems from nearly 40 years ago.

Isn't there some old proverb about anyone who thinks they have a solution not understanding the problem?
posted by normy at 6:36 AM on December 13, 2012 [1 favorite]

The biggest problem with anybody claiming they have the found a good way to develop software, totally lack of studies. Sample size is a problem, good academic research is practically non-existent.

Look up Greg Wilson, he has been for several years trying to run studies on software engineering.

Here's a website where he and other talk about the current state of software development research.
Never Work In Theory
posted by KaizenSoze at 6:48 AM on December 13, 2012 [2 favorites]

User Experience (UX) as its own discipline and owned by real people who have it as a job title is the best thing to happen to software, pretty much ever. It's not purely visual chrome and it's not the "but what kind of plugin architecture allows adequate performance while sandboxing" system architecture, but it's the job that asks the boring but crucial question "how and where does a user touch this software?" and "what do they need to accomplish?"

I've been the developer asked to do that work at the same time as architecting the system - sometimes it works, often it doesn't. When it doesn't work, it's not because you don't want it to, it's just intense work to occupy both an architectural headspace ("I expect parts X and Y will be most volatile, so need to abstract those; I need to enable undo so I'll need a command pattern with transactions... uh oh, that's complicated things on our non-transacting back-end, I wonder how much we need undo...?") with the user's very elephant-shaped headspace ("What is this thing for? How do I connect it to my things? What if I screw something up - how do I go back?" all the way to "I know exactly what I want get out of my way, and woe betide you if I can't find a conf file to edit.").

Frankly, the most successful development I've done (or managed) has happened when you start with the end result you're expecting. ("In order to X I need a report that shows me A, B and C." and "As an administrator, I need a config file to have these options, expressed thusly in JSON, located at this path because that's the easiest and most familiar way to get me started." or "As a new user, I want to upload my content right away because I wouldn't be here if I didn't have content to upload.") This is good design because it gives you a set of things that, once you have done them (or 80% of them, as someone above mentioned), you're "done" and can throw users at it. If you do that every week or month, call it agile. If you do that every quarter, half or year, you're probably waterfallish but can still succeed *if you know when you're done*.

Of course, it won't solve everyone's problem. And it will annoy some folks. But you might also finish in non-geological time and have a chance to refine it.

I'll harp on design though. There should be two words. "presign" and "design" - "presign" is when you apply your taste and sensibilities and invent something you think ought to work. Maybe it's new and interesting and breaks your paradigm and offers critical insight and what-not. Or at least that's what you intend for it to do. It's your hypothesis.

"Design", however, is what happens you your presign meets your audience and you refine it down to what succeeds and throw out what fails. A design is your experiment that tests your hypothesis.

I'd love to replace this exchange:

"Will the system X?"
"Yes! The system is *designed* to X."
"So, if I A and B, I'll get X?"
"No! Well, maybe. You'll need to Xify A and Xify B and then probably X."
"So it doesn't X."
"No it was designed to X, not to X. You just have to Xify to get X."
[Someone gets assaulted.]

With the magical notion of "presign", this conversation can go like this:
"Will the system X?"
"The system was *presigned* to X..."
"So if I A and B, I'll get X?"
"Hm, sounds like I need to re-presign. You want A and B to get you X?"
[Work happens]
"Okay! Here's a presign where A and B gets you X."
"Cool. [A] okay... [B]... okay. Ah, there's X. Hm, I sure would like it if I could just C and get X."
"Fair enough, but right now A and B get you X, right?"
"Yes."
"You can work with this, solve more problems today than you could yesterday using this, right?"
"Yep. I can use this today. But I'd really like to C..."
"Awesome. I want to get you to where you can C. I'm going to find some more folks who need A and B to get X and make sure you all get some value out of this. Maybe they'll want C too, but if this makes your life a little easier today, we'll roll with it for now right?"
"Totally. A's... B's... X! Woo!"
"Great, [sends email] This system is designed to take A and B and get X. Let me know how it works for you."
posted by abulafa at 7:11 AM on December 13, 2012 [5 favorites]

About Face, an Alan Cooper book that came out in 1995 was one of the things that made me realize I wasn't a bad software guy. There was a place for me.

It's been updated... but the original one, and Code Complete definitely made me feel OK about the career in front of me in the mid 90s

Those jerks!
posted by DigDoug at 8:08 AM on December 13, 2012

It really seems like not much is known about the software design process, and what abulafa describes is pretty typical of the communication issues that software developers experience.

The problem seems to be not only that software developers usually have no training in design whether that be architecture or user experience, but that nobody involved actually has any understanding of the design process at all. When you say "presign" is "when you apply your taste and sensibilities and invent something you think ought to work", that sounds like "rapid prototyping" to me as a software developer. From a design point of view it sounds like you go straight through divergence into the convergence phase and start doing more convergence ("refine it down to what succeeds"), and you don't involve anyone else in the decisions until you've taken the design well into the convergence phase.

This is fair enough, I guess, if you want to set the limits and hold the frame. The customer might be entitled to their opinion about A, B, C, and X, but they can't introduce the topic of P, Q, R, and Y because you've already framed the design issues as A, B, C, and X by going this far on your own. Often in software, that's the only feasible way to go because the customer can't even picture what they want until they have a version of it.
posted by tel3path at 8:15 AM on December 13, 2012 [2 favorites]

I can't be the only person that misread this as "Alice Cooper and the Goal Directed Design Process".

*waves hand*
posted by dlugoczaj at 8:23 AM on December 13, 2012

I think we're in violent agreement @tel3path, in that there's often a hard limit on what software can do in the first place - time and space, physics, that kind of thing. So if the project is "a website to manage my stamp collection", it helps to start from some basic assumption common to all "websites" and "management tools". Then if there are specific innovations or quirks about the domain of "stamps" you can really focus on those.

For example, if a stamp collector user says "I want to walk up to the screen and it knows who I am without remembering a password or anything" that sounds great and all but if you want to ever get to the stamp collecting part, (re)inventing the authentication, authorization and identity management experience may not be the best use of your time. Constraining the user to focus on their domain of expertise, and even further on what they waste time doing or are frustrated by, usually helps focus the discussion on solvable, delightful steps rather than the perfect system (which is so often the enemy of the good (-enough) refinement.

Of course, sometimes it's very important to step all the way back and ask questions to identify what the user actually needs (and will use/pay for). Maybe it's not a website, maybe it's an app. Maybe it's an assistant. Maybe it's a service where someone comes to your house and organizes your stamp collection. Assuming software is the only path to serve the user can also be an issue - to the chagrin of some but success of others, that's where stuff like marketing, product management and other kinds of business and design folks can help a lot.
posted by abulafa at 8:30 AM on December 13, 2012 [1 favorite]

Heavy up front design rarely survive the customer.

This is an article of faith in the Agile world, and its an assertion built on anecdotes and legends, not actual study of how design works. In industrial design, architecture, landscaping, graphic design, film, urban design, etc., heavy up front design very much does survive the customer.

No one says that you can't design a building up front, you can only build a minimum viable building as cheaply as possible, move some people in so you can get feedback so you can iterate on it. That would be ridiculous, expensive, and extremely irritating for the people who are living in the building, but in software, it's the gold standard.

The problems that Agile tries to address are really caused by a design process dominated by MBAs, salespeople and managers, people with no design expertise. To the extent that they have "designers", it is usually self-taught web designers who make things look nice, but who don't have any contact with the design traditions, and even if they did, they have almost no power and couldn't apply those skills.

Because Agile puts design into the hands of software developers, who also don't have any connection with design, it will also fail. But this problem has already been solved. Just take advantage of a huge body of knowledge that has been accumulated in other design disciplines, and hire people who have been immersed in that knowledge to design your product.
posted by AlsoMike at 11:21 AM on December 13, 2012 [2 favorites]

"That would be ridiculous, expensive, and extremely irritating for the people who are living in the building, but in software, it's the gold standard."

It's unfeasible to build physical objects by rapid prototyping. It is feasible to build software in this way, and usually the best choice. We know what a building looks like, so it's a lot easier to specify. Unless you're creating the same type of software over and over again, the desired product might be so nebulous that it's easier to show them a rapid prototype and go from there.

I've heard coders say that requirements gathering is ridiculous because "customers don't know what they want". It's absolutely true that they don't know what they want, but that's why requirements gathering is necessary. See also "requirements change therefore it's impossible to specify them". Rapid prototyping, Agile, or other forms of iterative development should never be an excuse for crap engineering practice.

But yes, it would help software development a whole fuck of a lot if anybody knew anything at all about design thinking. And if MBAs, salespeople and managers went off somewhere to eat paste or whatever it is they do.
posted by tel3path at 11:39 AM on December 13, 2012 [1 favorite]

That would be ridiculous, expensive, and extremely irritating for the people who are living in the building, but in software, it's the gold standard.

Imagine a world where you can drop by your local Home Depot and drop a grand or two on a Construct-o-Bot 5000™ capable of running up a finished 40-story building in five or ten minutes. In such a world, architecture would be a very different process. Every architecture firm would have a lot out back for setting up prototypes. You'd drop by the office, talk about what you wanted, and they'd bang something up on the spot. You'd go walk through it, talk about what you like and don't like, they'd take notes, and then they'd go revise the blueprints. A week later they'd call you back, they'd set the construct-o-bot to work, and you'd go tour the latest version of the building.

Ok, so you like the lobby, but the elevators are sort of awkwardly placed, they should be rotated 90 degrees, there should be a little hallway there and an extra set of restrooms on the ground floor, oh and could you change the curve on those tall windows, hmm, also I guess we need a couple extra floors up top. You go home, they rework the blueprints, a couple of days later they call you back for another tour. How do you like it now?

The halls are empty but they are fully carpeted. There are power outlets in the walls, the lamps are all installed and lit up, the elevators work, the plumbing works, the offices are furnished. Okay, looking good, but how about you make this floor two feet taller, and we could use a loading dock out back now.

No problem, the architects say - we'll just demolish the building, rework the blueprints again, and rebuild it - see you tomorrow!

This is every day life in the world of software construction. I get tired of people who expect software design to work in as slow, tedious, conservative, and plodding a fashion as building design, because they mistake the process of laying out the blueprints for the process of constructing the building. Software is different: building software is free, it's only thinking it up that takes work.
posted by Mars Saxman at 12:06 PM on December 13, 2012 [1 favorite]

I still have a few copies of the AIGA Gain Journal on the shelf. I never got the one with this article so thanks for sharing it. That publication actually holds up very well.
posted by quadog at 1:31 PM on December 13, 2012

Imagine a world where you can...

No need to imagine anything, we already live in a world where designers prototype designs. This is a standard part of practically every design discipline and has been for decades, if not centuries. It's a new thing for software developers, and isn't very mature or well understood by them. Here are two really big things missing from Agile prototyping.

First is the concept of fidelity. Developers insist on maximum fidelity, believing that everything has to be working in code and in production to get useful feedback. At best, an interface prototype can be completed in one 2-3 week sprints, maybe longer. A designer working in low fidelity prototypes can do the same thing in an afternoon on paper, and simulate enough of the experience to find the major issues and repeat it the next day. In comparison, Agile development is extremely slow because they go for 100% fidelity.

Second is the concept of divergent thinking. Agile developers have a highly linear process, where they code up one idea and get feedback on it, then get feedback and evolve the design in the next sprint. Designers typically work with multiple simultaneous ideas, approaching the problem from several different angles at once. After exploring the problem space, they converge on a design that worked the best, incorporating feedback from all the other approaches. In one two week period, I tried 6 different basic approaches to a single design, and created many iterations of each. I ended up with more than 40 different designs, and of those we picked the 3 best to usability test. In that space of time, a developer could have created 1 design.

Even at breakneck pace, software developers can never iterate as quickly or as thoroughly over a problem space as designers prototyping. Even Agile, which claims to be all about speed, is extremely slow, conservative and linear in comparison.
posted by AlsoMike at 2:34 PM on December 13, 2012 [4 favorites]

I can't relate anything you describe to the world I live in, AlsoMike. The "construct-o-bot" is nothing imaginary, just a simple metaphorical description of a programming language compiler, and the story I told is nothing more than a description of everyday life as a software developer, transposed into buildings. This is what I do all day: write some code, build it, run it, test it, debug it, write more code, build it, repeat. It is a constant process of trying things out and inching steadily toward better understanding of the problem, where one's understanding is expressed in code.

You seem to have a very specific formula for what "Agile development" means, and I'm sure there must be people who act in the strange way you describe, but the idea that the idea of rapid prototype iteration is "a new thing for software developers" sounds so blatantly absurd to my ears that I'm certain there is some fundamental misunderstanding going on here.
posted by Mars Saxman at 3:58 PM on December 13, 2012