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.



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.



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.



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:

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.


          

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



New Chartbeat Support Site


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

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.