Code – the superior design tool
Also published in Norwegian @ kode24.no: Kode som overlegent designverktøy
Have you ever thought about the fact that the users are never really in direct contact with what designers make? User interfaces are built by developers who are experts on the users’ environment, but the decisions are made elsewhere, by people that use entirely different tools. Sounds suboptimal, doesn’t it, keeping technical knowledge and user knowledge apart like this. And are those kinds of expertise really that clearly separated? Or are we seeing more and more people starting to cover both fields?
What if I told you there exists a design tool that could not only solve this but also improve your workflow. It might sound like a standard sales pitch for a new sketch and prototype app, but we are, in fact, talking about code. When it comes to making UIs, it’s the only tool that’s good enough.
User-centred development
Working with code means working less with sketches.
The problem isn’t really the sketches, but how they are used. They are great for communicating and discussing concepts, ideas and flows, but they need to be simple and rough. The pixel-perfect ones, on the other hand, are becoming irrelevant. Not only are they trying to be some kind of blueprints for the web, they’re not even a good way to make UIs. They are predetermining things they have no way of knowing because they are created outside of where UIs live.
Contrary to popular comparisons, interfaces aren’t architecture where everything must be made to measure. The fluid nature of the contemporary web makes it impossible to plan out. A room has the same size regardless of it being empty or you try to fill it with ten tables. An application, on the other hand, adjusts to your screen and your content. No sketch can take that into account, it can only be achieved through effective, human-made code that runs in the users’ environment.
All sketches, either static or faux interactive, are made to be handed off. Which disconnects the users from the designers’ work. And they don’t get any closer despite research, interviews, metrics and media-queries. Only by using code can you tell how the content will behave and what techniques are needed. Doing that at a sketch level would require the same amount of work as developing it – which sounds pretty redundant.
Bridging vs. filling the gap
The hand-off requires time and effort to translate the sketches, thoughts, and interactions into tasks. As well as rounds of back and forth for clarifications and adjustments, maybe weeks apart from when the designing took place. By the time the sketches are implemented, the work has been done at least three times. And in the meantime, there’s always the risk that the real world has changed.
Despite all the modern software claiming to improve workflows and teamwork, they’re essentially just re- and reinventing the twenty-year-old workflow of PSD2HTML. The infamous gap between designers and developers might not be as deep or wide as it once was, but building the most efficient bridge can only get you so far.
Within the gap, it’s my experience that designers feel like they lose control of what they make before it ends up in the hands of the users, and developers feel like they are just doing what they are told. Recognising that those people, together, are the most qualified at uncovering and solving problems and weaknesses in the services they make is the road to an increased feeling of responsibility and ownership. People care more about the things they can impact. And when they are invested, they build better interfaces.
We are way past talking about improving communication between designers and developers. The next step is to start turning designers into developers and increase the design competence of traditional developers. The reasons for keeping designers and developers apart are grounded neither in an excellent workflow nor in what’s best for the interface. As long as we’re trying to bridge the gap, we are contributing to its existence. The only way to get rid of it, is to fill it. With code.
Design all the time
Design is the process – not the result – of making interfaces. Which means that design for screens isn’t one single thing that is instantly solved just by working through a screen. It also means that design isn’t a step in a process. No matter how strict the compartmentalisation is, the result is not going to improve. You will most likely end up with interfaces looking more like the sketches made by someone else in the middle of the process. Design should permeate the process through planning and discussions, like today, but also development.
Feedback from developers in all parts of the stack tells me that they do better work when they can solve actual user and tech problems instead of those created by a sketch. When they can be part of making and challenging relevant decisions instead of just implement predetermined tasks.
Workshopping flows and functionality with all the relevant people results in whiteboard sketches that hold more value than any pixel-perfects can. And few things can beat a workflow that allows iterations and testing with actual data in environments replicating exactly what the users have. It enables things to happen at the right time, with the right people, instead of trying to create detailed snapshots of something finished halfway through the project.
When you free yourself from the idea that developers and designers can’t be the same people and that their work must be compartmentalised, you can start developing earlier and with what you’ve got. And you can often leave things like visual details toward the end. They can always be changed later or handled by a design system.
Police and translators
The logistics tool we make has a frontend team that consists of people with various design and developer backgrounds. The details of how we came to be and how we work are beyond what I’m trying to tell here. But the short of it is that we make some rough sketches with the other teams, do some quick devtooling in the browser, and code the odd prototype using our logistics application’s design system. Most importantly, each and every team member writes (and deletes) thousands of lines of production code a year. Zero pixel-perfects are made – they don’t exist. Instead of acting as gatekeepers or police, we try to teach, assist, and together with the other teams, build their frontends.
Only you can find out what works for your organisation. The technology exists, the knowledge isn’t far away, but you need to create some wiggle room. This isn’t a clear cut thing where you can change some titles around and call it a day.
Chances are there are already designers with coding skills close by, who perhaps are going to waste as hand-off translators or prototypists instead of writing useful production code. Same goes for developers with invaluable insight and unique ideas – something a traditional design team would have a hard time utilising as long as their job is to tell developers how things are going to be.
Form heterogeneous teams where different people can begin expanding or utilise different skills. Do whiteboard discussions, learn from and participate in each other’s work. Also, make sure people can voice their fears and challenges.
Review, adjust and repeat.
For us, efficiency and teamwork improve when everyone is developing. I’m not only convinced that it’s to the benefit of the users – it’s also good for business.