Many UI professionals – typically in smaller to mid-sized organizations – are responsible for both visual design as well as front-end development. In such set-up, a UI designer/developer works directly with back-end programmers usually with the same code base and in the same environment. The handing over of files between teams and the need for extraneous instructions is virtually eliminated. This typically results in far more nimble and accurate transition from concept to execution.
How do you organize your workflow when you are both the designer and a developer? Which do you focus on first? Attractive design, usability, or efficiency? Below are high-level breakdown of workflow that, for me, have resulted positive outcome in numerous occasions.
1. Make it usable first.
2. Make it somewhat pretty and presentable.
3. Make the interface behave the way you intended.
4. Make it dynamic. Optimize. Modularize.
1. Make it usable first
First and foremost, this involves understanding the business needs and requirements. It also requires that you come up with a logical organization and breakdown of content and its delivery. Which basically means knowing what is important on a given page. What is the goal of a particular scenario? What should be in focus? Which elements are the star of the screen? And which are secondary or supporting elements? Answers to questions like these ultimately dictate design patterns such as font size, font-weight, placement, white space and sometimes shade and color*. This is easily the most crucial step of the design process. If you don’t get this step right, it doesn’t matter how pretty or trendy a page or the site looks. It just won’t work. No amount of cool animation or interactive bells and whistles is going to make up for the failure to communicate.
(* Although I was always a firm believer that a highly intelligent, highly evolved designs should work even as black-and-white or monochromatic, I realize strict enforcement of such belief isn’t always feasible nor practical.)
2. Make it somewhat pretty and presentable.
This is the step where you refine your markup and the CSS. A lot of the styling and formatting applied at this stage is more or less the direct result of the decisions made in the previous step. This is when you can also think about how to organize the front-end dependencies such as stylesheets, javascript, libraries, CDN, images, media files, markup and include files. I almost always use some type of server-side includes even for the prototypes. When developing locally, Mac OS can easily be setup to run PHP or for Windows, you can install something like WAMP. I say ‘somewhat pretty’ at this stage because you’ll be tweaking and fine-tuning the style throughout the next steps and probably right up to the point when the site is about to go live.
3. Make the interface behave the way you intended.
This is when you add interactivity to the interface to bring them to life. It’s much too easy to get carried away with javascript behaviors and effects. Effects should never be added simply because they are cool. If they don’t add any value, enhance usability or support communication they are distractions. And also remember that nothing is free in programming. Every interactivity adds cost either in performance, maintenance or something else. There’s always a cost to everything we add.
4. Make it dynamic. Optimize. Modularize.
Rarely anything we create for web these days are static. Also, many of the interactivity and behaviors may be dependent on dynamically pulled content or data. Elements such as menu, text, links, images are rarely hardcoded in the markup (actually, they should never be hardcoded). Whether you ultimately work with a database, XML, JSON, or third party content, it’s important to first make your code work with static content before attempting to write a complex code involving dynamic data. Start simple. If you can make your code work the way you want with static data, introducing the dynamic data later on should be simple.
Also think about the ways you can optimize your script. Find ways to write less code. If you find yourself writing a similar function more than once, chances are, you may be able to write it only once using variables and parameters. Are you repeatedly targeting elements using unique class names or id? Instead, try to find a unique identifying pattern in the DOM so that you can target elements without using given names. That way, you are making the code reusable; the same code or function can be used over and over again for other similar tasks.
Modularize your code. It basically means do not wrap everything in one huge block of code. For instance, if a particular function is made up of several smaller functions, separate out the smaller functions, put it outside, and make it reusable. The idea is to make your code work like the old Lego blocks, generalizing its purpose so a piece of code can be utilized in more places. Note that I said ‘old’ Lego blocks. Many modern Lego pieces are overly specialized that they exist only to serve a single purpose which is not the direction we wan to take with programming.
