ServiceAtWrk Redesign
What Is ServiceAtWrk
ServiceAtWrk is a comprehensive field service management app and CRM that is modular, customizable, and scalable for various industries. It allows businesses to efficiently manage staff, track products and deliveries, send invoices, conduct stock checks, and communicate securely through in-app chat for both team and job-specific discussions.
Project Background
Customer Goals
I interviewed our customers and their workers that are using the ServiceAtWrk application to identify the main adaptations that our customers would benefit from the most. I compiled those responses into a set of requirements for what our MVP must contain.
Areas of focus to acheive goals
To solve these challenges, I led a full redesign of ServiceAtWrk focused on five key objectives:
What The Project Started With
Since its inception, ServiceAtWrk's development process was disjointed. Features were added reactively, often without research or design input, leading to a fragmented user experience. The lack of integration with modern tools like Figma and the absence of design tokens made even simple updates costly. Each page felt like its own isolated system, creating confusion for users and friction for the team.
Poor usability and inconsistent UI
Problem
The job details page was cluttered and inconsistent, making it difficult for users to quickly locate essential information. Critical actions, such as status updates, notes, and assignments, were buried, which slowed down workflows.
Why it mattered
This screen was central to ServiceAtWrk, as every engineer and dispatcher used it daily. Its inefficiency made the entire product seem sluggish and unrefined.
Approach
I performed a comprehensive feature audit and engaged with internal users to determine the primary actions used daily and those that were secondary. I then organized a clearer hierarchy, categorizing information into logical sections.
Initial concepts
A streamlined job details page that highlights the most crucial information immediately, with expandable sections for additional details. Status updates and communication were relocated to a fixed, easily accessible area.
Concepts
Wireframing
Initial experiments had spacers between form elements, mimicking the floating card design from the original design. However this added unwanted visual clutter to what was already visually complex floating card design. The stake holders also agreed
I tried implementing a progress bar to help users navigate the Start, Active, and Exit tabs. However, developers strongly opposed this because our dynamic job templates would necessitate a GUI option to support them.
High Fidelity
A streamlined job details page that highlights key information upfront, with expandable sections for additional details. Status updates and communication are now in a fixed, easily accessible spot.
Solution:
Changes Made:
The Start, Active, and Exit tabs guide users through the necessary data at each job stage. This approach divides job requirements into manageable pages, providing relevant information to assist users effectively. For instance, a user in the Exit stage would benefit more from a 'sign off' section than a 'pre-worker inspection' card.
In App Chat
Problem
Why it mattered
Without dependable in-app communication, ServiceAtWrk risked losing a key value proposition: consolidating all job information in one place. Support staff resorting to WhatsApp to communicate with drivers who refused to use the app could lead to confusion and inefficiency due to fragmented communication.
Approach
I analyzed how popular chat systems like Slack, Teams, and WhatsApp structured group chats and conversations. My focus was on optimizing placement, enhancing clarity, and ensuring that messaging administrators and relevant job contacts were easily accessible from within a job, all while maintaining a clean and modern appearance.
Solution
Consistency
To ensure a cohesive experience and streamline development across sections of ServiceAtWrk with similar user interfaces, I created a series of cards based on the group chat card for Dataset and Form cards as well. This approach helped maintain a visual language that users could easily recognize for items with similar purposes.
Impact
Take aways
Although the card designs in his MVP version of ServiceAtWrk are not visually stunning, they convey necessary information that developers who had previously struggled with uniform development can create with low chance of error.
My next version would consider improving the uniqueness between cards.
Onboarding Flow
Problem
Why it mattered
Onboarding serves as the initial impression of ServiceAtWrk. Ineffective onboarding results in frustrated users and lost sales conversions. The application lacks a method for active users to learn or enhance their skills without enduring significant trial and error or requiring ServiceAtWrk customers to pay for basic tutorials.
Approach
I collaborated with the sales and operations teams to pinpoint the primary friction points for first-time users. We designed a step-by-step flow that introduced only essential registration tasks. I then created a simple registration page and a support contact form, all supported by clear help text.
Impact
Where we started
Collaborating with the sales and operations teams, I identified the key obstacles faced by first-time users. We developed a streamlined process that focused on essential setup tasks, accompanied by clear and concise help text.
Before (left): The registration process was complex and prone to failure. Key pain points are highlighted in the flow diagram—for instance, returning users could not sign in or re-register with a previously used email because the passcode token never arrived.
After (right): The registration flow has been simplified. Users can now complete registration in three screens, compared with a minimum of six screens for a standard registration or 12+ screens when logging in or accessing the demo via the CRM or AtWrk website.
I streamlined the login and registration screens to three dialogues, showcasing the CRM behind the popups. This approach utilized M3 design system UI elements to establish a standard that enhances trust during the onboarding process.
I placed the progress indicator at the top of each page to ensure users always knew their position in the process.
To help users learn and navigate the ServiceAtWrk system, I introduced a Help Center in the navigation bar, featuring higher contrast and larger text for better visibility.The Help Center integrates our physical documentation through an AI agent called Danswer and provides a self-hosted, customer-facing documentation platform using Bookstack.
A final implementation of this setup would be;
To address point 1, we could use a self-hosted documentation site via Read the Docs or MkDocs. I deployed an Ollama instance using Docker Compose to aggregate and search our physical documentation folders, similar to Danswer. This setup could be integrated with our self-hosted AI model, enabling users to ask questions and interact with the documentation directly.
I developed comprehensive documentation for all ServiceAtWrk features, organized into Worker, Administrator, and SysAdmin manuals. To ensure relevance and clarity, I interviewed customers from each role to identify the key features requiring documentation and determine the appropriate level of detail. I also researched self-hosted communities, such as TrueNAS and Proxmox, to understand how small companies approach product documentation.
The documentation was structured to cover all tasks and features necessary for each role, forming the foundation for AI ingestion into Ollama. Additionally, I established a handover process from development to support, improving communication and collaboration between developers, QA, design, and the support team.
Impact
Our support team Our customers found that they
Shared Multi Platform UI Elements
Problem
iOS, Android, CRM, and Support portal all use different UI elements. The web platforms utilize an unlicensed and outdated Rapido v3.2 template, while the current mobile and tablet applications employ a custom UI based loosely on a mix between M2 and M3, differing between iOS and Android.
Why it mattered
Approach
Impact
Solution
To ensure a cohesive experience and streamline development across ServiceAtWrk sections utilizing similar technology, I developed a series of cards for Dataset, Group Chat, and Form cards.
IOS and Android UI Parity
To ensure a unified experience and simplify development across sections of ServiceAtWrk that utilize similar technology, I recommended a design language that could support product development with reduced effort and overhead. This approach enabled me to design a single response, share a Figma developer link, and hold developers accountable if they created something that did not align with the design. The main areas of contention were the dataset list, group chat, login, and form list.
I selected a consistent style for buttons and text boxes, ensuring the background contrast is appropriate.
Consistency
To ensure a cohesive experience and streamline development across ServiceAtWrk sections utilizing similar technology, I developed a series of cards for Dataset, Group Chat, and Form cards.
