Aircraft performance and preference list was a feature to be added in the gantt chart. It compares the performance of aircrafts within a single aircraft type. For instance, the company can own 8 type A aircrafts, and they should be ranked to show which aircraft performs better than the others. The information was originally in a separate website, that the PO now wants to integrate it in the Event Management System (EMS). I was given a few screenshots of what the original website looks like as initial requirements.
After studied with the reference, I came up with a list of questions to ask the users in order to find out what their current practice is with that piece of information, as well as what the expectation on new design is. Here are some of the questions:
Through the user interview, I consolidated the following statements:
◦ This aircraft performance and preference list is not frequently used.
◦ It is required when an aircraft in used has issues.
◦ Users are interested only in PERF numbers to decide which aircraft to use.
◦ They basically need to know only the best 5 aircrafts based on the payload capacity.
◦ The next action they do is usually choosing a better flight to switch to the aircraft.
With all these detail requirements and use cases, I started working on the wireframes.
I created a new side panel for aircraft types, where users will instantly think of when they want to find information about each type of aircraft types. According to the user comments, the best 5 aircrafts is shown at first sight when the open the detail panel. In order to reduce cognitive load, the remaining of the list is hidden by default. In reality, not all aircrafts are measured, so the list of aircrafts might not be complete. Therefore the total number of active aircrafts and the number of aircrafts in list is clearly stated to avoid confusion.
Compared to aircraft preference list, aircraft performance is a second priority information. Thus, it is captured in another tab. Unlike the old website, only PERF number is displayed here, since this is the only information users need. The aircrafts are sorted by PERF number in descending order to let users know which is better at a glance. Here I used a more layman’s term, ‘Best to worst’, to convey the meaning directly. It can also be changed to sort by registration number (i.e. aircrafts ID).
Apart from the requirements given, I also suggested to add indicators in the aircraft list outside in the gantt chart, so that users can know which aircrafts are better when scrolling through the chart, without clicking into each type and view the details. This feature received very positive feedback.
Because this feature is relatively straight forward, after confirmation on the wireframes, I immediately moved on to the UI phase.
Apart from the above hands-on work, I also played the role of facilitator. Most of the time when there are problems come up, designers are often turned to for solutions or advice. Working in a team, I had the opportunity to discuss with team members, reframe the problem and make the best decisions.
Once when we were designing a new module, the PO decided not to include an interface to show the audit trail. I pointed out that all the other modules we have developed include this audit trail interface. He mentioned the reason was that, audit trail is relatively useless compares to other modules. Since we haven’t come across the definition of in what scenario users need this audit trail. I decided to arrange a meeting to go through all the modules we had so far, aim to set guidelines to be reference in future.
In the meeting, I first wrote down a few statements of what could be achieved with the audit trail interface, in order to redefine the functionality of this feature, since this was developed a while ago before I joined the project. We had a short discussion and came up with the following set of rules.
Based on these statements, I moved on to review the use case of audit trail interface in each modules. I gathered the modules with edit features, and prepared a few use cases to my knowledge. Business analysts, who constantly communicate with users and gather user requirements, contributed to add more user cases. Eventually, we all agreed on when to include the audit trail interface in each modules.
