Constraints are a creative catalyst.
I heard that quote so long ago that neither my memory (nor any search engines I used) could recall the original author. But I guess the important thing is the lesson it taught me; the constraints of a project should help inform what you can create.
As a developer, my constraints are generally the limitations of the platform or the dataset I’m working with. Identifying them provides me with foundation for what is and what is not possible to implement on a project and workarounds if any are possible. With this knowledge, I can work with the designer, UI/UX expert, and project manager to refine or change the scope of a project with what is feasible.
Can we use hover effects on a mobile browser? Sorry technically impossible but how about we use a tap event instead to bring up that menu?
Can we search by those attributes in the third party API we’re integrating with? Sorry they don’t support those fields but they support these fields and worst case, we can post process the results.
Can we make clickable elements on a mobile app that are 22 pixels by 22 pixels? Apple’s Human Interface Guidelines recommend a 44 pixels by 44 pixels as the minimum comfortable tap area.
As the developer on a project, you are often the subject matter expert for your development platform as well as the data and services you’re working with. It’s your responsibility to make sure the constraints you are aware of are understood by the team. The earlier the better. No one wants to be in the position of learning a design, functionality, etc. decision months ago will need to be scrapped.
Constraints are the catalyst to a successful execution.
Starting with a greenfield project, decide in a sentence what you want your product to do. Don’t get into the features with any depth. Just who, what, and why. I want to find help people find late night places to hang out and make friends.
Identify your audience. People would use my mobile application are primarily undergraduate college students.
Identify your platform and its constraints. My audience mostly owns iPod Touches. iPod Touches support the full iOS SDK but cannot guarantee a persistent WiFi connection nor fine grained GPS coordinates.
Is there an API or dataset available for our application. Yes, there is an API that costs $250 per year. We can use it with as many applications as we want. We can cache the data for 30 days after which it will need to be purged from the device.
We now have some good constraints to determine what we can build to implement our original idea:
- Our audience is primarily college students who own iPod Touches. We can expect they’ll be online at some points during the day using on-campus WiFi.
- iPod Touches give us a near iPhone experience but since we can’t guarantee a WiFi connection, we’ll need to design an offline mode.
- The terms of service for our allow us to cache their data. We can use the cached data to present a limited experience to the user in offline mode. We can show previous results but search won’t be an option; we should let the user know this in the interface by designing some iconography or notices.
- The API lets us search by latitude and longitude but it doesn’t filter by location type, we’ll need to do that on the iPod Touch.
- The API doesn’t tell us if the locations that sell food are vegetarian/vegan/gluten free. We won’t be able to implement that in our application even though our audience would be interested in it.
With constraints in place, there is still room for creativity. You’ll come up with clever workarounds to some of the limitations. You’ll still think up great features to execute your idea. You’ll still built great interfaces for the features you can implement. You can even bank the ideas for the features you can’t implement because with time the constraints may change.
Constraints lead to features. Features lead to a design. Design leads to execution. Constraints aren’t a bad thing, they’re a good thing.