Kevin Cheng  

Why Technology Matters but Shouldn’t

November 12th, 2004 by Kevin Cheng :: see related comic

In Bill Watterson’s _Calvin and Hobbes_, Calvin often fantasized about becoming Tracer Bullet, the private investigator, whenever he was confronted with a particularly nasty problem (the really tough ones went to Spaceman Spiff).

As HCI practitioners, we’re frequently confronted with situations where Tracer Bullet could probably be of some assistance. In the ideal case, HCI proposes interactions independent of technological limitations but today, you’re either Tracer Bullet, with the technical background to backup your interface ideas, or you’re just regular 6yr old Calvin, with no say in what happens.##Technology Matters
Technology matters because we can’t build anything and everything we can imagine. Interfaces like [Minority Report](http://www.ok-cancel.com/archives/week_2003_10_03.html “Minority Users”) may seem appealing but, aside from being impractical, are technically or monetarily infeasible. What matters then, is knowing when it’s actually not feasible and when it just seems that way or put another way, whether the programmer is being inflexible.

This may seem contrary to what I’ve said [before](http://www.ok-cancel.com/archives/post/2004/10/type_mismatch_hci_and_programmer_communication_barriers.html “Type Mismatch: HCI and Programmer Communication Barriers”) about being both programmer and designer:

> I have found myself limiting my design choices based on what I knew to be technically feasible. … While pragmatism has its place, such an approach is akin to shooting yourself in the foot before starting the race.

I still stand by that statement. When I know the inner workings of a program because I’m also the developer, I often limit my design choices before truly considering them. An example recently occurred with my [new blog](http://www.kurioso.com “Kurioso and Kurioso”). My girlfriend suggested that I move the two sets of stripes which surround the design down a bit to match the spacing of the header photograph. I knew it was actually a page background graphic and thus, “couldn’t be done” and such was my instinctive reaction, “it can’t be done.” Of course it can.

##Technology Shouldn’t Matter
In a digital utopia, we’d be able to build any interfaces we can imagine. Such a utopia doesn’t exist nor will it. We may reach a point where technological limitations are negligible but even that isn’t in the near horizon.

Designing an interface shouldn’t be about technology. When the iPod Click Wheel was designed, the discussions were likely to be more along the lines of, “this is what we want, how can we make it work?” instead of, “this is what is possible.”

When IDEO designed a Prada changing room that captures and shows what you look like from behind, they probably weren’t thinking about what was possible, but what was desired.

Technology limits our thinking. Taking tried and true design implementations holds us back. If you’re an HCI practitioner with a technical background or a programmer working with HCI, you need to actively fight the instinct to say:

“We can’t do that.”

and instead ask:

“How can we do that?”

8 Responses to “Why Technology Matters but Shouldn’t”
Julian wrote:

This is one of the issues I have with saying you can’t be both a programmer and a designer. I very much am and find myself filling both roles.

The key difference is what you touch on at the end of this article. My design class right now is very much pie-in-the-sky detached from reality–but every now and then we start talking about how something could actually be implemented. The designers just don’t have the technical background I have and I find that they usually say “We can’t do that” more often than I do!

I think that you /can/ separate yourself from what is technically feasible and then bring yourself back to ask “How can we do that?” later–it’s just hard.

If you can manage it, though, I think every group needs someone who has technical and design knowledge. They are the ones who can figure out how to best make use of technology to implement the design in ways which capture the essence of the design.

Bob Salmon wrote:

You forgot Stupendous Man. Dun dun daahhh! (Sorry)

Dave wrote:

The question that isn’t being asked is why shouldn’t I think about limitations? And WHEN shouldn’t I think about limitations?

The why was sorta answered, but I think at too high a level. At the low level, what is important is that ideas are outted, no matter how sublime or ridiculous. You just have to let them out. The reason why you have to let them out is because the brain is a fabulous entity. It has this way of connecting things, creating patterns, and juxtaposing things that at first rationally seem completely disonent.

The design process itself strives on this power of the brain. The ideation process needs to happen with as wide a birth as possible, so that discovery can happen. Putting out a ton of seemingly unrelated ideas in a team collaborative environment is how you lead to innovation the quickest. The associations created can be turned into patterns that then can be mapped into a more pragmatic world later on in the process, when after ideation, evaluation begins.

What I have been trying to tell everyone in my life is that EVERY idea has a morsel of goodness in it. We just need to create the environment where that goodness gets juxtapose to another associated goodness and voila a pattern is created that can be applied toward innovation.

If you start out thinking about the solution first, the limitations, you miss these opportunities.

Damn! Kevin, I keep giving you the good content. ;)

lane becker wrote:

In my experience, the biggest problem most people (and by extension, most companies) have is they still think the Internet has something to do with computers. It doesn’t. It runs on computers, but, really, what doesn’t these days? My toothbrush is powered by a computer, and I wouldn’t say that technological constraints were much of a factor there. But when it comes to the Internet, because we can see the machine, we are ruled by it.

And then we buy elaborate technological solutions — cmses, crm systems, portal “solutions” — that fail because they’re bad answers to the wrong problem. The problem has nothing to do with technology. The problem, like soylent green, is people. And it requires a people-centric solution.

A corollary to this: I can’t say for certain where in an organization the “Web team” should be located — I think the answer to this is more nuanced than the structures of most companies currently allow — but what I can say is, the one place the Web team shouldn’t end up is the IT department. That’s a deal-killer.

Ron Zeno wrote:

Technology matters because it’s an inherent part of the medium. To be a good designer you must know the medium you work with. To be able to competently answer the question, “How can we do that?” you must be a master of the medium.

I’m with Dave: Good designers know WHEN to not think about limitations.

solouk wrote:

I’ve spent many years learning how to “think out of the box”.

When it come to HCI I’ve found it necessary to understand the technology - not because I think I should be a developer to be a good designer, but because I need to understand what a developer is telling me when we engage in the design solution discussions (or argument!).

There are often valid reasons why a developer might object to something in my designs, but more often than not there is little substance to the objection. I’ve lost count of the number of times I have been told that “We can’t do that because that means we will have to change the patterns . . . “.

We all have to work with developers. We should all know by now the strengths and weaknesses of a developer (read Cooper’s ‘The Inmates are running the Asylum’). There are a growing number of developers who openly support the skills that I bring to the table, but there are still many developers who still work within their comfort zone and have a blinkered view.

A technique I often employ is to fake ignorance. The developer then spends an extended period of time explaining their argument, which, with a little bit of prompting from me, usually ends up with them coming round to my point of view without them actually realising it!

Solouk

noah wrote:

I think of the original moon missions — it didn’t matter that we didn’t have all the technology on hand, it was enough that we had the vision and patience to see it through.

It’s pretty much what Dave pointed out: you have to shoot for the stars first, and only then find the ways to make it happen.

Plus, lots of patience and money helps.

Jeff wrote:

The flip side to this is that just because something can be done, doesn’t mean it should be. In my experience designing, the developers are often the ones to propose design ideas because they utilize new or interesting technologies, or provide more options to the user, or allow for a convoluted but “efficient” way of performing tasks, etc.

Sometimes knowing too much about the technology causes us to adopt a stance in which we think that if something can be done, and it might be useful to someone, and it hasn’t been done before, then we should do it. Sometimes, in other words, the design needs to be a constraint on the technology.


Leave a Reply


OK/Cancel is a comic strip collaboration co-written and co-illustrated by Kevin Cheng and Tom Chi. Our subject matter focuses on interfaces, good and bad and the people behind the industry of building interfaces - usability specialists, interaction designers, human-computer interaction (HCI) experts, industrial designers, etc. (Who Links Here) ?