The workflow process of a web project can range from simple and straightforward to an exercise in an M.C. Escher caliber game of connect-the-dots.

Responsive Web Development... Workflow?

If there's a buzzword these days that actually has some genuinely far-reaching meaning to web design and development, it's 'responsive'. It's come to represent a philosophy of design and coding that revolves around building a flexible, sturdy base that can adapt and change to always perform at its best, no matter where it shows up in the wild west of the web. More than just responsive screen functionality though, responsiveness has become a hallmark of the leaders of this generation of the web.

'Responsive' as a philosophy can touch all aspects of working on the web, from start to finish. Workflows, in particular, can benefit from some responsive pre-planning. Depending on who you are and what you're doing on the web right now, some of this may already be pre-baked into your existing methods! From personal experience, responsiveness has a way of unintentionally creeping in to smaller freelance outfits and folks who are just starting out. Why? There isn't as rigid of a road-map in place as to "How it's always been done". Before I go any further, I should say that having that road-map in place, especially for teams of even 5-10+, is crucial. Always freewheeling may be 'cool' and 'creatively liberating', but you'll be thanking yourself for formalizing things a bit even just a few months down the road when maintenance and organizational complications begin to set in!

UI, UX, and a General Roadmap

So what does a responsive workflow look like? Is there one, correct model of flexibility that can be applied universally? Part of the nature of responsiveness in workflow means that no two iterations of the same process may be exactly the same. My favorite visualization is a set of Lego-type toys, or even the old fraction block toys I hope you were lucky enough to have played with in school. If not, you missed out, and may this picture be my condolences.

A well planned responsive workflow should be able to account for multiple types of clients, time-frames, project scopes, and other variables. Break down your process from start to finish (whether you're a one man army, or only handle one part of the complete process like design or back-end), and then granulate it as much as you're comfortable with. What you want to do is make the smallest possible building blocks that can then be used to reassemble a custom process for each and every client. At the start, everyone has the exact same pile; every finished product uses the same pieces. If a project brings a new process or level of granulation to your attention, throw it in the pile going forward.

Now that you've got your box of pieces, it's up to you to evaluate your projects for how the process should be assembled. Talk with your client and get a grasp of how much/little they know about what you're doing for them, and how much they want to be involved. Some clients want to be involved with every little step, some want to check in every so often and be surprised by shiny new things in their inbox. There's plenty to say about client relations and responsibilities, but that's for another day. For now, use what you've learned to start assembling your process. The client trusts you to create a visual design without input? Put all your granular blocks together and make a nice, long, streamlined chunk of process. They want a few revisions to compare and weigh in on? Streamline what you can, but keep the process in separate chunks and check in between each stage.

This methodology allows you to leave out whole chunks of unnecessary work, but requires you to acknowledge that you are actively streamlining that process with each new project, as opposed to letting it slide into neglect gradually over time. Each new process is a re-evaluation of your toolbox as a whole. If you have a specific way you actually take the time to visualize/record this each time, you may actually even be able to compare processes over an extended period of time and get some interesting insight into your professional habits and tendencies.

Workflow's Purpose

Just as there's an endless number of ways to create your workflow, there's just as many reasons to formalize that process. Better management of an office/freelance team, visible deadlines and processes for your involved clients, or a personal way to organize your own thoughts and drive, to name a few. Each workflow you make could actually fulfill any or all of these goals, regardless of the use of any other workflows you've made. So what purposes and methods have you used in your workflows recently? There's a whole world's worth of 'named' workflows, processes, and touted methodologies I didn't even touch on here, as I haven't delved too deeply into them myself. Have you used any that particularly stood out to you as an individual or member of a team?