Designing in the browser used to scare me. Not because it seemed hard but because I thought I would end up with a design made up of a lot of little boxes, something that was so generic and bland I would end up redoing it in Photoshop. That fear turned out to be completely unwarranted. Not only did my designs become more focused, I also completed them faster and got clients involved earlier in the process through interaction and discussion.

It’s not as tough as you think

Design is design. It doesn't matter if it's being done in a software program or being written in code. Designing in the browser isn't any harder than designing in Photoshop. Like any tool you need to use it to learn it and eventually master it. Design is an iterative process, one that is made more difficult by working for clients. It's hard sometimes for clients to picture exactly what you are describing; designing in the browser can get them involved throughout the process rather than just the design phase. Essentially the design and development phases are merging and if you're naturally good at design and front-end development you will take to designing in the browser like a duck takes to water. One major benefit of designing in the browser is that we can design based on realistic expectations. Sometimes designing in software can create unforeseen problems for front-end development. UI elements could be designed wonky or maybe they just don't make any sense, it's hard to explain to a client why you changed something, not because they won't understand but because you've already pitched it in the design and had it approved. Designing in the browser lends itself to the idea of simplicity.

Have a plan

Before I even think about designing I need to have a plan. Just because I'm using a different tool doesn't mean my process changes. I like to have a pretty solid plan before I start designing and I need to know what I am designing, why I'm designing, who I'm designing for, client background, and any service or product information that I will need to focus on. After I determine these things I will have a better idea about what the product is or what the client does, how long they've been doing it, what sets them apart from their competition, who their user base is and what the primary and secondary goals of the website are going to be. I personally like to have documentation of everything. Typically I have documentation for the site map, content, calls to action, and site architecture. By the time I start designing I should have a clear strategy for the design and all of the content should have been collected.

Sketch first

Sketching is key if I'm going to design anything in the browser. I can rough out content areas with pencil and paper, get feedback and quickly iterate into the foundation of my design. I sketch based off of the the plan I described above and I make sure that I have all content areas and calls to action laid out. Sketching should be quick, don't spend a lot of time perfecting anything. It should be solid enough to show to a client but sloppy enough that you can get them finished in less than an hour. Next I like to prototype the site from my sketches in HTML and CSS. The prototype is a lot of gray boxes with text and images for placeholders. The gray boxes act as containers for content when I actually start designing. The biggest benefit in prototyping with code is that the client can interact with the prototype and see how the site architecture works, that way if anything is off or needs refined we can handle it now rather than on launch day.

Style tiles

Before we can start designing we need some sort of style to base our design off of. We need to determine the colors and fonts we will use with potential textures and patterns. This is where style tiles come into play. Style tiles were created by Samantha Warren and I have been using them for a while now. They help clients see an early and very simple style guide that we can use to start designing with. I like to create several of these to see which the client prefers that way I can narrow it down to one. I find that these are also very important in the approval process and helps prevent outright rejection.

Design

Now we're ready to start designing. If you're used to designing in a software program like Photoshop or Sketch this isn't much different. Using our prototype file we start to add mock content in our markup. At this point we know exactly what is going into each content section in the markup and the grid has already been defined so it shouldn't take that long. Now I'm going to start layering styles on my content. I'm going to add base styles for color, typography, and layout. Once the base styles are finished I will step away and look at it. I like to screen shot certain parts of the design to reference later.

Refinement

Once I'm satisfied with the base layer I like to take notes on what to refine. Based on those notes I will most likely use Photoshop or Sketch to add texture or anything with a tangible feel. Photoshop and Sketch are great tools to refine complex UI elements fast so I save anything that might be a pain to code out more than once The reason I do this is because I want my codebase to be lean and clean and the more you code, comment, and delete, the more sloppy and bloated your codebase becomes.

Save and reuse common patterns

If you had to design in the browser from scratch each time, things may seem like they take forever but if you start from a custom base, a framework, you can eliminate any repetitive steps. To start with I have a custom version of Initializr that I use with a custom responsive grid built in Sass(http://sass-lang.com/). Using a custom framework gives me a head start for prototyping and design. Having a library of common UI patterns is also a great way to build a fast prototype and it makes designing in the browser more efficient. I use Sublime Text to code and one thing that I have learned to take advantage of is the custom snippets you can create. I've added several variations of navigation, lists, sidebars and other common elements to my snippets list so I can quickly place them in my markup with a simple action. I also use accounts on Codepen and JSFiddle to save patterns. Dan Cederholm created a great Wordpress theme for storing common patterns called Pears. It uses posts to store code which you can edit live in the front-end to test and preview changes.

Conclusion

Practice and practical application will make you better at designing in the browser. Chances are if you do any sort of front-end development you already have a base framework to start from and you already have some common patterns to use. Now all you need to do is start designing in the browser and eventually you will come up with a workflow that is efficient and works within your process. With practice you will only get faster.