Design Websites in Code
Posted on February 11, 2016
What is this madness, you ask? What advantage does designing in code possibly have over designing in design sotftware? Why should production materials be used at inception? I like my wireframes flat and abstract! I like my Photoshop. Code is not a design medium, it's a nerdy interface to present a design that lives in code.. Why..?
Because websites are made of code. Always and forever.
This wasn't always the case. In my 13-ish years tap-tap-tapping away at web architecture, design, development, for better or worse, I've seen every way websites have been created. I've seen terrible implementations, some of them, early on, being my own. I've seen processes that involved up to 6 design iterations and ways of bringing web development into the bite-size arena, so that clients can review & understand the process along with the agency or designer. I have, MANY times, been the person who was given the PSD and told to go to town, man! (Being a woman non-withstanding.) No process is perfect, and many of these are a little too imperfect, especially considering where we are today.
Today's web design process has the benefit of 40+ years of user interface research, that has spurned revelation after revelation, thing after thing, feature after feature, until some of them have been boiled down practically into user interface (UI) law. Back in the days of 10 years of research or even 20, we tried thing after thing to be the next best, to try to do it a little better than last time. The client loved it or hated it, but it didn't matter, because the client came to us because they didn't know. We could talk them into it, or be talked into hell because of sheer ego-sparring, until ultimately this practice with so little history and even smaller benchmarks had us doing everything on the bleeding edge of our power just to best the last project in blinks and marquees and get past the neon 256 color palette we had. Photoshop, that is, photo-centric design of websites, rose up in a way that knocked a lot of barriers off the cliff - it allowed for print fonts, textures, gradients, and overall brochure-like experiences. It left the codey-feeling old sites of the past in the proverbial dust as it carried us away, as happy as little clams could be.
In the meantime, Content Management Systems became the norm. We were doing for the client, out of sheer demand, what we were not doing for ourselves, because the collective derived desire for this was lost in the noise of a successful launch or post-launch bug list. We were not necessarily reusing our code, refining it, treating it like its own project. Our skills? Sure - we were honing them - but the code itself as a product of our time, an object of improvement, was not being kept sacred and polished like the true brain-baby it deserved to be.
It's not like we were necessarily pointed in the direction of something perfect to save and care for, however. Designers worked with multiple developers, and visa versa. MooTools one site, JQuery the next. New tools kept emerging. We would hedge on one thing only to find out that the new best thing was completely incompatible with our code. Doing our best each time always resulted in the last thing looking like a sad final exam.
When web fonts came along, springing a design from Photoshop came into view. Once we realized all that we were doing to get around the fact that we had 4 fonts to work with, and now we had more that could carry the message of all of this work seemingly independently, minimal design began to take the lead, and textures, slices, and image-based markup began to fade.
Also, phones. Websites on phones. Mobile sites. Mobile apps. How much of this is was a designers' burden? Depends on when you ask, but today it's at 90%, if you allow your dev that extra 10% to do the responsive component their way. So, in Photoshop, your single page design just turned from one view to 3 (at a minimum,) sometimes requiring a developer to reverse-engineer some crazy layouts that the designer, only having so much experience, put together because they had to "fake it till they made it," and not because they truly understood it.
There were some people, however who took the 5,000 foot view of all of this and noticed code popularity organizing around popular features and the need for flexibility in applying design to user interface. Miraculously, these people had time to organize their thoughts either in spite of or in spite of a lack of client work. First they created Grids, or JS Libraries, (some still do,) but then some created Frameworks.
Not quite. The focus on refusing to reinvent the wheel is hot with some and not with others. While we're still united for web standards, so much so that the movement is considered a victory and is enjoying the honeymoon of retirement, but not everyone agrees on the inception of a website. But most of us agree on one thing: to be of value. This is our only goal in listening to our clients tell us about their needs. We're listening for pain, but also humor, clues to the bigger picture, identifying the spoken brand through their voice. They hand us over some brandy things and we can turn around a round-1 mood board, replacing a round-1 "wireframe" delivered only by PDF (lame!) if we:
- Find & use a framework that has all the UI components that they will need in their project.
- Create an HTML page with one of everything that they will need (and I throw a color chart in here for good measure.)
- Add a little CSS to brand it appropriately.
- Put it somewhere so they can see it.
Where the client was formerly making abstract decisions on something that only abstractly resembled a website & didn't know how to time appropriate feedback, the client is ALREADY interacting with a coded piece where some small pieces of it could even be FINAL. They can deliver qualified feedback based on how the design looks in the browser, how it interacts with them, and the overall feeling they get from playing with it. And here's the best part - YOU can keep adding, changing, rearranging, and things fall into place because you know where to change the tiniest values and otherwise, your code just wraps around itself in display.
As an added bonus, you're not going to get any of that awkward interactive critique that the client comes up with (because they are only now interacting with their site,) right before launch, delaying your launch and stretching your budget. The client know's what they're getting, how it feels, can look at it anytime, and shoot you relevant feedback to the place where you are in the process.
Let's count the versioning, alone that we're saving with this process:
- Wires: 2 versions.
- 3 versions per revision
- 3 pages (home, interior, other)
- 3 views (minimum) each.
Total: 29? At a minimum? Good grief. That's a lot of proofing. This process:
- Moodboard - 3 revisions
- Pages with occasional revisions, none structural.
Total: 4. 4!!!!! FOUR.
That's a difference of 25. You're providing this much greater value to yourself and your client.
Just one thing - this process isn't going back to the old days or some kind of hipster code minimalism. Quite the contrary. Frameworks are the result of hundreds of brains in large companies pining away for perfection in flexibility and potential. Even if you're smarter than every one of these people, you're not smarter than all of them put together, nobody is! Frameworks are code libraries and they are quite large, so they sometimes have performance implications, but not always. For example, use of Zurb's Foundation through Gulp preprocessing ensures that you have to un-comment every feature to include in your work, so you're only adding the bare minimum, while taking on slightly more work for the performance of your site, a task which is always worth it and generally more than *slightly.
Today's design process for responsive web sites has the ability to reflect all of the ways that we, the collective makers, have changed the web. Do you agree or disagree? The comments are here for you.