Upon first starting to work at Revelry, Gerard told me, “Eventually we’ll have you designing in the browser and you won’t need to mock everything up in Illustrator, Photoshop or Sketch.”

To be quite honest, this terrified the living you know what out of me. Was I going to be able to visualize every component together so that they were styled consistently? What if I dev’ed out everything and the client didn’t like it? Would I have time to redo my work? Would the vision I had in my head end up being cohesive or would it look like a 5 year old got a hold of a scrapbooking kit?

These thoughts continued to haunt me up until the style guide was completed and I was able to start implementing components. Then the revelation hit me. THIS PROJECT IS GOING SO RAPIDLY!! How? Because all my components I needed were already built and styled.

Where Do I Even Begin?!

I started out with making a style guide — something that can be referred to by both the engineer and myself. I believe these guides are important to ensure that styles remain consistent. Instead of creating the style guide in Illustrator, I created a page in the project and dev’ed it out. I tackled general page layout, colors and fonts first before I moved into the components.

Generally, I know which components I’m going to need. I began with ones like buttons, tables, panels, checkboxes and radio buttons, flash messages, form fields, etc.


You can share your completed style guide with the client so they can get an overall feel for the direction you are heading. From here, I was able to make live client changes. Unlike a style guide that was created in Illustrator, the client is seeing exactly how the end product will look.

Another benefit to designing in-browser is that it is quicker. Let’s say a client wants to make the buttons more rounded. In the style guide I have coded I can easily go in and change the border-radius for all buttons in the matter of a few seconds. However, over in Mockup Land, this becomes a pretty tedious task to change every button.

By the time we were ready to use the components, they were already styled and we just had to input the content. Just like how Foundation has a set of components pre-styled, my style guide worked the same way except it was tailored to a particular project.

The Haunting Questions

The questions that were haunting me quickly began to subside. I was able to build out each component on one page which helped me see if there were any inconsistencies. Because I had the base of the components already built, it was easy to make changes to the styles. I personally liked the fact that the client was getting to see how each component would look in the browser.

Fantasy Land vs. Reality

Last November, I published a post about improving your workflow by making the switch from Photoshop to Illustrator. This can serve as proof of how rapidly the web design world is evolving. In less than a year, the process of creating mockups has become a dated way to design.

When a client asks for mockups it is likely because that is the way the design process has always been done. They don’t know any differently. They haven’t been introduced to a more efficient process. As industry professionals, it is our job to teach clients what we know. What we do know is that spending hours designing pictures of what we hope the end product will look like is not the most efficient way to design. Instead, we should be coding these styles and letting the client take a more hands-on role in the design process.

The biggest difference between mockups and UI style guides is this: A mockup is like a designer’s dream of what the product will be. A UI style guide in the browser is reality. This is about efficiency. Completing the best work possible in the quickest and most efficient way.

Ending Note:

Don’t get me wrong, there still was a need for a few things to be wired up. Mostly the larger/ more complex pages where the engineer and I needed to discuss how it would function. I found that small things here and there are okay to mock quickly. I spent no more than 10 minutes on these wireframes.

As terrified and out of my comfort zone that this pushed me, I’m really glad I took on the challenge. Styling all the components in the browser cut my work in half. I can now say that I have been converted to this workflow. As much as I love you Illustrator, I think its time we start seeing other people.

We're building an AI-powered Product Operations Cloud, leveraging AI in almost every aspect of the software delivery lifecycle. Want to test drive it with us? Join the ProdOps party at ProdOps.ai.