AtWork: the Consolidation of a Tech Stack

Throughout the entire Product Design and Development piece of the project we were in direct conversation with the Subject Matter Experts (SMEs) and stakeholders weekly.

Additional Research and Project Planning

Due to our Win-Loss Analysis we had a massive backlog of research and even an overall direction for the Design of the site before we even began. The major decisions that came about during the brief Research phase of Design and Development was that we needed to structure this project differently. We landed on a Jobs to be Done Framework, traditional user personas were far too limiting for this project. Mostly due to how “mixed-desk” each role was. Every AtWork franchise has the autonomy to decide how they want to structure themselves and how they divide up responsibilities. Thus we landed on four primary Jobs:

1. Payroll and Billing: This included time keeping, payroll, finance, and billing of clients.

2. Hiring: This included marketing positions, the hiring process, and placement of Talent on a Job.

3. Communication: Notifications, calendar, and an instant messaging platform.

4. Records and Reporting: Data visualization, records of activity within the software, and displaying data legibly.

A Marathon of Design

Most of our hands-on design work took place in figma and figjam. We built out user flows in figjam. I built the UI off of the google material design library but I quickly moved away from that library as we realized how much custom UI we were going to need for this project.

Payroll and Billing

We began design with Payroll and Billing due to its legal requirements and because you have to start somewhere. Due to the multiple levels of data that needed to be shown in Payroll I designed a “Nested Table” system for the UI. This system allows the user to collapse and open multiple nested levels of a table to show how the values in the table interact and sum between different entities. The most common example was how hours were summed and divided out when looking at a pay period. Nested tables allowed our users to view individual time sheets in the same table as a total for their branch for a pay period. This feature had a bit of a learning curve but our tests showed that the friction was worth it.

Hiring

AtWork’s existing application and hiring process was mostly disconnected and required a lot of a recruiter’s time to push an applicant across the finish line to being hired and place-able on a job. We worked to integrated the hiring process into our future communication features, gather as much data on an applicant as quickly and painlessly as possible, and allow the recruiters to set-up an application as quickly as possible.

We started with an application builder that would allow the recruiter to duplicate a previous application and apply it to a new Job Order. This would save them tons of time. The new Application also had the added benefit of building the applicant’s account for AtWork as they applied for a Job. This meant that they were in the system and a recruiter could reach out if a position appeared that was a good fit for the applicant. In addition to the above, if the Talent applied for a different position the system would only ask them questions that they hadn’t previously entered on another Job. This got the application process down to a one-click application really quickly. In tests it took less than three applications in most cases. The application system was also directly tied to notifications which went out whenever the applicant or the recruiter completed a step in their application process.

Communication

The new system had a built-in notification system that sent automated emails and text messages out when certain actions took place on a relevant entity within the system. The bigger feature was us building them their own integrated messaging system. This was unique as well since all employees at a Branch needed the ability to see communication between Talent and any individual at a branch. This meant allowing users to subscribe to a conversation and allowing conversations to be searchable.

Records and Reporting

The old system allowed the users to process and export a variety of reports, and create “notes”. Reports were run manually and were not easily accessible. Notes were really the backbone of a branch’s business. The notes feature just allowed a user to create a text file with an attachment that was attached to an entity within the system. AtWork used this for everything. We set out to make both of the above features smarter.

We began with reports. My number one goal was to eliminate the need for a “Report” builder feature at all. I started by finding out which of the reports were actually being used, then began by focusing my data visualization work there. After that I wanted to make sure that we didn’t miss anything. We did this by making every table in the system exportable and capturing the current filtration set on the table by the user when they go to export the table.

Notes was fairly straightforward. We renamed these to Records to show how important and permanent they now are. Records retained Notes features of being text files with attachments that can be tied to any entity within the site. As you navigate up the hierarchy of the site though you now get a feed of all the most recent Records for all of the entities nested within the entity you are currently viewing. If you view an individual Talent’s file the Records will be just for them on the right side-bar. If you are looking at all the Talent for a Branch, the right-sidebar will show the Records for each Talent in chronological order.