Tom Chi  

Technical Limitations

August 26th, 2005 by Tom Chi :: see related comic

Being a designer is a great job because ostensibly you are paid to dream. You can spend half the day coming up with inventive, powerful, world-changing ideas, and package them into great design. Now the other half of the day… that’s where things are a little more complicated. Technical limitations abound — there are so many to consider that it’s easy to forget that technology is about making things *possible*.

This week let’s talk about some of the limitations we’ve faced in design work, and the ways we’ve worked through them or how we’d design differently if we could make them disappear…

10 Responses to “Technical Limitations”
daniel wrote:

For some designers, unlimited technological possiblities would mean the end of their career. If, for instance, a hifi-system could produce the exact same music as was (equally perfectly) recorded, without any loss of quality, what would be the point of designing a different one? A boring example would be a tyre. If it always had perfect grip on the road, no friction and never wore down, there’d be no use for anything else.
For usability experts, however, there’s always a challenge, since a human is going to interact with the product. And humans have limits, even when the technology does not.

Wait.. come to think of it, with unlimited techonology, the product would know what you wanted, do it for you, and there’d be no need for interaction. Either that, or technology to increase motor skills, reflexes, memory and whatnot in the user would render usability concerns pointless. Usability would become a question of using the user… scary.

I like technological limits - they’re the reason you design.

Rob Goris wrote:

The biggest problem a designer has to face, is - in my opinion - not the technical limits but the time to market in software development and the delivery date in client engagements. Finding the right solution in a limited time(resources, money) is what we are hired for. Frustrating at times, yes, but with unlimited time and money everybody will find the near-perfect solution. However, I think senior management in most IT-services companies could focus more on limiting scope and increasing quality rather than satisfying as much requirements as possible in order to generate more project revenue. Customers are part of this problem as well; a purely feature-driven project approach does not always pay off for them either.

Curt Sampson wrote:

Interesting comment about resource limits. For me, as a developer, the most frustrating thing is watching someone insist on using X instead of Y, when it’s three times as expensive to develop and very little different. Not understanding the costs, a lot of customers simply can’t do a cost benefit analysis, and thus won’t trade off expensive things for cheaper ones that are almost as good, and use the extra resources to better benefit.

Ron Zeno wrote:

Time is by far the easiest thing to measure in a project, and so should always be viewed with skepticism whenever it is used as a primary reason for any decision. Incompetence loves a schedule ;)

In response to Rob’s, “with unlimited time and money everybody will find the near-perfect solution,” I can only say: Absolute rubbish!

To be effective, designers must understand technical limits (and face it: most don’t or they’d be working much better jobs making much better money) or work extremely closely with those who do. The final design, the one that gets produced, is a result of tradeoffs due to technology, resources, and time. If a designer cannot be helpful in making those tradeoffs, then someone else is doing the designing.

Robby Slaughter wrote:

I more often find the problem to be programmers defining arbitrary technical limitations based on their perspective, not designers bumping up against actual techincal limitations because they don’t know what is and is not possible.

That’s because engineers are trained to think in terms of what they know, which is all the gritty details behind-the-scenese. We want to know how it will be normalized into a relational database schema, or if it can be peristed it by serializing it over XML. This is all well and good, but it’s the exact opposite of driving the development process based on the user experience. Users don’t care how your system works—they care about how they can work your system.

Most designers, though, don’t seem to know this either. They get excited about chamfers and color choices and sharp, clean lines. But they do have one thing in common with the more technical types: have them watch users struggle with something they created, and they usually won’t budge.

I think that *cultural limitation* is much bigger than any technical limitations we encounter.

Steve wrote:

Time is a technical limitation!

With unlimited time/budget any technical limitation can be solved. You can always throw more resources at a project to accomplish the impossible if you have the resources available. But in most cases we do not have this as an option, therefore we have to resolve these issues through design process.

As a designer the job is to be able to juggle the constraints (time / budget / technology) to develop a solution that is most appropriate to our client and most importantly to the end-user.

Personally, I thrive when there are a few limitations. Any good design can utilize the limitations to develop an innovative solution to the problem, in a manner that is true to the product, and true to the user.

Eric wrote:

The tech-side challenge I most often face is not so much the technology itself.

Instead, it’s the programmers’ focus on what is either a) the easiest way or b) the most interesting way for them to accomplish a goal.

That focus does influence their technology decisions.

Don’t get me wrong: They don’t mean any harm.

But too often they expect everyone to focus on the back-end technology rather than what customers intend to accomplish via that technology and when they need to do it (i.e., the reason the site exists).

I stress the importance on - IF it’s what it takes - making it harder for us in order to make it easier for the customers.

That doesn’t always make me popular with the programmers.

But no one actually wants to be the one to stand up and say that the programmers’ needs are more important than the customers’ needs (although they wish someone would).

They do tend to find customers and business deadlines to be uninteresting and highly inconvenient.

Tricia wrote:

I’d love to read this article but after “This week let’s talk about some of the limitations we’ve faced in design work, and the ways we’ve worked through them or how we’d design differently if we could make them disappear…”, only the comments from readers display.

Kevin Cheng wrote:


Sometimes, we just open it up for discussion so that IS the article actually. Tom was just opening the floor to comments. If you want something more meaty, I finally got around to posting an article on the subject this week.

Nah wrote:

The comic was funny, but if the issues you showed are the kind of thing you mean then that is part of your problem.

If you have told the developer first off that, for example, you wanted to use a “dropdown” (second panel) then she would have done the “event model” differently. Having said that, she should probably have designed a bit more flexibility in. Where she would have got the budget from to do that is another issue.

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) ?