A UX/UI developer’s workflow

Ever since I started doing front-end work full-time, I had a realization that there is an almost infinite array of ways to get the job one. What do I code first: IE or the standards-compliant browsers? How much wireframing do I need to do before designing? And the questions go on…

The nicest example of a developer’s workflow I could find is the following talk by Ryan Singer, of 37Signals fame, about their design process. I hope you can watch all of it as it’s well worth your time:

Here's a talk I gave at Future of Web Apps 2010 in London. In this talk, I walk through the steps of creating a web app including modeling, sketching, HTML, Photoshop explorations, and moving from static mockups to live running code. Each step is illustrated with a real example, including some live sketching and live HTML. I also wanted to give a sense of how we think about apps at 37signals, as a stack of different levels that we can iterate on individually.

So, for the sake of showing those who may be getting started or want to see a different perspective from a fellow developer, here’s how yours truly usually goes about building things on the web.

A COUPLE OF STARTING TIPS

• Don’t get married to your ideas. You’re doing it wrong: People who make things (designers, developers, artists, etc) tend to fall in love with their creation. There’s probably a term for it in psychology, but just remember that you’re not always right and, worse yet, you don’t want to know that you’re wrong. It takes humility, but I suggest you turn the thought on its head: Assume you’re always wrong and ask the people around you (ideally users) neutral questions that prove or disprove your ideas. This is especially true for UI work.
• The 80/20 rule: At each of these steps, if you’re obsessing over details, it’s likely time to ask someone else to help you decide and move on. Is the wireframe properly lined up? Move on. Does the font you picked for the footer copyright notice in Photoshop exist in browsers? Move on. Designers (myself included) tend to suffer from this level of paranoia more so than other human beings, so just be on the lookout for time wasters like these.

DO YOU “GET IT”?

Ryan’s talk perhaps enlightened me the most on this simple tidbit: Do you truly know what the app needs to do? Who are the people using it? Why are they using it? How is it any special or different from other products? Can you make those shiny points stand out? This is where other fellow UXers do things like persona creation and contextual inquiries to figure all this stuff out.

A good sign that you “get it” is that, while you don’t yet know how your app will look and behave like, you do know what it will NOT look & behave like based on your research. For example, if you’re building a talent recruiting app and your customers from HR keep raving about how crappy these database-looking things are, then you’ve been forewarned to pony up your usability going forward.

Hopefully another thing will also happen: your team will now have a shared vocabulary of “objects” that interact with each other in the system. These objects can be users, products, orders, collections, etc. All that matters is that they’re like first-class citizens and will get special attention going forward.

HE SKETCHED “CRUDIES”, AND HE SAW THAT IT WAS GOOD

Based on the “objects” you’ve defined before, there is a beautiful little hack that works wonders for my wireframing that you need to learn.  Sketch the following states for each of your main objects:

C – Create: Where is the form that creates the object? What data do you need right now and what can you make discoverable later?

R – Read: This is usually the Big Kahuna screen for your app. When a user accesses one of these objects, what does she see? 

U – Update: This may not always be possible, but I always try to make the form that edits an object the same as the form that created it for usability’s sake.

D – Delete: What happens when the object gets deleted? What message do you show the user before and after?

I – Index: Do you need a screen to display all instances of an object (ie. search results, product inventory, friends list, etc).

E – Empty: So important and so often forgotten: What does your user need to do when there’s nothing there? Can you take this opportunity to teach her how to do it?

S - Start: What does your user experience the FIRST time they use your app? How can you delight within 30s of the start?

You may find that some states of an app overlap one another in the same screen, which is ok, as long as the states themselves have been accounted for. This step is your best shot at catching big mistakes for a little cost, so go out and do it! Ask users to perform tasks, run usability tests on your Balsamiq files, get feedback on things that you’re not sure about. It sucks to realize you’re wrong, but it’s even worse to realize you’re wrong once you’ve deployed this thing with Javascript and IE baked into it.

MAKE IT PRETTY

Your wireframe has mostly survived the barrage of user feedback, so now you can let your creative genius come out to make things pretty. A couple of quick tips at this stage:

• Remember your audience in your design and make it “speak” their language (corporate business = serious; consumer = friendly, bubbly; tools = utilitarian, minimalistic, etc).
• People love Photoshop, but I’ll suggest you use Illustrator for the main composition because of its native vector graphics. Realized your screen size was wrong? It’s 30 seconds to fix it in Illustrator, not so in Photoshop. Of course, there are cases in which this is just impractical (ie. working with stock photos), but I figured you should know…
• If you plan ahead, you can actually design with your favorite CSS framework in mind (960.gs for me) so that coding it up becomes a breeze later.

MARKUP FIRST, LOGIC SECOND

OK you’re finally there: it’s time to code the app. Here’s how I usually do things at this stage:

• First off, get a CSS framework (960.gs, Blueprint, whatever) and save yourself some time. They’re crazy easy to use and are really handy on the cross-browser nonsense.
• Make your code work in the latest Firefox, Chrome and Safari. Deal with IE later. Drop IE 6 if you can, life is too short to suffer needlessly.
• Get your HTML coded from OUTSIDE > IN & TOP > DOWN, meaning start at the very outermost box your layout is going to have and get more granular as you go, coding things up at the top elements and downwards towards the footer. I find that this helps you pick out browser weirdness early.
• It’s good to have a CSS style guide preloaded with some globals just to avoid repeating “font-family:” stuff all over your declaration. Also, code your CSS up in lockstep with the HTML so you can adjust elements on the fly if you come across browser inconsistencies.
• Have you heard of CSS sprites? This is a damn good time do it…
• Fix IE’s crappy CSS rendering before adding your flavor of Javascript library (ie. jQuery, Dojo, etc). This will help you set a checkpoint that you can fall back when the JS stuff also starts to break IE’s layout rendering engine… 

So there you have it friends! I hope this extends Ryan’s wonderful talk (did I mention you NEED TO WATCH IT?) and added a bit of detail to it. I’m very curious to learn about your own workflow? Do you skip design and jump straight into code to prove out a concept first? Are there any tricks along these steps that you vouch for? Let’s hear it from the pros!