As a front-end developer who works most of the time with predefined design files handed off to me by a designer, I am often faced with the task of explaining what can effectively translate from Photoshop to the web. This is by no means an easy task, as the nuances of web are ever increasing, and gaining an intuition for these possibilities is equally growing in difficulty.
The Importance of Empowering Designers and Developers
I believe it is important to lay this on the table for all managers, engineers, and others who are worried with the implementation side of creativity: It is time to let designers build impossible things. It's time we push our designers outside of the boxes (and box models) we've built for them, and here's why.
1. The Right Kind of Boundaries
Creativity thrives inside the right kinds of boundaries; in particular, creativity thrives inside conceptual boundaries that implicitly shape the creative artifact.
"We are targeting individuals who enjoy independent films and live in suburban areas" is a very different set of constraints than "we can use only four large background images on any given page".
While the first will shape the message and the impact of the creative artifact, the second shapes the artifact itself. If we are working with good designers, the implicit boundaries (rather than the explicit boundaries) will provide direction rather than hindrance to the creative process.
2. Web Innovation is Driven by Creative Realization of Necessity
The web of today is very different than the web of one month ago, much less the web of the early 2000s. A primary force behind this rapid change is the fact that evolution of web technology is driven by competition to meet developer and user needs.
What this means in practice is simple: developers and users alike are constantly giving input to the teams behind the development of browser layout and rendering engines. The primary players in this arena are WebKit (Chrome, Safari, and now Opera), Gecko (Firefox), and Trident (IE). The first two engines are open-source, so different variants of these find their way to the browsers we use every day. Microsoft's Trident is closed-source. Traditionally, the open-source engines have seen faster turnaround of feature implementation and more flexibility with experimental features, and as these features become standardized, they make their way into IE.
Feature standardization is implemented by way of a "spec", and that spec is often created based on community feedback and iteration. In fact, you can be a part of the groups that standardize these features by participating in the W3C (World-Wide Web Consortium) mailing lists. By allowing designers to dream up things that are currently impossible with web browser technology, we will realize unmet needs in the browser of today, and push innovation forward for tomorrow. Those mailing lists are community accessible, and things like box shadows and Geolocation APIs are born in these threads. Without community feedback and the need for new, impossible things, the web would still be full of animated GIFs and marquees. Yikes.
3. Use Creativity To Build, then Find Boundaries to Adapt
The point of well designed web artifacts is not simply to portray the built-in capabilities of the web browser, but instead to sufficiently convey a message and incite an action. Why, then, should the outset of a project be limited by something that is irrelevant to the message or desired user action? Instead, allow creativity and design best practices to define the "best case scenario" – if anything was possible, what would be best? After this has been defined, the engineer who is taking the artifact from creative exploration to a usable interface can reduce the impossible or less practical features, and adapt the best case scenario to the best possible scenario.
This may stretch the limits of the front-end development process, and it may not be a "natural" development process. However, this method allows the message to reign supreme over the process, and creative exploration to help dictate more than naturally dull functionality.
Balance
Of course, like any other practice, it is necessary to practice balance. If all features of a given web artifact are designed outside of the realm of possibility, reduction to something plausible for the web would be a nightmare for an engineer. The art of design is, in the end, the balance of communication through possible means in novel and effective ways.
To create an environment where possibilities are communicated at the right time in the creative process, follow these simple guidelines.
Combine Quick Iterations with Effective Communications
Designers should always work in iterations, practicing open communication with the developer that will work on that project. The developer's job is to ask questions in order to understand the designer's plan, and answer questions regarding feasability. It should be stressed to the developer that a hard job is not an impossible job, and that unknown attributes are not infeasible attributes.
What this means in practice is that developers should remain optimistic about making the seemingly impossible things possible, and refrain from placing restriction on the designer's ideas in every iteration. However, they should also be able to provide useful feedback to designers about difficulty and feasibility when it is known. Take the following examples, for instance:
Joe Designer:
"I'd like to create an interface that dynamically removes the background from a user profile image and replaces it with a dinosaur. This will let our users have dino-ified avatars! And it would be awesome."
Bob Developer:
Joe, you are right. It would be awesome. Of course this is a "possibility", but the difficulty of doing such a thing is probably somewhat high; is it worth the investment to create a dino-ifier, or could we let them add dinos next to their picture (which accomplishes a similar goal, with much less effort)?
This is an example of collaboration at work, and it points out our next topic.
Effort / Gain
Balancing "effort required" with "potential gains" is an important task, often left up to higher ups in corporations. However, in a fast-paced high-iteration environment, this kind of decision-making has to happen much more often than can be delegated upwards. Accomplishing the same goal with a parallel solution that carries less investment is a dynamic but important nuance that every developer and designer should take into consideration when working on a project.
For this to be possible, designers and developers must be empowered to make decisions, and the values of the project must be communicated all the way to the bottom for those decisions to be made well and in full confidence. In other words, for Bob Developer to know that the dino background isn't worth the development investment, he has to have gained an intuition for the values embedded in the project. Similarly, Joe Designer should be able to understand that value immediately as well.
Open Vertical and Horizontal Communication
With the previous knowledge in hand, we can gather that open communication should be a standard, throughout all levels of any given project. If the designer has a question or needs clarification of a component of the underlying message of an artifact, they should have access to the resources necessary to answer that question.
Conclusion
Designers should have the freedom and power to make wildly innovative decisions, and developers should have the power to drive adaption on projects. Cultivating a culture of creativity-first empowerment and adaptive innovation will ultimately yield more intuitive teams that build more effective web artifacts.