Metaphors for non-dinosaur designers
March 20, 2017 7:30 PM   Subscribe

I need help coming up with alternatives to a metaphor that no one understands -- specifically, how to teach engineers about the values of an iterative design process.

I am a computer science professor, and I often teach students about human-computer interaction and the user-centered design process. One of the concepts that I find many of my students struggle with is the notion of designing things iteratively, and, specifically in the context of HCI, how to iteratively develop and refine an interactive prototype.

My students do know about the waterfall software development model vs. iterative models, but don't always follow it. In talking through this problem with a grad student, I came upon a metaphor for what the process should look like: that of progressive vs. non-progressive JPEGs on the early internet. In the former case, the overall structure of the system is laid out in a very rough form, and the details are filled in as time and bandwidth allow. In the latter case, the full picture does not appear until the very last moment.

I like this metaphor because it clearly lays out the tradeoffs between these two approaches to doing work, but in a context outside of design -- the benefits of the iterative approach are clear to anyone who is familiar with the concepts. However, none of my undergraduate or graduate students are old enough to remember when the internet was slow, so the point is somewhat lost.

So, I'm looking for other ways to convey the benefits of coming up with a very rough version of a project, and progressively filling in the details, that would make sense to students who have never lived without ubiquitous broadband. Ideally these examples would make sense to someone with a range of life experiences (mise-en-place may not mean very much to an undergrad who lives in the dorm and never cooks for themselves), and ideally there would be examples outside of design and artistic practice -- the process I'm describing is very similar to how animation is made (sketches -> storyboards -> animatics -> animation), but the students I work with don't tend to see themselves as creative types and thus don't always empathize with these approaches. I would love to hear ideas about how to represent these kinds of processes to people who are not necessarily familiar with or interested in creative work outside of class.
posted by neither here nor there to Education (22 answers total) 10 users marked this as a favorite
 
Athena came fully formed from Zeus's forehead, but everyone else is born as a baby and grows into adulthood.
posted by aniola at 7:36 PM on March 20 [3 favorites]


fwiw, Instagram still caches low-res versions of photos and blurs the heck out of them; this is mostly noticeable when you disappear into a subway tunnel, and when you emerge, the full image appears.

How about moving into a dorm? Some people might have been Pinteresting their dorm room since the junior year of high school, have everything ordered from Bed Bath and Beyond, and have sketches of where everything will go. Those are the waterfallers, and if the office of residential life accidentally gave them the wrong blueprint before term and their actual room has a pillar in it, everything falls apart.

Others have no planning whatsoever about their dorm room decor; they just brought a coffee maker, microwave, fridge, and some bedding, and will pick things up from flea markets as the term progresses. There is danger of stagnating at an undecorated stage, but you're robust w.r.t. getting a different room than the one you thought you were going to get, at least, and you'll have more things from where your college is located, not a time capsule of home.

I realize this is from the perspective of a girl whose parents were pretty laissez faire. If your parent(s) planned things for you, then I have no idea where that falls.
posted by batter_my_heart at 8:13 PM on March 20 [3 favorites]


Are you familiar with the graphic that shows the development of a car? Here's a blog entry that explains it. It's focused on product development, but there seem to be parallels.
posted by chesty_a_arthur at 8:23 PM on March 20 [3 favorites]


Well, this overlaps a little with art/design, but it's also very pragmatic: The Gents Tailored trousers course - Exercise 5 part 1 - Cutting the toile. See also Shirt Sewing - Test Fitting on the Muslin. It's not 100% the same, because in the end the toile/muslin is a prototype rather than something that's edited into the final product, but it's an iterative design process--it's possible to wind up making several of them if it's really important to get the fit right.
posted by Wobbuffet at 8:30 PM on March 20


Oh, there's also How Buildings Learn, which has less to do with what the designer thought and more to do with how what they created needed to evolve to meet the users' needs.
posted by Wobbuffet at 8:39 PM on March 20


Here's one example: Lug-nut driven development.
posted by suedehead at 8:41 PM on March 20 [1 favorite]


How about drafting an outline of a term paper before filling in the body of the text? A careful writer would review the structure and coherence of the outline before digging into the meat of the work.

UX designers call their early work "skeletons" for a reason.
posted by JoeZydeco at 9:09 PM on March 20


As long as you don't use the car drawings referenced above, which ignores the fact that bringing a product to market has its own set of challenges; making a car in 4 steps may be a much quicker way to get a car than starting with a skateboard.

I say that not because the originator of the drawing misunderstands software development; I loved the drawing when I first saw it. The issue is that I've seen people misunderstand what minimum means in a minimum viable product. Examples like this tend to get an imaginative mind bogged down in the weeds of reality.

Personally, when I'm trying to teach this concept, I don't use examples like the jpeg loading you reference, since the counter argument (why would anyone want most of the image, waiting for the whole thing reduces confusion) is so readily available. I give them a scenario where time to market is key; every day you wait to deploy is money gone, and every requirement you leave undone is audience (and money) gone. The student is responsible for a concept, but they're judged on how well they reduce that to an MVP. It's what it sounds like you do, just smaller to target the iterative concept.

I'm no professor, of course. Just a product manager.
posted by Pacrand at 9:30 PM on March 20 [4 favorites]


Taking a holiday? The waterfall approach is like a package tour that lays out every meal and event for the entire trip in advance. I think people planning their own holidays tend to take a more iterative approach. From a vague concept "Europe for a week or so in July" to a more narrowed down scope, "Madrid and Barcelona for 9 nights". Then more detail; the flights and hotel firm up specific dates and places. The next pass puts in more details - booking tickets for popular attractions, roughing out a daily schedule - "Wednesday in the old town". Finally, the rest of the details are added as you do it - exactly where and when you go and what you do.
posted by Homeboy Trouble at 9:33 PM on March 20


I like the skateboard to car analogy because it focuses on solving the "I need transportation" problem. I'm in agile UX design. Your MVP (iterative product) has wheels and gets the customer where they need to go.

From the car article referenced above: "...focus on the underlying need the customer wants fulfilled. Turns out that his underlying need is “I need to get from A to B faster”, and Car is just one possible solution..."
posted by ImproviseOrDie at 9:51 PM on March 20 [1 favorite]


One of the classic-to-the-point-of-cliche examples is when you look at a building with nice paved walkways leading up to the the beautiful looking main entrance, and you also see all these paths worn into the grass where people actually walk that the designers didn't pave.

So some architects pave nothing, then three months after the building has been open look where the grass is worn out and design the exterior paths then.
posted by mark k at 10:32 PM on March 20


Another idea:

cat toys

You buy the CatGizmo 3000 (waterfall); they prefer the grocery bag (iterative).
posted by batter_my_heart at 12:44 AM on March 21


Reading The Design of Everyday Things could give you some wonderful examples! Some absolutely hilarious stuff that shows the need for iterative design and trial and error processes.
posted by yueliang at 1:20 AM on March 21 [1 favorite]


Moving into a new place might be a good example, since these are students:

Iterative is acknowledging that you might not get your room set up just right the first time, or that even if you do, unforeseen circumstances might change how you want it set up after you start living in it. If your room is small, you might move the laundry basket into the closet to save floor space even though you've never done that before, or you might push your bed closer to the window because it's winter and direct sunlight helps you wake up. You trial the first version of your living space and then change stuff that bothers you iteratively. Even if you don't end up moving any major furniture around, you probably rearrange the stuff inside it as time goes on in order to make the user (you) happier.

Waterfall would be like meticulously plotting out where everything you own is going to go in your new room before you move in, then putting everything according to spec and never revisiting the end product after it's all been implemented. Or worse, setting up one section at a time and then realizing you can't fit your desk in your room with the layout you picked ahead of time, but also can't move anything you've already set up.
posted by Snacks at 3:01 AM on March 21 [2 favorites]


I was just studying iterative vs. prescriptive solutions design a month ago.

Our main assignment was to put together a design for a theoretical sporting amateur organisation. The approach I took was to look at all the identified requirements and "wishes" for the final system, to prioritize them in terms of what the organization would get the most benefit out of, and then break it up into several workable (2-3 week) chunks. For example the orgazination identified that they wanted to be able to accept club payments online as their top priority, so my iterations ended up looking something like this :

ITERATION 1
Online payment received from clubs
Online addition of new members to clubs
Web-based new member sign up to clubs

ITERATION 2
Regatta management
Equipment scheduling

ITERATION 3
Web-based merchandising sales
Ad-hoc event planning
Social media integration

etc. That way the organization gets it's much needed club payment system within 2 or 3 weeks, rather than having to wait months for the whole system to be delivered. That may be no different to what you're tried to explain them to them, but I thought I'd throw out a way of looking at it that worked for me.
posted by Diag at 4:26 AM on March 21


The Mona Lisa metaphor is pretty popular in the Agile software development world.
posted by neushoorn at 4:44 AM on March 21


coming up with a very rough version of a project, and progressively filling in the details

What about mapping apps, like google maps? When you turn on navigation at the start of your trip, it shows a high level overview of your path, with very few details filled in. As you get closer and closer to your destination, the view of your map zooms in closer and closer, until it gives you distances to your destination in feet.
posted by SuperSquirrel at 5:30 AM on March 21


I like the idea of comparing the execution of these projects to navigation. If you are planning a long journey (by land or by sea) at the beginning, it is not mission critical that you know the precise destination or that you have a super precise set of directions to get there. More often than not, you start with "what is the best/fastest/most-convenient way to go [arbitrary cardinal direction]?" It is only after the execution of these more crude steps that any specific knowledge of the precise destination is needed.

Using the sea navigation metaphor is particularly apropos. On a long trip, you may only use navigational equipment once or twice a day and course-adjust accordingly...

Generally, the key element of the metaphor that garners agile adoption is the intentional use (or ignorance) of all that is learned along the way. Waterfall (or any completely pre-planned methodology) limits your ability to use/leverage/implement anything that is learned in the course of execution... Why would you ever stop learning? Particularly as the new information becomes more and more relevant to the exact nature of the destination?
posted by milqman at 5:37 AM on March 21


... all that is learned along the way. Waterfall (or any completely pre-planned methodology) limits your ability to use/leverage/implement anything that is learned in the course of execution... Why would you ever stop learning? Particularly as the new information becomes more and more relevant to the exact nature of the destination?

Exemplified when the gps app "recalculates" after you make a wrong turn, or take a different route to avoid a traffic incident, etc.
posted by SuperSquirrel at 6:21 AM on March 21


The best I can do is supply some buzz words from the past:

Fast prototyping
Build one to throw away.
Writing is re-writing.

On navigation, my uncle was a teacher, and the thought that celestial navigation was a great tool for teaching the scientific method. You start with a hypotheses (your current position), collect data (the sun or star sights), and update your knowledge of your position based on evidence. (I'm not sure this works with the GPS generation which instantaneously gets a position within a few feet compared to celestial which gets a position within a few miles a couple times a day.)

Yacht designers talk about the "design spiral" illustrated here. There are so many interconnected parts that you cannot design the first part perfectly until you have worked out the other parts. So you work around (clockwise) taking a stab at each part. When you get to the top, you start around again, working at a higher level of precision.
posted by SemiSalt at 6:45 AM on March 21


Thinking of things that might be relevant to your young engineer students, maybe you could compare it to how chemistry is taught in school. I remember being an engineering student and feeling like a lot of our chemistry/physics concepts were introduced iteratively, with successively complicated models being introduced, and learning repeatedly that each one was just an approximation that's incomplete or incorrect in some way that can be experimentally proven, followed by the introduction of a more elaborate theory which fit the data better. I bet it's stuff that your students have been learning in their other classes.

The Bohr model is a relatively primitive model of the hydrogen atom [...] may be considered to be an obsolete scientific theory. However, because of its simplicity, and its correct results for selected systems[...], the Bohr model is still commonly taught to introduce students to quantum mechanics or energy level diagrams before moving on to the more accurate, but more complex, valence shell atom.
posted by beandip at 2:12 PM on March 21


Is software development too obvious? Everyone seems to be talking about Agile software development, where as soon as one component of a product is developed, it's put out there for testing by the users and iterations are done with their input. This is as opposed to more traditional software development where you make a Business Requirements Doc and the software folks go sequester themselves away for a while until a final product is reused and then tested. This can lead to wasted time if there are misunderstandings about the requirements at an early stage of the development process.
posted by peacheater at 1:53 AM on March 22 [1 favorite]


« Older Tropical privacy hedge tips?   |   Baby steps toward sharing my craft with others Newer »

You are not logged in, either login or create an account to post comments