Archive for the ‘Design’ Category

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.

photo1
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
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.

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!

newsite
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.

This is the first post in a series on how we used the design process to understand, define, ideate, and build a brand new support site.

My favorite part of being on the Chartcorps, our client support team, is that all of my teammates genuinely care about and empathize with our clients. We don’t just train editorial and advertising teams, debug code implementation, and provide general support — we’re always trying to build a better product experience for all Chartbeat users.

This starts with customer feedback. At Chartbeat, and especially in the Chartcorps, we’re all about using data to drive decisions. So, my Chartcorps teammate Sam and I decided to team up with our designers to critically approach the challenge of creating a unified support experience. In doing so, we learned why design collaboration and a comprehensive support system are integral components for any software product.


resource inventory
Beginnings of our brainstorming process

Phase 1: Understand

One of the fundamental problems we wanted to solve for was the lack of a centralized location for Chartbeat’s support resources. We noticed, as a team, that we frequently received similar questions from our users — often about where to find implementation instructions or how to learn more about our data science.

While of course we love talking to our clients, we came to realize that one-on-one client communication (for any and all issues) is not a scalable support model. We also took into account that many users were probably trying to find the answers to their questions without having to email the support line.


Screen Shot 2015-07-01 at 1.11.22 PM
An example page from our old resource site


The content library we had at the time was difficult to navigate. The majority of implementation docs were static PDFs. Educational videos and case studies were scattered across different shortened links. Version control, maintenance, and innovating new support methods were confusing and cumbersome.

So we took a step back and re-evaluated. How could we make communicating and answering our clients’ needs a more efficient process across multiple channels?


Phase 2: Define

Before putting anything down on paper, we first needed to figure out exactly who we were designing for. Since our customers have extremely diverse sets of roles, workflows, and team sizes, the Design Team suggested we use Job Stories as a way to approach this problem. This meant ignoring user personas and instead defining what ‘jobs’ people were ‘hiring’ our support site to do.


job stories
A job story format (Source: Medium)


We talked through a lot of examples of why someone would come to a Chartbeat support center and what outcomes they would be expecting. For example:

  • When looking to implement the Chartbeat code, I want to find full technical documentation, so I can get my site up and running.
  • When using Chartbeat for the first time, I want to know what specific metrics mean, so I can put them in practice and incorporate the tool into my daily workflow.
  • When I have a specific question already formed in my mind, I want to quickly and easily find the answer, so I can go back to using the tool.
  • We weren’t trying to design just for “developers”, “homepage editors”, or “account admins”. Instead we wanted to design a single support experience that offered everyone an intuitive path to their expected outcome, whatever that may be.


    Phase 3: Ideate

    Then came our first big challenge: to step out of the comfortable realm of client experience and feedback, and into the creative and practical world of UX design. Enter, the whiteboard.


              whiteboard

    Luckily we had a few main points to help get us started; the three general support journeys we imagined users taking, and a need for a singular site architecture that began at a master landing page. Eventually we aligned the resources and content that already existed in our internal library with our three main journeys, which became ‘Documentation’, ‘Education’, and ‘FAQ’.


    SupportSiteshot
    New Chartbeat Support Site


    Now that we outlined the basic structure, we turned our attention to the smaller details:

  • How do we visually represent product hierarchy?
  • How can we encourage exploration between products and categories?
  • And how many clicks should someone have to make to arrive at their expected outcome?

  • Conclusion

    We started this project as an opportunity to solve a very real problem for our client base and brush up on our technical skills, but we knew that if we were going to take the time to build a whole support center, we had to do it right.

    This meant committing to the entire design process — something we didn’t know would be so challenging. Fortunately, we had the support and experience our Design Team to guide us and give us feedback along the way.

    Stay tuned for part two. Next week, Sam will get a little more technical and talk about how we prototyped, built, and tested our product.