Anemoi - Train Capacity Dashboard Design Concepts Challenge

Challenge Introduction
The Train Capacity Dashboard allows Operations Room Controllers to understand the impact of a change they’re making to planned train allocations (which trains or carriages run on which routes). We are looking for your best concepts and UI ideas for how to help the Controllers monitor and find solutions quickly and efficiently.

Round 1

Submit your design for a Checkpoint feedback:
1. Dashboard
2. Detailed View (if including)
- If you have time - please provide us with a click map for your design.
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).

Round 2

Final design plus Checkpoint feedback:
1. Dashboard
2. Detailed View (if including)
- If you have time - please provide us with a click map for your design.
- Readme.jpg : Provide notes about your submission.
- Make sure all pages have correct flow! Use correct file numbering. (00, 01, 02, 03).

Challenge Description
This challenge is to design how we present this information to the controller in a quick and easy to understand way with the minimum of interactions. Controllers typically only have a very short period (1-5 minutes) to work out the available options and select and action the best. Note that changing how they work out the available options is currently out of scope – this exercise covers helping the controller make the best decision between the options they are presented with.

We are looking for your ORIGINAL IDEAS and CONCEPTS of this dashboard could look like and how it would function. This is the concept phase, so not every detail and piece of content needs to be perfect. We are looking for general ideas and structure that we can present to the client to spark discussion and additional ideas.

IMPORTANT NOTE:
Specific countries are restricted from working on this challenge, due to the client’s company policies.

If your country is highlighted in red in the following sheet your submission WILL NOT be accepted, unfortunately. This is NOT a new Topcoder policy or something that will become a normal part of future challenges. This is an isolated policy and requirement for this specific client and their challenges. Thank you for your understanding.
https://docs.google.com/spreadsheets/d/1MFZCGwIqgllzWBJuh2adC_BRCCG4kZwN1m8j4ZgbuLc/edit?usp=sharing

User Scenario

• The Diagrams for a day call for three 4-vehicle units (each with a capacity of 200 passengers) to be available at station A at 07:00.

• At 06:45, the depot states that only two 4-vehicle units are available plus one 2-vehicle unit (with a capacity of 100 passengers).

• The controller now has to decide which of the 3 Diagrams they will compromise by providing less capacity than planned.

• They enter the three Head Codes for the first journeys of the three Diagrams into the interface.

• The Train Capacity Dashboard immediately shows the planned Units for each Headcode and their total capacity

• The controller then selects how they would propose changing the allocated Units for each of the Head Codes (there are multiple options here, including swapping one unit type for another, removing a unit from a multi-unit train, removing all units [effectively cancelling the train] – see “Replacement scenarios” diagram below)

• When the Controller makes this selection the Dashboard updates to show how the change will affect the capacity of the original entered Head Code(s). There should be notifications on a per station level that indicates if capacity will meet the demand (will there be passengers unable to board or not?)

• The Train Capacity Dashboard will also show the Controller where there will be further impacts in future Head Codes for the diagrams these units are on if the controller were to take no further action. (For example....less capacity on certain trains will impact other stations on the line. So decisions made will alter capacity for other stations...thus creating a pros vs. cons scenario that the Controller has to take into consideration when making their decisions. How can we show this in our dashboard? Show some suggestions.)

• The operator will then decide which of the options is the best to take. Considerations will include:

  • Which option has the lowest impact on anticipated demand – ie minimise the number of people who wouldn’t fit on the Train

  • How long before the impact happens? The operator may have the opportunity to make another change later to “fix” the Capacity gap before that issue would actually manifest (they often act to push the problem later in the day rather than managing to actually solve it)

  • Which services have been disrupted recently – if a service has been the victim of under-capacity Trains a number of times recently, they may wish to avoid doing that again (rider satisfaction)

  • Are there special circumstances attached to one of the options which mean demand is likely to be higher (for example if there is a large event going on near one of the stations) Alerts/ notifications would be great to make the Controller aware that there be capacity issues now or in the future.

Note: The first two considerations are the most important focus initially, but we would like to see options for presenting information about the other two considerations too.

Once the controller has made their decision, they will be reflecting this in a separate system, so no further action would be expected on this interface until she has a new scenario.

Key Terms
The below terms are used throughout the spec and is how the customer references items. It is best to understand and use these terms where applicable.

• Unit - A set of railway vehicles that always travel together (for example you may have 2-vehicle units or 3-vehicle units)

• Train - One or more Units comprise a Train. This is what passengers will see operating the service. The train may split or join as it makes its journey.

• Head Code - this is a code for a specific journey, for example the 0700 train from London to Birmingham. Each Head Code will have between 2 and about 20 stations that it will call at to complete its journey. We know the time it is due at each station.

• Diagram - This is a collection of Head Codes that a given Unit will operate on a day. It captures the complete movements that those vehicles will make over the day. A Diagram might have 10-20 Head Codes for a given day.

• Capacity - This is the number of passengers that a Unit can carry

• Demand - This is the number of passengers who typically wish to travel between a pair of adjacent stations on a given Head Code. For example, for a journey where the train goes from station A to station C via station B, we might know that 100 people want to from station A > B and 120 want to go from station B > C. Therefore a train with capacity of 100 would be fine from A > B but be under capacity for the B > C stop. (This is what the Controller tries to fix and the purpose of the Tran Capacity Dashboard)

Replacement Scenarios
This image shows how an original 2 unit, 4 vehicle configuration may be altered by a Controller. These examples are not exhaustive – in principle the controller can remove any number of units (including all of them) and replace with any number of units of any type.

Branding Guidelines
We’ve created an InVision Board with basic branding and guidelines. Branding is open, but your designs should look clean and modern. Use colors and fonts appropriately. The design and UI shouldn’t be distracting or overwhelming for the user. This is a utilitarian desktop application that needs to be easy to understand and fast to use.

Content Input
The Content Input is meant to give you a basic understanding of the structure and process. These are NOT meant influence finished design. We want to see your ORIGINAL IDEAS based on these ideas. The Content Input can be found on the InVision Board

Screen Size Requirements
Desktop: 1280px wide (Height can expand)
Keep important information above 766-800px, if possible, to reduce scrolling

Screen Requirements
Screen 1 - Dashboard

• Input for Head Code(s)

• Solutions and options presented

• Any alerts or status updates for a specific proposed Unit

• Capacity information

• Station information and current travel

• Historical information about capacity (influences the Controller’s decision)

• Status of how a specific proposal will impact future capacity for that Unit (will influence decision. If the impact will happen later in the day the Controller will have time to resolve that issue when needed)

• Ability to view Detailed Information (Screen 2 - Detail View) (not a requirement, but something worth exploring)

• Elegant solution to view more than 3 solutions at a time. Grid views, scrollable windows, expandable panels/ tiles, filtering, categories, etc

• Might also be interesting to think about infographics, statuses or maps of train lines, visual representation of which Unit(s) or Train(s) are where on the train line network. Think of additional features, functionality, and ways to look at data that might be beneficial to the Controller to make an informed decision.

• Any additional states or functionality to explain your design solution (dropdown, slide out panels, different views, etc.)

Screen 2 - Detail View
This is not a required screen, but would be worth exploring some solutions for.

• Click on a proposed solution option could show the Controller some additional/ detailed information.

• Additional information could include: Robust historical data, why capacity will/ won't work, additional station information, what other Diagrams this Unit belongs to (if any), route information, etc.

• Remember, this Dashboard has to be fast for the user to make a decision. Make sure any Detail View solutions are intuitive and fast for the user to open AND return to the main Dashboard

• Options could include expandable panels, tiles that flip over, hover states, etc. Be innovative.

Important

• Keep your designs and UI clean and modern for easy of use and a streamlined experience

• Clear sense of hierarchy and purpose for the user

• Fast. The user will only have 1-5 minutes to make a decision

Target Audience
Operations Room Controllers

Submission & Source Files
Preview Image
Please create your preview image as one (1) 1024x1024px JPG or PNG file in RGB color mode at 72dpi and place a screenshot of your submission within it.

Submission File
Submit JPG/PNG for your submission files.

Source Files
All original source files of the submitted design. Files should be created in Adobe Photoshop and saved as layered PSD file, or Adobe Illustrator as a layered AI file.

Final Fixes
As part of the final fixes phase you may be asked to modify your graphics (sizes or colors) or modify overall colors. We may ask you to update your design or graphics based on checkpoint feedback. See more information about Final Fixes