Context
Moxo (formerly Moxtra) began as a team collaboration platform focused primarily on document annotation and sharing. A few years after launch, the company shifted to developing a client portal platform that provided businesses with a configurable white-label collaboration app.
Although this new product focus was successful, it became hard to scale quickly because of the effort required from the sales and solutions teams to onboard each business.
Problem
My task was to drive a significant boost in new users by enabling potential customers to sign up on our website and use the platform independently, without direct assistance. Initially, we planned to add a free trial option and a self-service onboarding process for our existing product.
However, it was clear that our product’s complexity, with its massive number of features supporting various business types, would be a significant barrier to self-service adoption. No amount of onboarding could reasonably set up our potential users to see value in the platform on their own.
Ten years of constant feature releases left us with a massive collection of powerful functionalities that very few could navigate effectively.
Defining The Solution
To address the scalability issue and improve user adoption, I proposed two approaches:
Overhaul the existing product: This involved tackling technical debt and streamlining features to clarify their purpose. The main concern with this approach was the risk of alienating customers who were already familiar with how things worked.
Create a separate, focused product: This approach involved developing a new product tailored to our most common use case that would be simple enough to use without setup and training sessions.
We chose the second approach because it allowed us to leave behind our previous product’s technical limitations and unnecessary features while creating a more focused solution. This strategy also wouldn’t upset existing users who were content with our previous product.
Understanding Our Users
With a general plan for tackling the growth problem, I collaborated with my teammate Yingzi to better understand the inner workings of our target demographic: small to medium-sized businesses providing service over an extended period.
Without the option to contact them directly, we opted to use case studies, business websites, and the limited usage data from our previous product for our research. We created process maps of how they do business and highlighted any potential pain points in their customer interactions to ensure our new product would immediately deliver value when used.
Building process maps helped clarify the common threads that existed between the variety of businesses we were targeting.
We found that most of these businesses and their customers lacked a proper “central hub” to communicate and work within for their projects, instead relying on text messages and emails to drive their business.
While our previous product was intended to act as this central hub, the platform was structured around the customer rather than a project. This meant that businesses and clients needed to navigate between several group, direct, and workflow conversations to collaborate effectively.
Service Dashboards
Armed with a better understanding of our users’ needs, I began work on a new platform centered around service dashboards.
These dashboards combine all necessary components for businesses and their customers to manage and collaborate on service projects (such as home renovations or landscaping services) on one page.
Each service dashboard has a space for the company to add branding, as well as three main features:
The process tab provides a clear overview of the entire project lifecycle, highlighting when action is needed from each user.
Process Tab: The most important element of the dashboard is the process tab, which serves as the definitive source for tracking project status and identifying the actions required from both the customer and the business. A process consists of native and third-party interactive action items, all organized within containers known as ‘stages.’
Stages group action items together with a title, optional description, and dynamic status to visually represent the significant phases within a project. This concept aligned closely with how businesses typically operate and allowed us to support sequential and parallel step completion and a “not ready yet” state for actions—two frequently requested features in our previous product’s workflow system.
Documents Tab: The documents tab, located next to the process tab, serves as a centralized repository for all project-related documents. It includes files the business uploaded, copies of signed contracts, and completed forms finished within the project action items.
Communication Sidebar: This feature offers a dedicated, secure channel for businesses and their customers to discuss the project and conduct video calls. Consolidating all project-related communication into one space improves transparency and simplifies information tracking for all users.
Business & Customer Platforms
Because service dashboards are intended to help businesses connect with their customers, we structured our product to have two main experiences: a “business platform” and a “customer platform.” The business platform includes advanced features for managing multiple projects, customers, and employees. The customer platform presents only the dashboard(s) relevant to that customer. Both share a common design for service dashboards, with certain edit permissions and settings exclusive to business users.
The highest priority for the business platform was ensuring it was structurally correct from the outset to help lay a solid foundation for our product to follow in the coming months. I repurposed many pre-existing page designs and patterns from our previous product to save engineering resources and deliver within our ambitious three-month timeline.
Admittedly, many corners were cut here, and many critical functionalities that businesses need are missing. Still, this solid foundation should allow us to iterate quickly moving forward.
Given the nature of the product, the customer platform’s design was relatively straightforward. Unlike our previous client portal, which often overloaded customers with complex features and conversation types, this new design focuses solely on presenting the service dashboard.
While most customers typically work on only one project with each company, a project list menu for easy navigation between multiple projects appears when necessary.
Bringing It To Mobile
Once I finished delivering all the necessary designs for our web platforms, I began adapting them for mobile screens. For customers, this meant ensuring our web app had proper responsive behaviors, which we had neglected in our previous product in favor of native app experiences. While business users might be expected to download our app, their customers generally dislike the idea of having to download an app just to chat and collaborate with their service provider.
Fortunately, making the service dashboard responsive for customers was relatively straightforward. It only required defining a collapsed behavior for the communication sidebar and adjusting navigation bar components to ensure they had correct close and back buttons.
Designing the mobile app for business users was more complex. Although pre-existing page designs and patterns from our previous product accelerated the process for most pages, the challenge arose when designing the service dashboard for mobile.
Unlike the mobile web service dashboard, which is generally used briefly by customers for a single project, the mobile app needed to accommodate employees managing potentially hundreds of ongoing projects. This meant carrying over the floating action button entry-point for the communication features wouldn’t work well. After exploring traditional solutions like top navigation tabs, I landed on a custom bottom sheet-toolbar hybrid.
Swiping up on the drawer brings up the last selected tab, while tapping a tab directly opens the respective tab.
This design differentiates itself from the app’s base-level tab bar while visually emphasizing these secondary functions as “supporting” the primary process. Swiping up opens the chat view by default, while tapping a specific tab opens that tab. Though unconventional, this design feels intuitive and effectively solves the challenge of maintaining easy access to all functionalities within a limited screen space.
Final Thoughts
After developing this first version, we handed it over to our sales team to gather initial feedback on whether there would be interest in a product like this. Early feedback was highly positive, with our sales team reporting that this concept was straightforward to sell and generated a lot of excitement from our target users.
Planning and designing a new product from the ground up to launch within three months was one of my career’s most challenging and rewarding experiences. It wouldn’t have been possible without my teammates’ constant feedback and support!
