Kevin Cheng  

An Approach To Optimal Design Within Technical Constraints

August 30th, 2005 by Kevin Cheng :: see related comic

> “I don’t remember being forced to accept compromises, but I’ve willingly accepted constraints.” - Charles Eames

As a designer, I’m a member of a product team. While a great part of a designer’s role is to do its name sake - _design_ - there’s a significant part that’s in the follow through. Following through means not just throwing a design over the wall to development and then throwing a tantrum when it comes out all wrong. Following through is working with the technical team to see that vision come to fruition. The challenge lies in coming up with the best design within the constraints set out.

I’ve observed (and practiced) a number of design processes which were less than optimal. In some cases, the designer has sufficient technological knowledge that they cripple themselves (I think I called it [shooting ourselves in the foot][9]) with the their own perceived constraints. Other times, the designer may set out with a fairly idealistic design, but the end product gets nowhere close to that vision.

So after a few hard lessons, I’ve come up with a personal approach which seems to have worked better. I think one of the keys is the initial design. When I first approach a problem, I design as though technological constraints did not exist _within reason_. What’s within reason? That’s a judgement call. As [one commenter pointed out][10], without technological constraints, the user could just think what they want, and the system would do it. That’s not very realistic though. I say it’s a judgement call for what is within reason because it depends on the device we’re designing for.

Basically the idea is to stretch the boundaries that are perceived to be there. What if those weren’t there? What if we could drag and drop on the web? What if we could retrieve data without refreshing the page? All of these are now possible but were probably perceived as not so just a year ago.

![Setting the Optimal UX Bar][1]

So this design acts as a high bar. The ideal goal we’d like to get to if time and technology constraints were at a minimum. Once I have this design, I also mentally set a “low bar”. The low bar isn’t so much based on specific design elements as it is on the user research data and requirements. What is the absolute minimum interaction functionality I think is needed for a passable experience?

![Setting the Optimal Low Bar][2]

At the same time, development has probably set a feature minimum. This is the _functional_ minimum, usability be damned.

![Development Feature Minimum][3]

While not consciously set, there’s some technological barrier based on the time constraints of the project. Let’s call that the Development Maximum.

![Development Technical Barrier][4]

As the project progresses, I present the optimal design to the team and begin to pare it down as necessary. At the same time, development is working their way through the feature set and hopefully, also moving towards the vision that was laid out.

![Development Approaches UX][5]

As the development line crosses the UX Minimum, we’ve reached a state where the product _could_ be launched if push came to shove. The goal however, is to coincide the launch date with the point where the UX and Development line meet.

![Launch Ready][6]

This process may seem really trivial and obvious but it’s surprising how many people don’t practise it. If a designer begins their design with their own constraints in mind, even given more flexibility with time, we’ll never hit maximum potential.

![Starting Too Low][7]

If the designer doesn’t understand the reasons for the technical limitations let out and is unable to have a discussion around potential workarounds, we could get a process that looks more like this:

![Not Understanding the Language][8]

The advantage of this process is that it ensures I start out my design with an optimal picture in mind. Equally important is that I consciously think about what the minimum user requirements are for a usable product experience. The final part of the process - the negotiation - requires more practice, training and education on both the design and technical members. In the end though, by setting out these starting points and internal process, we can go move from compromising to accepting constraints.

[1]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_01.gif
[2]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_02.gif
[3]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_03.gif
[4]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_04.gif
[5]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_05.gif
[6]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_06.gif
[7]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_07.gif
[8]:http://www.ok-cancel.com/uploads/20050830_technical_constraints_08.gif
[10]:http://www.ok-cancel.com/archives/article/2005/08/technical-limitations.html#comment-2543
[9]:http://www.ok-cancel.com/archives/article/2004/11/why-technology-matters-but-shouldnt.html “Why Technology Matters but Shouldn’t”

5 Responses to “An Approach To Optimal Design Within Technical Constraints”
David Weiss wrote:

This was the best summary of the challenges inherent in program management and design that I have ever seen. Well done! I couldn’t agree more about starting with the ideal first and then actually articulating the UX minimum. That’s so important, because you’ll almost never hit the ideal, but you need to know when you can “be okay with” the progress and know that you are dealing constructively with the constraints. Frankly, I believe this is why is some ways, having a technical designer is helpful, as long as they don’t let their technical knowledge limit their ideal.

ezuk wrote:

Great summary.

Just one small question: What’s UX?

Kevin Cheng wrote:

ezuk: UX is the rather cryptic acronym sometimes used for User eXperience. I don’t know how it came to be that. Some organizations I know use the more straightforward UED - User Experience Design so maybe I should just call it UE instead. Wish we could at least agree on that industry wide!

Dan wrote:

Why not start with the minimum and collaborate with all team members to build a better design?

Perhaps I’m misunderstanding the article, but it seems like this approach has some scary implications:

By starting with the “optimal” and going through a process of compromise, the approach sets the team up for a competitive dynamic, which can be ineffective and inefficient. It also forces the designer to think of his or her work modularly — that it’s easy enough to swap stuff out. Feature changes, however, can have a ripple effect throughout the design.

Alternate approaches suggest starting with the minimum — identifying what will get the job done — and adding discriminately. It’s easier to add things in than take things out.

Am I missing something?

Kevin Cheng wrote:

Great questions. First, I suppose I should always say YMMV. This process stems from the teams I’ve worked with and I’m sure there are team dynamics where it’s less effective.

There are several reasons I choose to start with the optimal and move down rather than start from the minimum. First, if the minimum is presented, developers may start architecting their solutions around this design and inadvertedly paint us into a technological corner that was avoidable. Of course that applies more to new products - legacy systems are bound to rear their ugly heads but why not constrain the limitations to those instead of accidentally creating more?

Second, it establishes a goal towards which to move towards. I’m not saying the designer should just hole his/herself up in a room and then come out in a few weeks announcing a design. Discussions should certainly be carried out as the dseign process happens. What I’ve found is that having a goal of the “kickass” solution helps set the sights higher for the whole team a lot better than starting from “good enough”. I would actually say the adding is much harder than subtracting and implies more modular thinking.

With an optimal design, one has an idea of what the ideal kind of interaction is and work to get as close to that as possible. Going in the opposite direction, there’s no clear direction, and I could see myself just trying to improve parts of the interface, piece by piece, rather than designing holistically.

As for conflicts, that would depend on the team personality more than anything. Assuming that development did have input into the optimal design (having them come up with the design entirely as a team would be unrealistic and honestly a misapplicaiton of their talents), I’d hope that we as a team are striving to reach that optimal design.


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