How the heck are you supposed to build a web site these days?
Process feels pretty good. It’s like a dependable bus route, with all these little stops, and you can measure how long it takes to get to each one. Then, the transportation service can tweak it and tune it so it becomes more efficient over time. They can document it and refer to it each time they have questions. They can add and remove stops. Passengers can build expectations around it, and even make predictions because of it, and because of this, they can feel confident.
We do the same thing with our processes. Over time, it’s hard not to become attached to something like that. Look at all those benefits! But what does our transportation service do if all the sudden we’re flying cars around in a year or two? (I really hope it’s that soon!) They can’t use that trusty bus route anymore, or even their bus, for that matter! In this article, I’ll give you some reasons why you might want to re-evaluate your processes, or even let them go and start new ones.
The iPhone happened, right? Maybe the actual device that started it all is debatable. The point is, an unpredictable amount of little (and big) devices are now pulling up your web sites. We’re flying cars now. Because of this, we’ve all been faced with how to define, adjust, or re-define the processes we’ve all become so comfortable with.
The part about Responsive Web Design
I think it’s obvious that I should start with the topic of Responsive Web Design (RWD). This is that new vehicle that is giving us a reason to redefine our processes. Many web teams are now considering RWD for every new project they take on. Customers are even asking for it now, even if they don’t really know what it is. We all understand why the idea of it is at least worth considering for each new project we take on. Some shops are already baking it right in as part of any new projects they do. Some people are already sick of the buzzword, and they agree that RWD as just “design” now. The web is responsive, and therefore design is, too.
But there are still times when it’s obvious that RWD is not the right tool for a job, and maybe that a native app is needed instead. Or, maybe a multi-device solution isn’t needed at all. Regardless, it seems the question of whether RWD is needed for a web project is almost always asked.
Do we need RWD?
When this question is brought up for a new project, sometimes it’s an easy yes or no. Other times, it may take some research, thought, and discussion with the customer and your team. A quick look at the past and some conversation about the future around the customer and their project can help with the decision. For example:
Past: This can be as simple as checking the site’s analytics data from sources like Google Analytics to find out how many different devices users are trying to access the site with. If you already know the site is a mess on devices other than a large monitor, then you don’t really need to dig deeper into how much users of other devices are using the entire site. It’s enough to know that they’re trying. And if you decide RWD is not the right tool for the job, maybe you only need to do something informative for those who are still trying to access the site with a different device.
Future: The future is about the goals of the entity you’re doing the project for. Is this a site that would be even appropriate for people to use on various devices? Do they want to increase the usage of their site for various devices? Will doing so add value? (Almost always a “Yes” for typical websites). Some businesses may find themselves literally selling the “feature” that is RWD to the customer at this point while others don’t even mention the word anymore.
It’s not all about RWD
Responsive Web Design is a tool and skill like any other. It can be misused or abused. It’s not something you should just slap on a site. If not used with care, you can risk making a web site’s content just as difficult to access as if you weren't using RWD at all. It takes time and thought to plan for how a site will be used across the plethora of devices out there. However, you can bet that it will become a near constant in your new workflow.
A Changing Process (One could even call it “A Responsive Process”)
So, if the web is (and arguably always has been) responsive, we should be too, right? It would seem that the more rigid we try to be, the more we find ourselves wasting time on doing things we don’t always need to do. The new web design process is one that can respond to each new project you bring in by assessing the problem, and re-evaluating both your tools and your approach.
If you’ve taken on a project that you know will be implemented using a responsive design, there’s a good chance that your tools can be augmented by one of the many new discoveries happening in this industry every day. For example, maybe you saw a framework that can save you time, or a new approach to responsive images that will allow your pages to load quicker on small, wireless devices.
The fact is, we’re starting our processes over. We've had to hit reset, and now we’re back to tweaking and fine-tuning. The difference now is that we’re constantly responding to new developments as they happen. Your process needs to allow for this. Your process needs to expect this.
The new web design process is one that can respond to each new project you bring in by assessing the problem, and re-evaluating both your tools and your approach.
My New Process: The Blob
For the longest time, I couldn’t find a name for that part of the process where you focus on just about everything that comes before the actual implementation. It’s not terribly different from all the things we had to do before. Except that now, the canvas we thought was predictable, is entirely unpredictable. I used to just call it “The Blob.” The Blob would contain everything like R&D, IA, Content Strategy, UI and styling the site. More recently, I call that whole process what it is: Design. Design, to me, is such a broad term. It used to infer visual design. Now, it’s the part of the project where you, or your team, come up with the solution(s) to the problem(s), regardless of the skill set being applied at the moment. I wrote previously about the difference between designers & implementors, so I won’t go into that here, but it’s all these sub-processes of the over-arching Design process that are all the sudden difficult in the modern web industry. It’s where we used to have a tried and dependable process, but now we have it doesn’t really apply.
In a recent podcast I listened to, the hosts spoke about the difference between “Deliverables” and “Delivering.” I think at one point someone even used the phrase, and I’m paraphrasing, “Don’t worry about deliverables, just deliver.” That sentiment is spot-on. Our old processes will persuade us that we need to spend time making things we inevitably throw away, or so we can get some sign off to call a milestone complete. Wouldn’t it be better if we had the freedom to choose the right tool and approach for the job, and we could produce meaningful and essential output the entire way through? Of course, it’s not always that easy. I understand that.
Tools And Approaches
So, now we can at least consider letting go of old processes. We can identify and become familiar with various tools and approaches. We don’t have to be stubborn about one approach over the other. We can use the one that works for the job. Over the past few years, I’ve picked up several tools and approaches that I evaluate for each new project. In some cases, the words "tools" and "approaches" are almost interchangeable, because some tools are actually full-on approaches, such as a responsive framework. Here’s a breakdown of some of the tools and approaches that I’ve been using lately:
- Sketchpad & Sharpie (it still takes less time than anything. It makes progress quickly, and it gets the ideas from my head to a place I can see and start getting immediate feedback on.)
- Sass (for the obvious reasons. It is obvious by now right?)
- Compass or Bourbon (Handy mixin frameworks to save me from having to type too much CSS or re-invent the wheel. There are tons of these now, but I come back to these ones a lot.)
- Foundation 3 & 4 (A framework for rapid prototyping in the browser)
- Livewires (A low-fidelity framework for rapid prototyping in the browser. Haven't tried this one yet, but I look forward to it.)
- Guard (for running various tasks as I work on projects, like concatenation and magnification of files)
- LiveReload (reloads my browser on save.)
- Bundler (for managing Ruby gems I use for projects. All of the above items are actually gems I pull in to be used in my projects.)
- CodeKit (a Mac app that can do almost everything above)
- Web Inspector (I typicall develop with Chrome)
- Sublime Text 2 (The greatest text editor I’ve used yet.)
- Git (code repository and versioning)
- Photoshop (Yes, I use it. Occasionally, I even still design a comp. Sometimes I just pop it open to create a texture, or edit a photo, or create a graphic.)
A Typical Workflow (For now!)
I’ll briefly touch on a typical project workflow, for the sake of discussion. Here’s an image that represents a typical workflow, with a focus on the Design segment.
What that image shows is after the initial discovery and project R&D, I dive into little cycles of research, prototyping and feedback for specific site features or areas. Then, when my team, the client and the users are happy with the overall success demonstrated by the prototype, we're free to dive into branding, deeper frontend development, and backend development.
I’m not anti-process, I just like progress.
I have nothing at all against creating processes. I will either create, or have my hand in creating many more of them over the course of my life. But if recent developments in our industry are teaching me anything, it’s to be able to respond to change quickly, without being stubborn. Part of this comes with admitting to your self that you never know it all. Sometimes it may mean being ok with the fact that there is no physical document you can stamp and call your super-duper-efficient process. Or, maybe it’s an evolving, growing, and changing document. You might have to be ok with never arriving at that perfectly honed workflow. You have rely on your skills and common sense to react.
Even if a process never again exists for our industry like it did before, I’m definitely not going to cling to the old processes I used to know for the sake of comfort. It may be worth your while to consider doing the same.
I would love to hear input from anyone and everyone on this topic. I know there are a lot of things out there being tried that either work or don’t work. And I know there are teams and individuals out there that may feel stuck in a certain process for very legitimate reasons. I’d love to know about your situation.