Coding Transparency: Development from Design Comps

Since I am an engineer first and a designer second in my job, more often than not the designs you see came from someone else’s comp. Being that I am a designer second, it means that I know just enough about design to be dangerous but not enough to be really effective over the long run.

When I say I am a designer second I mean I am, in fact, a design school dropout. I went, I learned just enough to “get it” and then I ended up dropping out. I did go back to school and I got a math degree, but that is a different story for a different day.

If there is anything I learned from design school, it was that everything in design is done for a reason. Mind you, this is when design is at its best. Every designer that is working to solve a problem and communicate with the viewer has incorporated elements and done things so a specific message comes through.

Unfortunately, many of my engineer colleagues don’t have this insight. Typically people who opt for the engineering route do so when they are in high school or earlier and rarely set foot into the creative world. They may be proficient hobbyists in a particular art or craft, but their real love is engineering. Typically they really have little or no knowledge of design whatsoever.

People who don’t understand design make really poor designers.

Sorry, it’s true. This is not to say people without design skill can’t convey messages, but they tend to be inconsistent and unpredictable. Moreover, engineers, in specific, are typically more interested in solving a puzzle than making the final presentation precisely “so.”

This is the benefit of design comps. Designers, unlike engineers, are trained in design and are able to consistently and deftly communicate ideas with a clear voice. When they create a design comp for a website, or several depending on circumstances, they are creating a visual roadmap to communicate with the world.

Engineers, even as wonderfully detail oriented as they are, tend to see the big-picture items like color and location of items on a page, but they miss items which are equally important, like typography, subtle shading and other items which create a polished look that tells the user this is something made by professionals.

Ultimately, what happens is engineers color the design with their desire to finish slapping that UI together so they can solve the really meaty problems. When I joined Arrowhead, the company I currently work for, much of the Creative-specific projects looked pretty good, though the code was abominable. The collaborative work between Creative and Engineering seemed to suffer.

Mind you, this does not mean the engineers here are bad at what they do. Quite the contrary. They simply colored the output when they worked on it. Designs would fall apart as content was added and the best laid plans met the real world.

Engineers and developers need to work on being more coding-transparent. Regardless of how ugly the first iteration of the code might be, get the page looking good. When you think you’re done, take a printout of the original comp and hold it next to the completed page. Do the look the same? Do they look different? How do they differ?

In order to achieve coding transparency it is important to take a moment and understand what the designer is trying to communicate. See what the pieces of the design do when they work in concert. Understand the intention.

Ultimately, this may lead to asking the designer questions. They don’t mind answering questions like “what am I supposed to be doing here,” or “when I add content, the design seems to break like this, any thoughts?” Questions like these help designers to work with you and, hopefully, develop a more robust design, capable of handling what the world throws at it.

Designers, on the other hand, hate questions like “what is this for? Do you really need that?” The answer is typically “yes,” so don’t ask. Try to implement it and then ask questions if something breaks.

As you work through a design, you may find you have to interpolate or extrapolate on a designer’s idea. If it is clear how to build from what they have done, just go for it and brace yourself for minor tweaks. It’s okay, changes happen. If you don’t understand what they want or it’s not clear how the design extends to what you are currently working on, then stop and ask questions.

When engineers ask questions which lead to better design decisions, designers feel more confident about how the end product will turn out. Much like engineers feel when people ask questions about whether items are possible to implement rather than just assuming they are and promising the world.

In the end, coding transparency is all about communication. It is about communication between the designer and the engineer and it is about communication between the designer/engineer team and the user. If communication breaks down anywhere along the way, the message will never reach the user or worse, it does and it’s ugly.

In the end, everything we do is intended to reach an audience. The more we can do to facilitate the message as it comes down the wire, the better. So, the next time you receive a comp and rush through, slapping elements into place without review, imagine what your system would look like without testing and code review. Practice coding transparency and make the web a better place.

Comments are closed.