A patron approaches a painter and asks her to invent a painting of a stone statue. The painter, never having sculpted, creates a beautiful composition of a towering monument. The painting is then taken to a mason, and the mason is asked to build the sculpture. Try as he might, the mason attempts to build the structure, but the proportions are wrong. The structure cannot hold its weight and it crumbles. “Perhaps if we add extra support here…” he suggests, but the changes ruin the aesthetic of the piece…
This is the way many modern websites were built. If you examine almost any traditional web design team, you’ll find a visual designer, an interaction designer, and perhaps a user experience expert. What you won’t find are developers, programmers, or systems architects.
Studying a great work of art is very different from creating one. How many hours do you think a painter works with paint to become a great painter? How long must a potter work with clay? How familiar must a sculptor be with a chisel and stone? Experience with the raw materials of the medium impacts an artist’s ability to create great works.
It’s about creating inspiration, not limitation.
Often, designers on such teams overlook the technical constraints and tools of their medium or fail to understand them altogether because they aren’t experienced with the raw materials. Some of these designers believe that understanding the constraints of a medium will “limit their creativity,” when in fact the opposite is true. By refusing to understand the constraints of the medium, we also refuse to understand its possibilities.
The raw materials of the web are not pixels, they are code. Mockups of websites built with tools like Sketch are merely imitations of what a website could be—they’re illusions. Without embracing their technical counterparts, designers limit themselves to what is achievable within design tools like Sketch—unknowingly forfeiting the full potential of modern web technologies. Our goal is to build intuitive interfaces that people can interact with effortlessly, not create nonfunctional counterfeits of websites.
Perhaps we reach for static mockups because they’re a relic of an earlier time when the web was simpler. Maybe we gravitate towards them because they’re easier to create and sell. Static comps require far less creative thinking because designers don’t have to consider interactivity, animation, functionality, or a dynamic range of screen sizes and devices.
Everyone is a user.
The reality is that “usability” isn’t something that only affects the end-user—it affects all users. Our clients also have expectations about how they will update and manage content. Unfortunately, not all clients have the technical expertise to understand what they’re agreeing to when approving static mockups. They might not understand if something will be easily editable or usable when looking at a non-interactive mockup.
Many companies exploit their client’s naivety with the visual impact of static mockups. Knowing that an edgy design is more interesting than functional specifications, they use static comps as a selling tool, but they omit the critical details that make a website successful. This approach leaves everyone disappointed. The client realizes they bought something very different from what they were imagining. The designers see their mockups disintegrate under the scrutiny of reality. The developers realize they’ve been tasked with building a product without adequate planning or preparation. Of course, the group that will suffer most are the visitors who will ultimately be using an inferior product.
Blending Design and Code
There are two solutions to this problem:
- Designers learn to code.
- Designers work alongside developers as an integrated team.
Learn to Code
At this point, the “designers should learn to code” battle has become blasé. Nevertheless, as someone who appreciates the intricacies of both design and development, I will share the following excerpt as the best argument I’ve seen for designers learning to code. (I encourage you to read the full article for more insight.)
To be a good UX designer requires a voracious intellectual curiosity, and learning about hundreds of things besides the tools and disciplines of UX. Psychology, leadership, communications, neurology, sociology, anthropology, art history, political science, human perception, systems science, brain development, branding, product lifecycles, chaos theory, programming, semantics, data analytics and visualisation, statistics, testing methodologies, data structures, marketing, finance, manufacturing, talent management, persuasion, color theory, ergonomics, aging, macro-economics, community management… And if you’re ambitious, also golf.
You’re on the side that needs to know more, because you work at a higher level, with more responsibility and more power than the developers. They get to say how it will be built, but you get to define what they will build. You’re the general, they’re the troops. If you don’t understand how battles are fought, you’re a terrible general. If the troops don’t understand military strategy, that’s not as much of a problem.
– Antoine Valot,
Why Designers Need to Code, and Coders Don’t Need to Design.
Integrated Teams
The second approach I’ve seen used effectively is an integrated team wherein a designer and a developer work together in real-time to produce a product. This requires both parties to be skilled and experienced in their craft and necessitates open-mindedness and a willingness to collaborate. If both parties understand that they can achieve greater results in working together than they could otherwise accomplish individually, the relationship will be productive.
The process of achieving synchronicity amongst the design and development team can come in a variety of ways. It’s a matter of understanding how both workflows can blend together and work efficiently with one another. One of our designers, Seth, references Brad Frost’s idea of designer-developer collaboration,
“It’s definitely a two-way street where I think developers need to fight a lot harder to work their way upstream and get themselves embedded into those conversations earlier to influence how things are designed, and what can be designed, and what’s technically difficult to create, versus other things. And because developers tend to have a better understanding around the capabilities and the limitations of the medium, if they’re able to work their way earlier in the process, they’re able to sort of make a smoother process for everyone, including themselves.
I think it requires everyone sort of coming to the table. Developers being willing to communicate, collaborate, and sort of have a little bit of flexibility. On the designer side, they need to be willing to come into the world of the actual code environment in order to not necessarily do that work, but to be able to accept the fact that it’s like, ‘Okay, I’m going to sort of partner with these people who know this medium inside and out, and maybe I can learn some things about new layout techniques like CSS grid or something like that.’ So, it’s like that humility on all fronts combined with all those disciplines throughout the entire process, is what leads to good work.”
– Brad Frost
Whether its designers learning more code, or developers getting more involved, the relationship between design and code will always be close. It’s just a matter of finding the right balance that will help you produce consistently for your customers.
