Some will tell you designing in the browser is the best way to work. For the most part I agree it is but it’s by no means the only way to design a website.
Designers workflow, the ever changing steps that we all tweak and modify to suit both our workflow on a particular project and the way clients need to be shown and briefed on how a site is coming along. There is no right way for everyone.
Sarah Parmenter posted about how she can’t design in the browser and it seems to be a “problem” (It’s not a problem) many others experience. I’ve revised my own workflow a great deal over the last year and I do a huge amount of work in the browser and on any scraps of paper I can find but do you know what? For the most part, Fireworks (insert Photoshop if that’s your tool of choice) is still open all day for me and the last freelance project I did included me sending a full set of jpg visuals to the client among other resources.
For the most part, I don’t care what other people say is best practice or what I should do. I do what is best for me, my client and their end users and at work, whatever is the best way for us all to contribute and tweak. It depends on the nature of the project, what the client needs* and quite simply – whatever works best!
My typical design workflow
Unlike Sarah, I do design primarily in the browser these days. My process is pretty simple for the most part:
- Sketch out initial wireframes and visual ideas
- Create wireframes in Balsamiq
- Sketch out HTML structure of project on paper
- Start building HTML structure
- Add in CSS
Now at this point, you’ll be wondering where I do any actual design. The secret is for the most part, design in Fireworks (yes, or Photoshop) can fit into or between any stage above. As I mentioned above, the last freelance project I took on, I was paid only to deliver wireframes and a new visual look and feel for an existing website that the clients own team were going to rebuild in HTML & CSS and update their own CMS at the same time.
A client case for modifying my workflow
Designing in the browser wasn’t entirely practical in this case. So I didn’t. In that particular case my workflow was modified to something like this:
- Sketch out initial wireframes and visual ideas
- Create wireframes in Balsamiq (send for approval)
- Overlay design elements in Fireworks
I did a lot of groundwork with the client to ensure they knew that because they weren’t paying me to build the site, there is only so much that can be done when you’re a smaller part of a bigger process. My aim from the beginning was to take a site that had last been visually updated in 2004 and give it a new lease of life while also accounting for varying screen sizes when it’s built. In a dream world, you’d manage the whole process but sometimes you can’t and you therefore have to be pragmatic.
I sent jpgs for my last project
What I provided this particular client with was a set of wireframes that showed the basics of a responsive layout – a “small screen view” of how the content, navigation etc would flow and a “big screen view” which typically represents a desktop view. On each wireframe, I made notes for their development team on how things would alter and I provided a series of suggested breakpoints for their build. Another reason for doing this was also down to the fact I actually didn’t know when this project was scheduled to be built so I accounted for the two significant breakpoints in layout that were known at the moment – a 320px wide “mobile view” and I decided on a 960px maximum width because on a practical basis, they only had small photos available.
So designing in the browser was simply not a practical use of my time on that particular project so why force my workflow to match what people consider is “the right way”?
For the most part my design process leans heavily towards prototyping in the browser and I don’t think designing in the browser necessarily leads to blocky, predictable designs as I hope we demonstrated with a work project Cutting Edge Knives which was entirely “designed” in the browser with visual assets being the only thing we used Fireworks for.
Use your brain to compliment workflow
There are so many folks pushing so many techniques at the moment it’s often hard to keep track, let alone decide what’s “the right way”. Follow best practice when you can, but do what’s right for you, your team and your client and their users. If that means getting an overall feel for a site in Fireworks that a client can understand and work with – do it.
For many projects, you will probably get the biggest gains from prototyping in HTML because it’s simply an efficient way of working but don’t force your workflow into someone else’s idea of best practice. Use your brain, it’s still allowed!
* Happy client paid their invoice 2 weeks early.