Constraining Design

There are good constraints and bad constraints when it comes to design. A good constraint is one that enables a designer to discover and realize a great design. This makes us ask what makes a design great--a design is great that facilitates the desired experience, one that harmoniously balances the concerns of all parties involved. Hopefully most of us involved in design these days take a more altruistic tack--helping others to get what they want and/or need in particular contexts. When it comes to software, it means usually balancing the trifecta of technology, users, and businesses.

Business constraints are not inherently bad. There is an "evil" business stereotype that seeks to extract the last bit of profit out of an endeavor by any means necessary. Greed is the overriding motivation. Now greed is clearly a core human failing, but it is just the twisting of the desire for good. The desire for good is a good thing; it motivates most of what we do. It only becomes bad by degrees as it is imbalanced, i.e., the desire for my own good driving me to the detraction of the good of others and/or seeking a good that is excessive or misplaced desire in relation to one's self.

In business, the desire for the good of the business can be a great driver for excellent work. It is not only the good of shareholders but also the good of every single employee and their significant others who are supported by the revenue from the business. This means that the business domain itself need not be altruistic for a business to be operating with good motives. Further, a business that provides real value to customers is a good, and its continuing ability to operate and provide that value (and increasing value) is also a good. Constraints that help us serve the good of the business can often be good. They also serve to define and, to some extent, circumscribe the problem domain, which gives focus and clarity for design work to proceed.

The good of users is the easiest good to perceive in design. UX folks idolize it, sometimes to the detriment and imbalance of other goods involved. For most software, good for the users is maximizing the value that they want to get out of the software. That can be entertainment value, information value, social value, efficiency value, and so on. Understanding the desires and needs of users and shaping our designs to maximize attainment is a basic thing for design. Constraints that help us serve the good of the users are, naturally, good. Users also constrain design, though we often don't think of it like that--they have ergonomic, psychological, and other such constraints that are good in as much as they keep us from wasting time on what human beings are capable of.

Sometimes these two goods are in opposition, but as many companies have discovered, there is usually more to be gained by seeking a path that maximizes the good of both. Companies that invest in what is best for their customers (really and truly) usually find that such investment has high ROI. Further, UX/customer experience increasingly is becoming a differentiator in the market.

And of course, there is the larger, common good that has to be considered. What impact does a design have on the shared good of the local community, the nation, the world? Environmental concerns are one example. Fair trade concerns. Other larger ethical concerns. And so on. These kinds of constraints are also good constraints, but often (for software) they are tangential. That's not to downplay them--just an observation that most software only impacts the common good very indirectly.

More often, balancing these goods is informed, when it comes to software, by technology concerns. At a high level, technology is a huge enabler--sort of by definition. In recent years this has accelerated with "high tech," and it appears that it will continue to do so. But technology is also a constraint. Technology is a good constraint when it helps discover and realize great designs.

That's still pretty broad. Let's scope it down. We can assume that technology as an enabler is a good thing, so the question is what other kinds of technology constraints are good versus bad in design. And what level of technology awareness/concern is appropriate and helpful at what points in the design process.

Feasibility Constraints
Is a particular design technologically feasible? This is the most basic technology constraint, and it is in itself a good one to be aware of through most of the design process. It is good, for instance, to know that mind reading and/or anticipating what a person wants before they indicate it somehow is not feasible. Some things are just plain not possible, at least for now. A designer should know about these and avoid them. Right?

Well.. when you are in the generative phase of solving a design problem, even infeasible ideas can be helpful. Infeasible ideas can generate proximate feasible ideas--they can help you push the boundaries and (dare I say) think outside the box. They can point you in a good direction, one you would not have explored had you flat out ignored them.

They literally, if you take the time to sketch them out, can force you to break through your own mental barriers and preconceptions about what "an appropriate" design might be. If you're exploring ideas, multiple alternatives, as is normally good for a healthy design process, these taken together with other more feasible alternatives can combine unexpectedly in ways you would never anticipate.

They can be aspirational and inspirational--you can use them to describe the overall feel you are looking for, and that can inspire team members to strive for that in all the little decisions they have to make.

So far we are just talking about flat out, well-known-to-be infeasible ideas. But unfeasibility is more typically a spectrum that is informed by two primary factors: time and skill (specifically, developer skill). Do your developers have the skill to implement the design? And even if so, do they have the time? (Time would include considerations such as importance/priority of the given design within a ship cycle.)

I would submit that:

1. Most designers can't reliably judge what their developers are capable of.
2. Even developers can at times misjudge their own abilities and/or just not know for sure without trying.
3. Most estimations are wrong, sometimes wildly.

Does this mean that we should just plow ahead with feasibility-challenged designs with no regard for these factors? Absolutely not. Here's what I think it means:

1. Designers should rarely attempt to pre-judge what is feasible or not. The one exception may be when they know it mimics what they have seen their team members produce already.
2. Sometimes it is okay--especially in the midst of the project/towards the end of a ship cycle--to just take an estimate at face value, but the earlier you are/more time you have to explore feasibility, the less you should let difficulty/feasibility re-orient your design efforts.
3. Developers need to be more affirmative and supportive of the design process and, when they don't immediately and certainly know if something is feasible and have some reasonable idea of the effort cost, they should make time to explore that with technical prototyping and feed the results back into the design process.

(All of the above apply more or less equally when the designer is also the developer.) A developer who complains that a design is not feasible indicates a broken process. If you have healthy communication and participation of devs in the design process, no design that comes out of that process should be infeasible. And by healthy, I mean supportively involved, doing technical prototyping where needed, and contributing ideas that help find a good balance between feasibility and best for users and business. I do not mean shooting down ideas that they don't like, being obdurate when their own design ideas are not chosen, or prematurely dismissing designs whose feasibility is uncertainly. ;)

Feasibility is an important constraint. It is good in as much as it can stop us from wasting too much time on dead ends and also, correspondingly, help us to focus on what is possible and expend our design energies within that space. But it can easily turn bad if we too quickly preclude design ideas that, in more cases than we know, could mean the ultimate success or failure of a project. It is better to assume that something is possible when designing than to assume it is not. Remember, even infeasible designs often suggest better, feasible solutions than what you'd come to without them.

Platform Awareness Constraints
Most software projects start out with at least some idea of what the platform and/or platforms they want to target is/are. So it just makes sense to immediately constrain your design ideas to fit within that platform, right?

An average developer would almost certainly answer yes to this. I mean, of course! Why waste time on designs that can't be implemented on the target platform! Right!?

Wrong. Well, it is wrong to degrees. This is also related to the feasibility question--just a bit more scoped and, therefore, a bit easier to be wrong about precluding divergent designs. Put more simply, all of the considerations above apply, plus the additional case to be made for exploring other platforms if one of them supports the optimal design you feel you have discovered. Great design should come before platform lock in, even though it often doesn't. :)

On a more practical level, there are two main concerns:

1. Being distracted by and fighting with platform/technology details. This is crucial. It's why coded prototyping is not as good as code-free prototyping. But even putting a UI over all the platform details only adds a level of indirection to the complexity. It is the proverbial lipstick on a pig. There is a time and place for everything, and when you're trying to discover the optimal interaction design for human beings, you should not be worrying about beating a platform into submission to express and test your design ideas. The appropriate place for those challenges is during implementation.
2. Being confined to built-in platform capabilities. If all you want to do is create a vanilla app that strictly follows built-in platform conventions, fine. But most of the time, you need to color outside the lines a bit to really nail a great design.

Where platform constraints are good are when they serve the greater story of a user's interactions within the platform as a whole. They are also a good baseline to start from in terms of framing the experience, and they can eliminate or at least simplify some interaction framework choices. And with that, they can be good by way of reducing the risk in getting an app approved for those platforms that have an approval process. Put simply, from a design language level, they are helpful, but less so from a practical technological level.

Constraints in Indigo Studio
This is our design philosophy with Indigo Studio--make it easier to design for target platforms without constraining you with all the technological details for that platform. Guide you to design on top of the design language, rather than becoming subject to it. Have as much of the feeling of sketching as possible while supporting you if you want to get more detailed/constrained.

Discussions about feasibility. Figuring out how to implement. All of that needs to happen, but at the implementation and/or technical prototyping phase, not in the initial interaction design exploration and testing.

You will see this philosophy come to life as we add specific platform packs. We have it today in our blend of built-in, interactive controls alongside our powerful shape tools and custom interactions-anywhere and animation support. We don't let you do everything, but we try to help you do the most common things and letting you color outside the lines. It is a balance, and we won't always get it right nor are we able to help with everything we want to help with, but it is we think the best approach for facilitating your efforts to discover the best designs for your business and your users.

About Indigo Studio

If you haven’t already, why not Go Design Something!? Version 1 is free forever.

If you are using Indigo, we welcome your ideas on how we can better apply and refine these and other good interaction design principles to help you to design awesome UIs. If you have any questions or problems, please don’t hesitate to discuss them with us in our forums. We’re also on Twitter @indigodesigned.

About the Author

Ambrose Little is principal design technologist at Infragistics and has worked on Indigo Studio as interaction designer and product manager along with an awesome team based here in Cranbury, NJ, USA and Montevideo, Uruguay.