The work below demonstrates a case study conducted for 3Body consulting as part of my Master's programme at University College Cork. This 1 month design sprint consisted of business systems analysis activities to determine the structure and requirements for a new Case Management System. This case study was conducted individually and all work is my own.
3Body consulting offers first class IT consulting for small to medium sized businesses. After years of successfully utilizing an analog case management system, the company needs to digitally transform to meet the expanding needs of their employees and clients. This project provided in depth qualitative and quantitative reviews of 3Body's current business activities and systems. The insights were used to develop comprehensive systems requirements lists, business structure diagrams, and data management strategy deliverables to guide the development phase. By creating a case management system that's based in 3Body's users' experiences, they will ensure their current and future business needs will be met efficiently, diligently, and easily.
An analysis of current systems was conducted via research into the existing hardware and software in use at 3Body, including interview transcripts with primary stakeholders. The insights were summarized with an Issue - Impact report, SWOT analysis, and user profiles. These each encapsulated the current challenges users face as they interact with the current system.
Data for hardware and client information (IP addresses, passwords, etc.) is disorganized, incomplete, difficult to decipher, and not updated consistently.
Not enough time to update case
information before going on to next job.
It is unclear who is working on a case and when.
Long time required to fix clients’ issues and rectify incorrect data and records.
Techs require wi-fi to access info called in by clients via email, causing hours long gaps in response time.
Case history is only transferred orally.
Techs waste their time, work with incorrect or inconsistent data, and waste billable hours.
Techs appear unprofessional in front of customers and waste customers’ time updating/correcting information.
Customers are double-contacted and overwhelmed by numerous techs responding to their case.
Techs waste time clarifying who has performed which services for which client.
Techs are unable to obtain necessary information to work effectively in the field.
Case history is not officially recorded and is relayed subjectively, allowing for information breaches, security risks and inconsistency.
Multiple Contact Options for Clients
Record of Cases
Various Case Statuses
Small Number of Employees in Charge of Contacting Customers
Written Records Allow for Misspelling
Incorrect Entry Types & Blank Sections
No connection between phone call and email records
No way for technicians to access information remotely
Increased case management efficiency
Increased communications between roles
Decreased cost in wasted billable hours and travel time
Improved client relationships and professional reputation
Complexity of barcode entry
New software learning curve
Dependency on internet connection & device durability
Eventual need for increased scale
Information security risks
PRIMARY USER: IT TECHNICIAN, TIM
Tim comes in to work early, as he usually does, to get a head start on his service requests. He logs on and sees one of his cases has been escalated by Peter. An email sent to him through the system verifies this: “Tim-- client called after hours yesterday very distraught. Please visit the client tomorrow to install the new hardware.” While Tim is unhappy to have to deal with an upset client, he informs the client that he will be stopping by later today. He continues on with other administrative tasks he needed to accomplish before heading out on the call. From his car he sets the timer for billable hours via an app on his iPad. At the client’s location he performs the necessary hardware installation. He is able to access the client’s software and server configuration information via the app on his iPad. He logs the new hardware via a barcode scan. The client, though upset about the difficulties they had experienced, are very pleased with how quickly and smoothly the installation goes. When he returns to the office, he ends the billable hours timer and marks the request as resolved.
IDEAL USE CASE
35 Years Old
BSc Computer Science DIT
Employed at 3Body for 3 Years
PRIMARY USER: CLIENT, PAT
Pat arrives to work and sits down at her PC. After logging in her computer pops up with a bunch of windows notifying her of updates that were completed and that certain requirements need to be reset. Annoyed, she closes out of all the boxes and attempts to check her email as normal. She sees a bunch of emails in her box from their remote employees complaining about being unable to access the VPN. Unsure what a VPN is, but she types an email to 3Body to let them know of the issue. Windows begin popping up and blocking her access to her email; feeling very flustered, she rings 3Body. She is relieved to talk to Kelly on the phone, who creates a Service Request for her, taking the details orally. She spends the next three hours ranting to everyone in the office about the issue until the 3Body consultant arrives. While Kelly is there he demonstrates to Pat how to use their online service request system. After the visit she receives email confirmation that her case has been resolved and a link to view all details of the case online. She reviews the details, downloads a copy for their records, and leaves a long review singing her praises of 3Body and Kelly.
IDEAL USE CASE
58 Years Old
Well loved Office Manager in her workplace
Minimal tech competency
The following Data Structure, Requirements & Systems diagrams were based directly upon and built to support the use cases, user goals, and touchpoints discovered in the primary research. Creating these diagrams acted as a bridge between the qualitative insghts gathered in the systems analysis and the quantitative implications for 3Body's case management system.
ZERO LEVEL DATA FLOW DIAGRAM
The diagram below provides a high level visual that distinguishes the inputs and outputs for three of the most common users of the Case Management System. This is an inuitive way to break down the information that will need to be requested and pulled from the system regularly. These deliverables can then be broken down into specific user flows and interface requirements. For example, a client will need to input a service request and will therefore require the relevant input boxes (issue and contact details). This interaction could occur via 3Body's website, allowing it to be reviewed and approved before being submitted to the CMS, or could be performed in a direct interaction with the CMS. Once they have submitted a request they will need to receive updates on that request; this output could take the form of an automated email, SMS, or other text output in response to any changes to the status of their case request.
USE CASE MODEL
The Use Case Model below details the distinct tasks each primary user type (clients, admin staff, executive staff, and consultants) need to fulfill on a regular basis using the Case Management System. This is a crucial visual to return to during development to ensure each of these tasks can be completed by the final version of the software. This also provides a visual reference for the different types of security features that may need to be put in if different user groups need to fulfill the same actions but at different security levels (for example, a client viewing their submitted service request should see significantly less detail than a technician reviewing the same service request).
The following activity diagram highlights the input-output dynamics between 3Body's IT consultants and the Case Management System when entering a new case request. The diagram visually shows the call and response, connecting the user's actions and the resulting actions taken by the software in response to those actions.
UML CLASS ENTITY RELATIONSHIP DIAGRAM
The ERD demonstrates the database requirements for 3Body's Case Management System. It serves both as a list of the various data types and a map of how those data stores are connected to one another, and therefore how they will need to be connected when put into a relational database. This is particularly critical to ensure 3Body's consultants have access to the information necessary to perform their jobs correctly and thoroughly. The ERD also ensures proper record keeping by labelling which values may be repeated and which may not (for example, bar codes for parts must be unique, while the manufacturer name may be duplicated).
The following deliverable summarizes the functional and non-functional System Requirements. These would be used to build a new internal IT service design, business strategy, and admin system for 3Body. By building this technical list using actual user narratives, 3Body can ensure that as long as these requirements are met, their users' and business needs will be met as well.
Business name, phone number, address
Contact name, title, phone number
Billing method, address
Contract number, date, appointed contact
Manufacturer name, ID number
Purchase price, date
Unit barcode number
Warranty date, expiration
Requester name, email, phone number
Client name, email, phone number, purchases
Description of issue
Relevant hardware, software
Notes, special requests
Assigned consultant name
Visit date, time, consultant name(s)
Description of resolution status
Capacity for various types and large quantities of hardware, software, and client information
Ability to increase data storage and demands to server as business increases
Secure access and storage for protected data
Intuitive User Interface (Admin)
Providing efficient and reliable data access, management, editing, and searching
Attractive User Interface (Clients)
Builds trust and positive rapport with clients
High quality performance providing
real-time updates to information
TECH ACTIVITIES FOR A TECH COMPANY PROVIDING TECH SERVICES
I particularly enjoyed this project as a way to flex my technical communication muscles. While I feel very comfortable translating design insights into business requirements and vice versa, I had never created the technical deliverables used so commonly by big business strategy consultancies to communicate technical requirements to development teams. I aspire to increase my skillset in this area so I can be an excellent project manager. I'd love to take on the challenge of taking qualitative data, translating it into technical requirements, then translating those to actionable software development tasks, and then demonstrating how those actions have achieved business goals. Those roles require the same balance of attention to detail and big picture thinking that I've practiced in UX design.
What made this project relatively straight forward was its problem space: using technical analytical practices to generate technical deliverables for a tech company. I would love to explore how these digital transformation strategy activities would translate to, say, educational platforms or philanthropic non-profits. I particularly believe the high level activity diagrams would be extremely useful post qualitative research to understand the distinct interactions, data relationships, and inputs/outputs that each user flow requires and therefore what that means for a system. I look forward to combining these approaches with my design activities to communicate more effectively with the technical and business professionals I work with in the future.