Problem

We were solving the problem of accessibility for our customers, so they could easily access support related knowledge where they would find answers to their questions. But, we were also solving the problem of resource allocation, so the support team would be able to do their jobs better by focusing more on heavily weighted requests.

Research

Design research began with querying teammates and stakeholders about their intentions. I found that customers were having to wait too long, and support reps were having to spend time on, basic debugging that was out of our control anyway.

Additional research included online searches for support sites to gain an understanding of what was currently being done. As well as to gain perspective on what users would expect in a site like this.

Much of the information needed in regards to the features and aspects of the new design were provided by Customer Success via support tickets or customer emails.

Sketching & Ideation

With my newly gained insight, the intentions behind the development of this project, a clear understanding of the problems we would solve, the benefits we would provide, and the goals we aimed to achieve, I was armed to begin materializing ideas.

The main content that we were focusing on in our first release was popular support questions, system status, contact support via — live chat and email, as well as linking to our developer documentation and API references.

Wire-framing & Mockups

In order to share my vision with the team and get feedback early on I created a set of low-fidelity wire-frames. These wire-frames were used as a tool for discussion and a benchmark for development efforts.

As we were iterating on the concept and discussing new features I used this as a time to map out some of the future additions to the site. One of those new features was the ability for user's to self-debug their transactions. Mapping out the user's flow and creating a set of low-fidelity wire-frames helped to continue the discussion and gain insight into what we were adding.

Exposing this flow early on proved beneficial as I found out that our authentication process conflicted with the design's direction therefore we were able to iterate upon this current design prior to tieing up any developmental resources.

Prototyping

The application was biuilt with HTML templates and SCSS documents as well as a bit of Javascript for on-page interactions. The development of this type of prototype helped to save time in the shipment of our initial MVP and sped up the process overall.

Iterations

Iterations on this application came in two waves. The first wave being the addition of transaction self-debug capabilities. While the following iterations focused on developing the Support app into an interactive community and allowing for more user engagement and less company resource drain.

Moving Forward

Continued work has happened on Spreedly support and the system was migrated to a third-party that supports communities and ehnaced self-service. New features and add-ons should be benchmarked with collected data and adjustments should be made to the application as the data suggests.

Additional information

I captured my process through a narrative in this article: Purposeful Web Design.

    • Dane Wesolko - UX/UI Designer
    • David Santoso - Senior Software Engineer
    • Research
    • Sketching & Ideation
    • Wire-framing & Mockups
    • Prototyping
    • Iterations