SkySpecs is a drone company deploys autonomous drones to provide automated wind turbine inspections for the Wind Energy Industry. We built a work order system for SkySpecs to streamline their workflow. This is a website that can be fully utilized by SkySpecs employees to track their customer commitments, creating and viewing both history and upcoming inspections.
With the growth of the company, customers and corresponding inspections are increasing which necessitates an infrastructure to centralize work orders, streamline their workflow and run business systematically and more efficiently.
The workflow of SkySpecs includes 6 steps, as shown in figure 1. They receive a request by phone and schedule via Google Calendar. However, there is only one web portal for the 5th step to store a collection of uploaded data and annotation. From their workflow, we found the main problems resided in two perspectives- scheduling inspections (Problem 2) and keeping track of orders (Problem 1, 3, 4).
After meeting with higher-ups of SkySpecs, they gave us a list of expected project outcomes, as shown in the table below. We prioritized the three key objectives and then started our design process.
|Priority||Stakeholder Objective||Specifications||Related Problem|
|1||Schedule Inspections||Determine when to inspect each wind farm||Problem 2|
|2||Ticket System||Interface for SkySpecs employees to view and interact with orders||Problem 1, 3, 4|
|3||Calendar Integration||Automatically place submitted orders on SkySpecs’ calendar||Problem 4|
Although our sponsor gave us a list of possible expectations, they were not 100% sure about what are the most useful and practical deliverables. Thus, we faced the challenge of helping our stakeholders figure out what they need in the system. We went through several rounds of fast prototyping and review, resulting in the wireframes shown on the right.
We discovered that there were too many factors to be considered during the scheduling process, so we shifted to the workflow after inspections are scheduled. After discussion with our sponsor, we have determined that the deliverables for this project will be:
- Work Order System: Interfaces for SkySpecs employees to view and interact with orders. (Original Objective 2: Ticket System)
- Calendar: Automatically place submitted orders on SkySpecs’ calendar. (Original Objective 3: Calendar Integration)
To flesh out the work order system, the research was twofold. Firstly, defined the target audience and conducted user interviews to gain insights of their needs. Secondly, did Comparative Evaluation to understand how does work order system function.
After the background research of SkySpecs organization, we generalized our target audience into four main categories: Director, Operator, Analyst and SkySpecs' Customer. And their major responsibilities are:
- Director: schedule with their customers and assign inspections to the operator.
- Operator: perform inspections on wind farms and upload data into the web portal.
- Analyst: annotate the damage seveity of turbine data in the web portal.
As you can see from figure 3 above, the primary user of the work order system was the SkySpecs crew while the secondary user was their customer. We planned to sketch out a fully-functional system and then modify separate views for the different user account. So we conducted in-depth interviews and observed their workflow with all primary users of SkySpecs in the work site. And then we analyzed the problem they were facing and came up with some insights.
Moving forward, we then did the comparative evaluation, including indirect comparisons with existing work order platforms: NetFacilities, eMaint, and Fiix, etc. We also did the analogous comparisons with scheduling systems: Google Calendar, Doodle, etc.
Our initial design focused on both the work order workflow itself and its related information (customer and turbine), as you can see from the system structure below. The main workflow is to create new work order through a 4-step-process. The relevant information will be programmatically brought up from customer or turbine table database. If new customer or turbine, users can toggle to the corresponding section and manually enter the information. The agenda/calendar provides the visual aid in a separate part with the same details as in work order table.
Below shows the system structure and key wireframes that we came up with from the research insights. I also listed out how each feature match with the insight.
Our project continued after the summer when the SkySpecs made a lot of changes to their existing web portal. Because the Work Order System is not a standalone website and will be integrated into their current site, we need to consider these changes and tweak our design.
We have worked closely with our sponsor through weekly meetings and to identify what features they need to consolidate in a work order system. We also had three design reviews to evaluate the design at each stage and iterated based on received feedback. We conducted late-stage usability testing to validate the work order system, testing the functionality, efficiency, flexibility of the work order system and made some tweaks.
|1||Efficiency||Turbines can be programmatically brought up, not manually anymore. The process of creating new work order has been simplified too.|
|2||Flexibility||Users not only can save and edit the work order later, but they now can fill in the turbine number for inspection without selecting the exact turbine.|
|3||Calendar||The calendar now becomes a visual view of the work order table.|
We previously planned to set separate accounts for different users (director, analyst, operator, and customer). As SpySpecs set up the login user account as each customer, we no longer needed to consider different user views and customer information section. And they also built the turbine section we design into their system, so we no need to worry about turbine information too. The final narrowed-down project scope is shown below:
Key Change 1.
1. Users log in to the individual customer account, so the customer section is removed.
2. SkySpecs added the turbine information under each wind farm, so we removed the turbine section from work order system too.
3. As the calendar/agenda shows the same information as the work order table, so the agenda section has been merged into the work order system as a parallel calendar view.
Key Change 2.
Turbine Selection Process
In the previous design, users had to enter the inspected turbine information one by one manually. With the technical support, the turbine information can now populate by importing from CSV file or bringing up from the existing wind farm database. The new turbine information will be added to the database programmatically from the CSV file as well.
Key Change 3.
Create New Work Order Steps
The 4-step-process of creating new work order has been reorganized and reduced to 3 steps. And some repetitive details, like the windfarm address and contact information which already exist in the database, have been removed. Either does the turbine details.
Create New Work Order 4-step Process (Before)
Simplified 3-step Process (After)
New System Structure
The new system structure now contains two main parts: the functional work order table and creating new work order process, starting from selecting turbines to adding dates and assignees to sending a notification to the client.
In this section, I showcase three critical features of the work order system and some other features at the end.Invision Mock-ups
Key Feature 1.
Create New Work Order
Simple workflow makes it possible for the user to create a new work order in a fast and flexible way.
Key Feature 2.
The checkbox before each row allows the user to select multiple work orders and do bulk action, including "assign to", "add estimated dates" and "delete".
Key Feature 3.
The calendar view shows the same informaiton as the table does but encodes in a visual way. It also has additional weather information but less interactive function.
From a technical side, what a UX designer should do is understanding user's needs through conducting user research and transforming the requirements into design and followed by iterations. This project allowed me to practice what I had learned and adapted them into real use cases. Most importantly, with the exposure to real-world problems, I learned how I could resolve the conflict between design and requirements.
From the professional respective, I got the chance to work with different stakeholders: the SkySpecs team (our sponsor and user), the development team, our project mentor and another designer. This one-year experience taught me how to reach consensus and solve disagreement within the project team, and how to gather feedback from our users and communicate our ideas to them.