This is the second post in a series on how we used the design process to prototype, build, and test a brand new support site.

By collaborating with our designers, the Chartcorps (our client support team) was able to create a brand new support site experience from scratch. Last week, my teammate Chris walked us through the first three steps of our design process that began with understanding, defining, and ideating a solution to a problem. This week, I’ll be discussing how we took those ideas from the whiteboard to the web in the next three phases: prototyping, building, and testing.

Phase 4: Prototype

In the Ideate phase, we were able to lay out the informational groundwork, but we still needed to figure out details around navigational flow and visual consistency.

An early mockup of navigation and flow.

Chris and I used Sketch and InVision to generate quick wireframes to get a better sense of how users could interact with the site. We made a few versions to compare and get feedback from the rest of the team and our designers — an incredibly useful step for planning how to scale our site for future resources.

After finalizing the overall structure, we moved on to higher fidelity mockups to find a consistent style and voice for our product. We wanted the support site to feel like an extension of the tools that customers were used to using, but also serve as an easy channel to connect with us.

Thankfully, our designers had already put together a style guide that helped us quickly get from wireframes to mockups. We replaced our Lorem Ipsum with real text, drew our own illustrations, and decided on a unique, but integrated, color theme.

Palette from our Style Guide

We found that prototyping was a quick and efficient method to diverge and converge on many ideas with constant revisions along the way. And since Chris and I were new to coding, prototyping helped us nail down design decisions before tackling code.

Phase 5: Build

When new members of Chartcorps come on board, we encourage everyone to get comfortable with code using resources such as Harvard’s online CS50 course, Codecademy, and Learn Python the Hard Way (which Chartbeat Developers actually TA once a week for the whole company!). Chris and I had also learned a lot on the job, but we really wanted to take all this knowledge and build something ourselves.

We were familiar with writing HTML, CSS, and JavaScript, but putting everything all together in a cohesive, scalable system was a brand new experience for us. Enter, the static-site generator—we choose Jekyll.

There are a lot of different options out there, but after we experimented with both traditional CMS’s and static-site generators, we found that the latter offered better version control and flexibility for what we were trying to build. Jekyll was our favorite because it was beginner-friendly and a few of our designers had experience using it.

While building the site, we found a lot of parallels with the design process. We spent a lot of time understanding, ideating, and prototyping different file structures to reflect the design of the site from the user’s view. We ended up using a cascade of templates and section-specific files to have a modular site that new members of Chartcorps could easily add to or edit.

Phase 6: Iterate & Learn

After many weeks of coding we were finally at the point of launch! We decided to start off with a soft roll out to test and get more feedback.

We held various focus groups with members of our Product Outreach Team to see if they could find all the resources in their new locations. We also attended the design review meetings that our Design and Marketing teams hold bi-weekly for additional feedback.

Of course the last step of any design process is continuous iteration. Since this is our first run at building a whole support site from conception to execution, we’d love to hear your thoughts: What are we missing? Does the structure make sense? Did you find what you were looking for?

Just as Chris and I used this project as a chance to practice and learn, it’s had a similar effect on everyone on Chartcorps. One of our teammates, who’s more interested in data and integrations than front-end design, used API endpoints from the Chartbeat Status Page to power a real-time widget to instantly tip people off to any downgraded performance issues!

Check it out, we’re live!

The Support Site project that Chris and I set out to build is becoming much more than just a side project for us. It’s turning into a way for all members of Chartcorps to explore and develop their technical skills and interests.

For Chris and me, it’s been learning more about what the web design process looks like in software companies, and how something goes from sketch, to design, to launch. And since we had such a great time collaborating with and learning from Chartbeat design team, we’re going to continue publishing blog posts about our Design culture.

P.S. Want to join our team? We’re hiring: Chartcorps, Product Design, and Marketing Design. Check out the openings here.