Code Out UX Design

Many designers do not like getting into the nerdy realm of front-end coding. Quite the contrary, I often feel constrained by design software (e.g. Axure RP), and a few lines of code always makes my job much easier. So why should designers code, exactly? And how?

Let’s start with one of the most heard complaints from design community:

“Ah! it’s so hard to talk to developers. They always ruin my design. Why can’t they just follow my documentation!”

Yes, some developers only care about getting the job done, and if you don’t specify everything, they will just sneak through or make up random things and emit a cloud of shenanigans.

But don’t forget this - caring about design is usually not their job. If you have a great front-end developer who can interpret your design, you are lucky. But for most of them, they do not have the design eyes at all - the difference between #ccc or #ddd is enough to make designers scream out, but they are the same thing to developers. What really interest them is the code - architecture, algorithms, and probably the universe’s most advanced command-line interface.

So to fill the gap, here comes design software, aiming to translate the tribal design language to normal people.

Stages of Design

I will not try to join the debate of iterative design, but in a word, there are a few universally acknowledged UX design stages for each iteration of design (though they might be named differently):

1. Early concept
2. Initial low-fi mockup
3. Hi-fi visual design
4. Interactive prototype
5. Development

For each stage our task and goal is different, so is our requirement of design software. As we move to the later stages, the ability to carefully manipulate design details becomes increasingly important. And on the final stage right before the development, attention to detail is even the top priority.

Speaking on Axure RP

Most designers in my company use Axure RP as the prototyping software. While I agree that Axure is a great WYSIWYG design tool, but the inconvenient truth is, that Axure is entering a weird middle ground as the web become less static and more interactive.

For simple & quick concept mockups, Axure always seems a bit too powerful to me. It can do much more than simple wireframes, so I’m always tempted to make the design better. I often end up using other light-weight alternatives that allow me to focus on basic architectural design and turn around things more quickly.

For hi-fi deliverables, Axure’s lack of visual design components really gives me lots of trouble and requires excessive amount of time on tweaking & hacking. For example, it requires two text panels to fake text shadows, which is just a CSS declaration in production code (well, maybe more than one due to legacy browsers, but you know what I’m saying). Also, its signature prototyping function is sometimes cumbersome too. It only supports limited amount of interactions in a fixed canvas. Facing the trend of responsive web and CSS3, it’s quickly getting old and difficult to play around - just think about how you want to simulate multiple collapsable panels in Axure.

Stacking up dynamic panels? No, I bet you don’t even want to try.

Really, Axure is best suited in the middle ground - where you already have the initial functional/information design settled down, sketched out the basic structure of the product, and are in the process of selling your ideas to business and development teams.

After you survive this stage, Axure prototypes can be a great documentation to archive, but probably not the best one to deliver and use to work with development teams. Just like I said above, it lacks the ability to manipulate visual details (aka. fidelity), and does not support complicated interactions well.

Yes, prototyping software is constantly improving too - e.g. in Axure RP 6.5 the company finally added image rotation function - but not fast enough to keep up with the evolution of web.

Power of Coding

I’ve seen designers spent a whole week hacking on a hi-fidelity Axure prototype, send it to usability lab for user testing, and then produced a pixel-detailed documentation based on the prototype to be handled to developers, making them start over to write real HTML + CSS code (and then repeat the cycle for the sake of iterative design). I ask myself - why couldn’t they just do the prototype in real HTML & CSS code? Why did they keep wasting so much effort on this?

Building up a site from scratch sounds intimidating, but with the help from a wide selection of frameworks, things are getting much more easier than ever before (I wrote another post explaining how to deploy a simple coding environment tailored for front-end coding).

My experience with designer coding out the interactive prototype is mostly positive. Surely the learning curve was steep for me at first, but I found myself in the comfort zone after coding out my first website, and it actually helped save tons of work hours later.

Our design team code all the time. We enjoy it, because it makes our life easier. In terms of my personal experience, designer’s code helps:

• A more engaging experience to better align stakeholders. It goes without saying that a common understanding of how the product functions is very important. Designers are able to look through the design artifacts to imagine a final working prototype - but most of our stakeholders can’t. An fully interactive HTML prototype may not be comprehensive, but it simulates every aspect of the final product to create a full picture for non-designers, thus establish a solid common ground.
• Effective communication with developers. Is it 8px or 10px? Developers can’t tell, and it’s also so tedious for designer to mark every white space on your mockup. Furthermore, I bet if designers do not understand CSS code, they don’t even know how to mark the correct attribute on the redlines - how many people know that line-height, padding, margin, font-size all affect the space around a line of text? How many people know the difference between pt, px, em, rm and % as the base unit size on web? How many people know the margin collapse in CSS? If things go wrong, the back and forth between designer and developer is going to eat up most work hours. For a pixel-perfect product, designers need to control every aspect, and know-how should be the first step.
• Quick turnaround for iterative design. I’m not saying all designers should produce production-ready code (front-end developers may lose job because of this so let’s play nice). Even if the code is only for demo purposes, it still allows researchers to take it, and put it in front of users to conduct preliminary walkthrough and testing - in a controlled environment, demo code is more than enough. It also give the developer an option to take the code and modify for production. If they’d rather start over, it still provides a native web experience as for them to use as reference (for example using Inspect Element to find styling attributes), which is better than software produced artifacts.
• A more practical design (when needed). It means in design process, it empowers me to think about the final implementation. This could potentially be a bad thing because it would let technology lead the creativity - and that’s why I usually don’t do it. But it’s helpful for time-critical projects or bug fixing, when working out an effective solution in a given time usually requires an easy-to-implement design.

Build Up the Toolkit

What I learned, ultimately, is choosing the tool that work the best for your on each stage of design, and if a particular tool becomes a hinderance, do not afraid to switch. For me, at prototype stage, hand-written HTML + CSS + JavaScript works the best, and that’s why I am writing this article to speak out its benefits.

I’d like to conclude with the tools I use on different stages of UX design:

• Early concept stage: Balsamiq (or just paper + whiteboard)
• Initial mockup: Fireworks (it’s so sad to see Adobe discontinuing it)
• Hi-fidelity visual design: Fireworks or Photoshop (yes, Fireworks is really competent for most modern web visual design)
• Basic clickable prototype: Axure RP
• Hi-fidelity prototype: HTML, CSS + JavaScript coding
• Functional prototype: Ruby scaffolding

Happy designing, and coding!