Creating Dash
The design process for creating our admin back-end system.
Overview
Dash is the back-end application used by the Jitjatjo admins to make sure everything is running smoothly. It’s the workhorse app for the company. All of the data for JJJ three apps are held within the Dash system. JJJ’s client information, applicant’s data, recruited talent’s data, job details, internal matching algorithm for workers to gigs, and more is run through the Dash system. I was responsible for the designs and upkeep of this application.
Design process
Our design process was all about getting something out, in-front of a user (in this case, our admins), seeing how it performs before iterating on that idea. This allowed us the flexibility to design fast, make changes fast, and get to an end result quickly.
Customer insights
For this particular application, our “customers” were our own internal admins, so we had direct feedback when implementing new features into the system. Most of the features and quality of life updates were through direct requests. We had the luxury of being able to showcase any updates to our admins, whether that be through prototypes or MVP builds and iterate/refine them in a timely manner.
Fleshing things out
The back-end admin system was a freakishly large undertaking. Trying to predict individual pages that an admin may require in order to rectify an issue, meant I needed to cater for all variability that may/or may not happen. For a lot of these pages I was guided by our in-house slack channels. These channels were essentially specific channels to handle and track issues and alerts a Customer Service Admin could encounter in their day to day operations. So having that as a jumping point lead me to incorporate those issues onto page.
Putting pieces on to page
From there I worked closely with our Head of Design and Product Manager in understanding the content need for each page. I worked on producing a number of low-fidelity pages in order to create some cohesion amongst the chaos of data that needed to be displayed.
This lead to me producing templated pages which could be reproduced in order to keep consistency for an admin to view. The main templates were; a list view page, a details view page, modal views, and forms (both empty forms and editing forms). They could then be altered to meet their individual requirements. From that, I produced various components which were later added into our Design System.
The following are some key highlights that went into the design rollout of Dash. They highlight notable feature requests, edge cases, and the overall design evolution.
One system for multiple user-cases
We had a number of different admin types that were using Dash, this ranged from Client specific, Recruiters, Customer Service representatives, HR, System admins etc. With that, different permission levels and access to different pieces of information was required for each individual user to view. So the need to make sure that relevant content was shown to those individual users. Conversations with individual admins allowed us to create custom homepages for each admin type.
For example, below is the home screen for a Recruiter Admin, and a home screen for a Service Delivery and Fulfillment Admin. The information presented is vastly different for each role.
Different home page for a Recruiter to a Service Delivery and Fulfillment Admin
Mobile responsive
Although we endeavored to keep the dash system working on mobile devices, we also encountered challenges when dealing with the large amounts of content being displayed that doesn’t necessarily lend itself to translate well on a mobile screen. Things like tables and the ability to scroll left and right in order to view it in its entirety. Technically it was all possible, just not the best experience. With that in mind, we did lean more on the admins to use the desktop version of the site, rather than mobile.
Calendar
Originally we had Future/Active Jobs/Past Jobs within the list template view. A feature request from our admins was the ability to view a months worth of jobs from a more, simple point of view. This lead to development of including a calendar view within the jobs page. I used Google maps as the main inspiration when designing our version of the calendar, but also included a pills visual treatment to understand a days overall status, and also included the ability to expand a days worth of jobs for any admins that still needed a more detailed picture.
Dashboard metrics
The ability to analyse metrics in all aspects was paramount for Jitjatjo. I worked closely with the Product Manager to ensure the data we receive could be easily interpreted and understood in a legible manner. Originally the company relied on grow.com to house data pieces and imported into Dash. Unfortunately grow.com has very limited ability to style and fit within our system. So I re-designed the whole thing. I split the dashboard elements up in a way to reflect our companies overall performance, this included revenue, profit breakdowns and performance with our clients. The other side reflects any trends and insights to evaluate and make predictions for future KPIs
Dashboard elements split between organisation level and insights
Payment breakdown
A huge project that the team worked on across all platforms was having the ability to be 100% transparent with the pricing details for a job, and further to that, the payment amount for individual workers. We had to account for different pay structures across the different markets we operated in. The US pay structure is completely different to the Australian and Israeli markets. Example of things we needed to be aware of include base pay, hourly pay, overtime, AM and PM casual rates, Weekend rates, Casual Loading, Shabbat specific timings.
Along with this, were also standard payment add-ons for things like Priority Pricing for positions, Travel Stipends, Promo Codes and Discounts.
A breakdown of the individual payments (US vs Aust vs Israel) across the different markets
Dealing with Issues
A big part of Dash was the ability to put out fires when they occurred. Making sure an admin had all the information available to them before they acted on it. So I designed a number of areas throughout the system to make sure critical information pieces were available and easily viewed. Things like, being able to easily see if a job will be fulfilled in time. I integrated a status bar on all job bookings so an admin could see what stage of the booking process it was up to. Along with these, were variables to when things didn’t go to plan, like different types of alerts to indicate their level of severity.
Another admin feature request was the ability to see any issue in a contextual manner. Originally admins were relying on third party solution such as customised Slack Channels in order to handle when issues arise. For example, when a talent has not shown up for a job or if they’re listed as not having left yet. I worked on incorporating these issues directly into those pages, but also inline with the specific talent that issue referred to.
In use cases for when there are multiple issues across a job, I worked on designating severity levels into major/mid/minor issues, as well as allowing the ability to expand a talent row to view that individual issue.
