ServiceAtWrk

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.

ServiceAtWrk stands out from conventional solutions by offering flexibility. Companies can activate or deactivate features according to their requirements or budget, allowing smaller businesses to enjoy a customized, high-quality experience without incurring significant expenses.

Main pain points

I identified several core issues that guided the redesign strategy. The main challenges were:

Inconsistent usability and UI: Each page used different spacing, padding, and interaction patterns, resulting in an unintuitive user experience.
Reactive feature development: New features were introduced hastily, without proper consideration for layout, hierarchy, or the broader product experience.
Sales friction: The lack of visual and functional cohesion made it difficult to demonstrate the product effectively to potential clients.
Inefficient handover and accountability: Misaligned processes between design, development, and operations slowed delivery and increased the risk of errors.

Key paths to improvement

To solve these challenges, I led a full redesign of ServiceAtWrk focused on five key objectives:

Unifying the design language: Established consistent spacing, typography, colours, and reusable components to create a cohesive visual identity.
Enhancing usability: Streamlined core workflows - such as job management, chat, and onboarding - to make them more intuitive and efficient.
Modernising the technical foundation: Adopted token-based design systems for smoother integration with development.
Ensuring cross-platform consistency: Aligned the iOS and Android experiences to deliver a seamless and familiar user journey.
Advancing business goals: Elevated the visual and interaction design to reduce sales friction and boost customer confidence.

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.

As an engineer using ServiceAtWrk, I need to contact my manager through a dedicated job chat on the job details page to improve communication and reduce delays.
As an engineer using ServiceAtWrk, I need a clearer, more guided way to progress through the stages of a job so I can complete tasks efficiently and with fewer mistakes.
As a sales representative for AtWrk selling ServiceAtWrk, I need to onboard users simply and cleanly, in a way that intuitively guides potential customers - especially those who aren’t tech-savvy - through setting up their first user.
As a user returning to the onboarding demo system, I need to log in and access my existing demo brand so I can continue where I left off, rather than creating a new brand or resetting my password each time.

Project Roles & Timeline

Timeline

18 months Sep 2023 - Mar 2025

Team

UI / UX Designer
2 Engineers
COO Ops Manager
COE

My Role

Qualitative Research
Conceptualization
Design
Usability testing
Dev handoff
Product Owner

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

Job Details

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.

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:

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.

I chose to discontinue using floating cards for forms as they proved ineffective for endless scrolling. To estimate job length, I relied on our existing customers' data, which better suited the longer forms in my tests.

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

The chat feature saw low adoption because it was buried within job pages and lacked consistency across platforms, leading teams to rely on WhatsApp or phone calls instead.
Both the chat and group chat functions were underdeveloped, resulting in a poor and fragmented user experience.

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

Relocate the chat feature from the job details to a more prominent position by placing a chat button next to the primary action. Redesign the group chat page to streamline the layout, incorporating tags, favorite, and mute functionalities. Implement modern features like last message previews and update the chat interface with contemporary chat bubbles and consistent styling across iOS and Android.

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

Encouraged users to return to in-app chat for job updates, decreasing reliance on third-party communication tools.
Enabled the foundation for advanced features such as attachments, video calls, and group chat tags that control access by user type.
Established a consistent development approach for similar assets, reducing workflow variance and easing the transition for developers.

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.

Group chat card could left align description text and tags
Dataset cards are designed to have data points switched on or off. This isn't conducive to consistent UI language. The technology behind the MVP the image has the; description, tags; dataset ID togglable. I would consider enforcing a minimum requirement of data for the dataset card on the dataset list then incorporate an expand button to view more details. Our customers found that they

Onboarding Flow

Incomplete process

Problem

High abandonment during setup: Onboarding screens felt rushed and failed to clearly explain features or benefits, leading new users to abandon the app.
Broken demo links: Users could not return to the demo without creating a new account, preventing seamless exploration.
Email verification issues: Any previously used email failed verification, forcing returning users to create a new email to access the demo.
Excessive and unexplained data collection: The login process requests unnecessary information, making users wary and less likely to complete signup.
Limited in-app learning support: Users cannot explore or understand features without raising tickets and paying for AtWrk sessions. The “support” button is a broken link, redirecting to the internal dashboard meant for existing customers.
No guidance for demo users: There is no documentation, tutorial, tooltip, or first-time walkthrough to help users understand the app.

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

Reduced early drop-off during onboarding.
Enabled sales demos to feel smoother and more professional.
Helped smaller clients get up and running without hand-holding.

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;

Public documentation site
Selfhosted AI Model
AI model that can read the documentation that we write

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

Improved communication and collaboration between the support team and development.
Provided customers with clearer, role-specific guidance, reducing confusion and support requests.
Established a foundation for AI-assisted documentation and self-service support.

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

Increased design workload: Maintaining separate design systems for multiple platforms requires significantly more effort.
Inconsistent user experience: Features built with varying UI elements across platforms force users to learn multiple approaches for the same task, lengthening the learning curve.
Disjointed perception for new users: Inconsistent platform experiences make the product feel incomplete, outdated, and difficult to learn, which can deter new customers.

Approach

Proof of Concept (POC): Developed POCs to convince developers to adopt Flutter, enabling a single codebase to support multiple platforms.
Cross-platform asset audit: Reviewed mobile app versions to identify reusable components for the web, including login flows, navigation, text boxes, and typography hierarchies.
UI/UX redesign: Executed a complete interface and experience overhaul, aligning the product with M3 design standards.

Impact

Validated workflow: The POC confirmed that the Figma-to-Flutter pipeline functions effectively.
Enhanced UI/UX: The redesign improved text legibility, standardized button placements, and made text and search boxes more visible and interactive, raising the overall quality to a competitive level.
Consistent product experience: The CRM and support pages now align visually and functionally with the application, creating a cohesive product that feels unified across all core elements.

Solution

Full redesign: Conduct a complete UI/UX overhaul of the applications, following M3 design principles.
Targeted improvements: Replace key elements with assets from the mobile update, focusing on login, navigation, text and search boxes, buttons, and typography. The page layouts were largely retained, with imported elements supporting the facelift. Further user experience enhancements are planned for a subsequent sprint.

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.