CSS is !important

You are a back-end developer. You may write code in PHP, Python, Rails, Javascript, iOS, .NET, or whatever. The languages change with the seasons, but a developer’s skills go beyond knowing a language – you know how to put things together, how to think about the world in a technological sense. You can translate theoretical requirements and ideas into functioning digital realities.

I am a designer. I work on building user interfaces and adding all the visual details to our projects. Because I work with developers every day, I know your job ain’t all daisies and roses — It’s often misunderstood by clients, and therefore undervalued. Many people have no sense of how hard something is, how long a feature will take to build, and it’s frustrating. As a back-end developer you may have presented your work to a client and heard them say things like: “Why is that line there?,” “What is that weird dot?,” “I thought we were going to make that part black,” “Will those buttons be blue?,” “It looks a little boring,” or “When are we going to have the theme?”

Software Development is Difficult for Mere Mortals to Understand

For clients, these are completely legitimate statements. For developers, these are motivation-killing phrases. “Lines and dots? WTF???”  You’ve spent hours coding recursive functions, looping through nested arrays, integrating third-party applications, writing APIs, researching database solutions, testing code, meeting requirements, and for some reason the client totally misses the point of the demo! The nerve. Go easy on your clients, though. Remember that they have very little idea about the work developers do, and that’s because your work is very complex and therefore hard to understand. Personally, I glaze over all the time when I hear things like “apache,” “call stack,” or “regex,” and I actually kind of know what these words mean.

So what can we do? Clients are capable of understanding your work, but I think they need a translation, a protocol. They need an interface. They need that pesky CSS. I know most of you back-end developers don’t like writing CSS — it never matches the PSD mockup, it doesn’t work in IE, media queries are confusing, and vertical-align never works! — but give me a chance to explain.

The Link Between Your Expertise and Their Vision

The CSS is the link between your expertise and their vision. Let me give you an example: You see that little trash can on your desktop? You can drag almost anything over it and your operating system will delete it. Nice. Convenient. But that icon isn’t really a trash can, right? And dragging a file “into” it is more complicated than it seems. It’s a series of complex digital instructions that a person like me would find difficult to understand, but you do. I only understand how it works because I know what a trash can looks like. I’ve been given an interface that is familiar and therefore I can accomplish a task that a smarter person coded for me. Thank you, smart person. I love deleting shit.

We can do the same thing when we build websites, software, applications, etc. We can give clients and users an interface that makes sense to them. We can help them appreciate all of that hard work that you do. Granted, we’ll be using CSS to build the interface instead of C++ or Object C, but the principle is the same. So, yes, I’m stressing the importance of writing CSS, and because I know it can be a pain, I’ve brainstormed a few methods to make this initiative easier to swallow. Here’s how:

CSS Components

Think of CSS components as tools in your developer’s toolbox. By gathering these reusable, flexible CSS components, developers can amass a reliable set of code snippets that they can use in their prototypes and software interfaces. This way, when you need a set of data filters, or a navigation panel, or a calendar of events, you can reach into your “toolbox” and grab what you need. You don’t have to start from scratch.

Pre-built interfaces

Building interfaces before building back-end functionality is a really great solution for developers, but it’s also great for clients, and even designers. For developers, it frees them up to focus on the code they know best, it helps communicate requirements and expectations, and it improves the developer/client relationship. The weird dot is gone. The buttons are already blue. “That part” is black just as the client requested. The design is approved, the theme is built – now you’re off to the races! For clients, it allows them to see and interact with their product before it’s even truly finished; they get to see the icing on the cake before it’s even done baking. For designers, it allows them to create and iterate on a UX/UI solution much more quickly than if the interface had to communicate with an API or a database.

Design-driven development

But what if the client asks for a new feature that isn’t already designed? There’s no CSS for that. Design-driven code helps to solve these types of problems. To me, design-driven code simply means including designers more throughout the process. Bring them to requirements gathering. Bring them to your pre-demos. Carry them on the plane! (I’m always game for a free trip.) Having them advocate for an application’s interface means you don’t have to answer questions like, “Why is that line there?” You can just sheepishly grin at the designer, put your hands behind your head and wait for them to answer. “I don’t know… Nick, why is that line there?”

Developers can also lean on designers to help with CSS quality assurance before a live demo. After all, the designer is the one who built the interface. Our developers come to me with CSS and UX questions all the time. Win, win! They’re thinking about a user’s experience and how an interface looks, and I either whip up some CSS code to solve the problem or I can meet with the client to discuss the best solution. In my experience, this type of process improves relationships all around.

I’ve received really positive feedback from our developers with this design-driven/design-first approach. They appreciate having an interface that’s already built (because most of the CSS and JQuery is done), and they’re even more excited to get started on a project when design is finished because it looks cool to them too, not just the client. They look forward to installing all the wires and connecting the plumbing rather than dreading the disenfranchised responses they might otherwise get during a demo.

So I say “CSS is important!“ It is the crucial bridge between back-end developer and client. And it doesn’t have to be painful if we focus on implementing a build-it-first process and providing developers with some common CSS patterns. It isn’t rocket science either – agencies have to build interfaces anyway, so why not do it up front? Using this kind of process gives developers the freedom to focus on solving problems, to be more efficient, and to write better code, and this leads to faster applications, lightweight websites, and better software.