Architects don’t need to be stonemasons or plumbers, but given the materials and the situation they need to know what is and isn’t possible so they can draw realistic plans. Architects need to be able to communicate with the people building the house. Architects’ jobs are not finished when the plans are finished: they go on-site, they make sure what is built is up to spec, and they need to adapt plans when unforeseen circumstances arise.
UX designers are like architects. We don’t need to be (front end) developers, but since we most often design front ends that end up being built as web applications, we need to know our raw materials, the web. We must know how a modern web application works, what the building blocks are, and what is and isn’t possible.
At the very least, we need to understand the theoretical basics: what is back-end, what is front-end, what is html, what is css, what is javascript, what are the various frameworks at various levels (realising that react and bootstrap are completely different beasts, for instance).
Ideally, we’d all get acquainted with basic web development. We should all be able to build a simple website, with some css and some javascript. It may also be interesting to know more about various more ‘modern’ specific aspects of html/css, e.g. flexbox, grid, but in general the idea nowadays is “if you can imagine it, it can be built”, so I don’t really think it’s that big an issue.
In specific projects we need to understand the tools that are being used, e.g.
- If the customer is building visualisations with d3.js we need to have a basic understanding of how d3 works, and what is and isn’t possible.
- If the customer is building a React app using ant.design components, we should know what React is, how it works, what ant.design is, how that works, what components are, how they work and how they can be modified, etc.
Making a product (site, application, experience, …) is a collaborative effort. Designers play an important role in that collaboration: we need to enter in a conversation with many parties.
We take for granted that we can and should have a dialogue with users, that we need to empathise with them and to a certain extent speak their language. We mostly produce deliverables (wireframes, detailed design, specifications, design systems) for people we might call “the business side”. But then we often assume that our final designs will somehow be implemented by an amorphous and shadowy mass of developers.
This “throw the specs over the wall” approach is in many cases no longer viable. The world has largely moved on from the model of big upfront design efforts, towards agile and iterative work, where design and development can and should happen concurrently.
In many projects there is a feedback loop: design, prototype, test, development, test, and repeat. This means designers need to be able to have a meaningful dialogue with developers, which implies we need to be able to speak their language.
When we specify designs, we need to communicate clearly and unambiguously what we ask of developers. Developers will typically not spend a lot of time reading a specification document. We should provide them with clear and readable wireframes, augmented with detailed designs / prototypes where necessary, e.g. for micro-interactions. It’s not really important how we create these prototypes (Axure, HTML, Framer, XD, AfterEffects…) or what form they take (image, web page, animated gif, movie, …), as long as they are as accurate as we can make them, and annotated where necessary.
We not only need to be able to communicate our design in a language they understand, we also need to be able to have a discussion with developers in real-time and possibly modify our designs as needed.
As an example: developers may have excellent reasons to not want to implement something we design, but in practice we also risk the “Star Trek lingo” problem: “we can’t implement the table sorting like you designed it because <insert random string of technical mumbo-jumbo>”. We need to be able to see through this.
The inverse of this problem applies too: developers are often wary of designers. Designers are typically much too vague in their specifications or leave details out that are ‘obvious’ (to designers), e.g. “you told us you wanted to test this search form and result list, but you didn’t say you needed test data for that”. This leads to developers routinely multiplying estimations by 2, 3 or 4 whenever designers get involved.
