Scalus is a task management platform for companies with complex process and compliance requirements. Companies use Scalus to ensure there is a consistent, scalable operational infrastructure that allows for the easy onboarding and offboarding of clients/personnel and project automation. Scalus’ primary base is the accounting industry; secondary industries include IT, manufacturing and investment services.
A major development at Scalus was to test the viability of a self-serve market. Our existing user base included large enterprise businesses. Our new user base would be small and medium-sized businesses. The business goal was to increase (1) the lifetime value of each customer and (2) the product’s virality.
To successfully pivot we needed to make a number of onboarding and support improvements. Scalus’ original method for onboarding enterprise businesses was to use a white-glove, concierge method. For our new self-service needs we produced over a half a dozen onboarding projects.
The self-serve push was the combined efforts of Design, Customer Support, and Engineering. I worked as part product manager, part researcher, part UI designer.
Qualitative and Quantiative Research
Our research goals were to uncover how effectively we were communicating Scalus’ value and features– specifically perceptions from our ideal customer personas. We also needed to get a baseline of usability problems within the application. We used both qualitative and quantitative analysis to achieve our research goals.
To gather qualitative information, I performed contextual interviews and usability tests on two groups: new users and existing users with little familiarity of the product. Here was my process:
- I began interviews by asking about people’s current tools. I wanted to understand what was working and wasn’t working in their current workflows.
- Then I asked them to visit Scalus’ marketing site on their device and recount their top takeaways. I wanted to uncover what information resonated and what information was completely missed.
- Once in the app I asked users to perform a short list of tasks to uncover usability obstacles that would hinder early engagement.
To gather quantitative information, I worked with the Director of Engineering to identify user patterns in Mixpanel: where customers drop off, where they spend more/less time, how many team members they invited, how many tasks and projects they created, etc. Due to a small sample size, we did not make product decisions based on the analytics. Instead we used Mixpanel to identify trends and to substantiate or negate qualitative findings.
Marketing Site Discoveries
• Audience Perceptions: Users were unclear for whom the product was intended and if it was for them.
• Terminology Barriers: Users noted that the language seemed ‘too complicated’.
• Feature Identification: Half of users couldn’t state high-level features/benefits after visiting the marketing site.
• Immediate Value Problem: Users struggled to discern the value of the product because they were overwhelmed interpreting the array of features. We heard, ‘the page is overwhelming’, ‘there are too many steps’, ‘what do I need to do next?’
• Immediate Use Features: Initially the product heavily favored admins who had the purchasing power. When workers joined they found Scalus to be functionally limited and less useful. Worker dissatisfaction led to admin dissatisfaction, and therefore slow conversion rates.
• Templates Concept: Although customers agreed a template system was beneficial in the long-term, in the short-term translating businesses processes into template-form was challenging and easily procrastinated. Templates being an admin-only feature compounded the problem and left workers feeling disenfranchised and unable to assist.
To address these various issues, we modified features and added new features to support a simpler, more streamlined onboarding process.
Strategy + Concepts Phase
To ensure that our solutions were targeted and effective we used two primary personas in making product decisions: ‘Annie’ and ‘Manny’.
- Annie, our persona for the worker, represented the worker whose biggest frustration was needing to keep track of myriad client details while simultaneously providing her manager with (seemingly) endless status updates.
- Manny, our persona for the manager, was frustrated by the number of complications that arose from (seemingly) repetitive tasks and projects.
Given that we had two personas with sometimes conflicting motivations and frustrations, we needed to understand what the experience was like pre-self serve for the worker and the manager, and to ensure the experience we were building was effective for both. We utilized customer journey maps throughout the process to identify user flows and identify gaps/opportunities in the onboarding experience.
Before jumping into the user interface and interactions, I performed competitive analysis of other products solving similar challenges. I’ve included a sample list of self-serve onboarding solutions:
- Post-registration welcome page (static information)
- Features tour (static information)
- Features tour (dynamic – users learn features by doing)
- Zero states
- Pre-populated sample data
- Getting started checklists
- Contextual help text
- Contextual help videos
- Help libraries
I use competitive analysis in my process to inspire but am always careful to not plagiarize. No matter how pretty or clever a product may look to an outsider, plagiarism is dangerous because it assumes a shipped feature achieved its targeted goal (which it may not have) and that their users are your users (generally never).
After analyzing the quantitative and qualitative data, our personas and the competitive analysis the product team collectively decided upon a list of solutions:
Immediate Value Product Solutions:
- We built in progressive disclosure to improve users’ perception and recall by reducing the visual load of the interface and increasing the emphasis on a single and clear next-step action.
- We added a contextual help tour in strategic areas of the product that were previously identified in usability tests as being confusing, difficult or overwhelming.
Immediate Use Product Solutions:
- We created a features video that introduced the Scalus product in an approachable manner.
- We corrected task flow issues by opening product permissions and designing a new feature where team members can be invited in-flow.
- We built an ad hoc project feature that allowed workers to immediately find use and value in Scalus.
- We improved product support by introducing Intercom and creating targeted email campaigns by user type.
Abstract Templates Solutions:
- We added pre-loaded templates to serve as examples of how Scalus could be used and to demonstrate best-practices in the setup of templates.
- We created a Convert Project to Template Feature which allowed users to first build the project, run the project then decide they wanted to turn it into a reusable template in one click. This flow fit much closer to our users’ mental model.
For these projects I used a template UX Doc to help organize and think through problems in the research and strategy phases of the project. The document covers both product and design thinking. On some of the above projects the Director of Product provided more product data and direction and on others I owned the project from business requirements to post-launch analysis.
Below I elaborate on how I moved the projects into tangible sketches, prototypes and mockups.
Interactions + UI Design Phase
Once I begin to complete my UX Plan doc– created problem and feature hypothesis, identified potential risks and developed design stories– I’m ready to move into the tangible work of sketching. As a practice I develop 5+ rough sketches: 1-2 moderate designs, 1-2 alternative designs and 1-2 wildly different sketches. Even if I feel very confident about one particular design, I explore alternative designs. Considering alternative designs at the sketching stage helps reignite creativity when the logistics of the UX Plan can overwhelm inspiration. Below are a few sample sketches while thinking through the contextual help project.
At this point in the project, I will bring in the lead developer to review the top 2-3 sketches and design stories. We discuss how these solutions could affect the current product architecture and very early estimations on technical difficulty.
Often this meeting leads to further narrowing of the solutions and from here I’ll move into prototyping. In determining at what fidelity a project should be tested, I consider the necessary degree of fidelity required for validly testing and the cost of the prototype. On the gamut of testing, at the cheapest is hallway testing with mockups and sketches, onwards to low-fidelity wireframe prototypes, high-fidelity Invision prototyping to the most expensive, coded prototypes.
As a general rule I error on the lowest fidelity protoype that will deliver valid, reliable results. In the case of testing first perceptions and functionality, hallway testing with sketches is reasonable. In other cases of testing where you want to determine if the navigation or layout is correct– without having the user get distracted by colors or fonts– wireframe tests are best. If the usability of a specific animation needs testing, high-fidelity, animated tools like Marvel or Framer will provide the closest approximation to the finished feature.
At times tools such as Marvel and Framer can take as long or longer to prototype than the development of the actual code. In instance such as this, I usually bring in the VP of Engineering to discuss reallocating development resources for prototype builds. Which in the end is an overall better investment in costs.
I primarily work in Sketch for interaction and UI design. Unlike many designers who keep wireframes very basic, I consider it important to add real information into the sketch wireframes. Because I’ve sketched with real content I know which designs won’t work due to content and layout constraints.
The number of design options expand again as I explore visual design options. Here are sample screenshots from the Sketch file for a contextual tour.
Marketing material, like UX projects, followed a very similar process at Scalus: understand the data (research), strategize solutions, develop early sketches/designs, get feedback (stakeholder review + usability testing).
For example, in the development of the feature video, we engaged the services of a remote video company. The top features we wanted the video to highlight were (1) tasks moving from person to person, (2) 24/7 status availability and (3) reusability of templates. We created the storyline, sent an early draft to the contracting agency, and provided visual direction so that the video adhered to the Scalus brand guide.
Development + Deployment Phase
Design and engineering meet well before the traditional spec hand-offs. Interactions begin when design presents early research and sketches to the assigned dev lead. The dev lead can already begin to advise on the complexity and size of the different solutions.
After the meeting the dev lead has time to do early exploratory work, consult with colleagues and think through the project. In some cases there is a need to test very specific interactions that wireframe/high fidelity testing cannot accomplish. In those cases dev and design will have an additional phase for building a functional prototype. But from the initial meeting until the official hand-off to dev, design and the dev work together.
Below is an example of the formal hand-off of specs to development for the Contextual Help Welcome Tour. This document is only handed-off after the initial dev-design kick-off meeting, usability testing, and visual design phases.
Quality Assurance Testing
Once engineering has completed 50-70% of the developed they pull design in to review the progress. If at this point there are potential bugs or unexpected complications in the code, we re-prioritize how to scope features against how we usability tested (and whether our decisions to scope would nullify the research or require additional usability rounds). In some cases, there were bugs or unexpected complications in the code whose costs would overwhelm the added value and therefore scoped the project accordingly.
Results + Insights Phase
Demo of the shipped product for Ad Hoc Project, Progressive Disclosure, Flow Corrections (Team Members Component, Convert to Template) and Intercom Build.