Lessons from design education

I met someone today at InfoCamp who got her college degree in “design management.” This essentially means coordinating overarching design projects that include a team of specialists working in a variety of mediums or products — such as brands that span websites, retail packaging, advertising, etc. (Apparently, in the US, this specialty is only offered at the Art Institute in Portland and at RISD.)

Carina said that virtually every project assigned in every design class she took was a real project for real clients. Companies, nonprofits, or government entities who needed something designed. This is in stark contrast to most class projects in most other disciplines, where imaginary problems are created with imaginary stakeholders, and the project team just consists of one or more students in the class.

Is it any wonder that software engineers are blissfully unaware of the needs of real users, when their only deliverables in school were to TAs who graded the correctness and efficiency of their program code?

I’ve already heard Bill Buxton talk about how class projects should at least include students from different disciplines, since that is the type of team that can make the biggest impact in the real world and people in such a team need to be able to communicate across the disciplinary boundaries. I’ve also read about the socially relevant computing initiative which seeks to make computer science projects more obviously related to real-life problems.

But design education goes all the way, by involving students at almost all levels in real projects. Actual projects! That actually need getting done! That come with all of the organizational politics and communication challenges of the real world.

Is there something special about the design discipline that makes this approach work? Or is the approach just as feasible in computer science, too?

As a high school student with no formal computer science training, I created an entire content management system with three interconnected data types (pages, vocabulary terms, and bibliography citations) and specialized back-end management interfaces for each type. Surely, there are real projects of this level of complexity or less that a first-year computer science student (or group of students) could complete. This clearly does not constitute “innovative computer science research.” But it does solve real problems with current technology, and it introduces students to the realities of working with users and stakeholders other than oneself.

An ongoing conversation thread among designers and consultants is that it is up to them not just to design but first to resolve the organizational problems (“corporate underpants“) of siloed teams lacking clear goals and effective communication. This seems to me primarily a failure of education.

Why would we expect people to know how to communicate with diverse stakeholders, if they never learned to do so? (The same reasoning goes for other emotional intelligence skills such as conflict resolution and leadership.)

If these skills are as widely needed as they appear to be, we should start teaching them at the earliest levels of school. The responsibility surely shouldn’t rest only on college-educated designers.

Computers calculate really fast

When I teach computer science to fifth graders, the main concept I want them to remember is that computers work by doing calculations incredibly, insanely, mind-bogglingly fast. To get across the idea of just how fast they work, I tell a story which I thought I’d share here, too.

Let’s start by doing a few arithmetic problems.

3 + 7 = ?

5 + 12 = ?

420394 + 59382 = ?

How long did it take to solve those? The fastest you could conceivably calculate them (especially with big numbers) is about 1 per second. Now take a modern computer, such as the one sitting in front of you. How many of these can it calculate in just one second?

The answer is (roughly) a billion. One gigaherz means “a billion times per second.” In other words, a standard modern computer can answer a billion arithmetic problems, every second.

But just how big is a billion? That number is so large that it’s hard to comprehend. My favorite way to understand it involves paper. Suppose you had a billion sheets of paper, all in a stack (the normal way they’re stacked when you buy paper or put it in a printer). How tall would that stack be, if it had one billion (incredibly thin) pieces of paper?

Of course it depends a little on the thickness of the paper, but the answer is about 100 kilometers, or 60 miles high! Mt. Everest is less than 6 miles high, so let’s turn that stack of paper on its side and lay it along a freeway. To drive past every piece of paper in that stack at 60 mph would still take you a full hour! Reams and reams, paper after paper after paper.

So it would take you an hour just to drive past all those sheets of paper at freeway speeds, yet a computer does that many sheets worth of calculations every second! After many years of programming, I still find this astonishing. That is an incredible amount of power at your fingertips.

Consultants ask “Why?”

I’m re-reading David Allen’s Getting Things Done book and realizing that many of his ideas about productivity are in common with the design processes and observations of user experience professionals.

In particular, David’s section on “natural planning” emphasizes the trajectory:1. purpose and principles2. outcome vision3. brainstorming4. organizing5. next actions

Points 2-4 correspond fairly well with, say, Bill Buxton’s emphasis on prototyping (“outcome vision”) and the expand-then-narrow design process (“brainstorming” then “organizing”).

And David’s discussion of point 1 (“purpose and principles”) immediately reminded me of Tamara Adlin’s musings on “corporate underpants.” She has been a usability consultant for various companies, and observed that bad user experience often stems directly from confusion and baggage in the ranks of the management. David and Tamara both point out that the primary advantage of hiring a consultant is not special skills or experience but simply the fact that they come from outside the company and can therefore ask the “dumb” question: “why?” Since external consultants have no previous knowledge of the company, they are allowed to ask questions that probe deeply at the organization’s core goals and principles — questions that executives and VPs would never ask because they are too scared to admit they don’t already know. Tamara always claims that by far her biggest contributions as a user experience consultant have nothing to do with usability methods per se, but simply asking “dumb” questions over and over until the various stakeholders finally get on the same page and actually start “pulling in the same direction” as each other.

If you work in an organization, try to ask those deeper questions if the answers are not already clear. Why are we doing this? What is our goal here and what are our values? What will the outcome look like and why is that what we want? My experience has been that people are much more likely to thank me for clarifying the issues than dismissing the question as “dumb.”

Health insurance is a solved problem

The current health care debate is reminding me how upset I am that most Americans don’t understand Economics. Paul Krugman, the master of economics journalism, explains it well. There is no debate. There are some types of goods for which markets work well, and others for which markets don’t work well. The simple fact is, health insurance is one of those goods that is most efficiently provided as a government monopoly. Just like defense or public parks. This is not controversial among economists.

Yet somehow politicians get away with meaningless arguments like “we need competitive markets.”

It seems incredibly dumb to spend so much time arguing about a solved problem. Especially when there are millions of people with sub-par health care that have to continue to wait for progress.

Improbable


I suppose that given a big enough forest, eventually one tree is bound to fall so precisely against another tree that it stays…

(I took this photo on Orcas Island, WA)

OmniGraphSketcher 1.0

When I first noticed, almost seven years ago, that there was no good software for sketching Economics graphs, I never imagined that this small observation would grow into such a major project. After several independent studies, conference papers, a masters thesis, and an acquisition, today my little project has reached a new milestone: the official release of OmniGraphSketcher 1.0.

This software application has always proven somewhat tricky to describe. I think this is partly because it is the first product of its kind, and partly because the word “graph” has such a wide range of meanings. I completely reframed the description at least five or ten times while writing my masters thesis. But my new favorite summary is by Omni’s documentation and UI master, Bill:

OmniGraphSketcher is a quick, straightforward tool for creating graphs, whether you have specific data to visualize or you just have a concept to explicate. And it doesn’t assume that you have gobs of free time and attention to learn how to use it.

You can find out more about OmniGraphSketcher in Linda’s entertaining Omni blog post and on the official product page.

As for me, I want to acknowledge again all the friends, mentors, usability testers, beta testers, and users who have continued to give feedback, find bugs, and suggest further improvements. The software would never have come this far if they had not repeatedly convinced me that it was actually useful.

So thank you, and enjoy OmniGraphSketcher! It’s a different kind of graphing program. I know there are many possibilities for expanding its functionality, and I look forward to exploring them. Even after seven years, this is version 1.0 – just the beginning.