top of page
Enterprise Software Design
for the Supply Chain Industry
Crane Split Scenario Calculator
Understanding the Domain of the Container Shipping Industry
Gaining Industry Knowledge and Learning about the Challenges to solve
Unlike consumer application, enterprise design is for professional users that are specialized in their domain. They have to process large amount of data, address numerous use cases and work in unison with other teams.
A designer must gain a certain level of understanding about the complex processes that take place at a cargo terminal. The initial learning curve can be steep, but it is also exciting to gain a new set of knowledge. Great resources are colleagues that have first hand experience, phone interviews with clients and the occasional on site visit at a terminal.
The need for new products and services like the Crane Split Scenario Calculator is identified through established relationships with the container shipment industry. Product managers discuss with Terminals and Carriers the challenges of their operations. Customer support receives feedback from clients and conveys their suggestions for new features and software improvements to the development teams.
The role of a UX/UI designer is typically embedded between the product managers and engineering. Requirements are outlined and translated into solutions that fit into the existing software concept. A common challenge from the design perspective is to manage "feature creep". This means that over time an already complex application is being overloaded with more and more features. User oriented design thinking is crucial to maintain a certain level of simplicity. Thus the proposed solution for the new crane calculator was best realised as an independent app, instead of adding it as another feature into the main planning tool. This product strategy also offers other advantages, which will be discussed in the following paragraphs.
An advantage of designing software for a specific industry is that the target audience does not change. Container terminals may differ in size but adhere to a similar organisational structure. Shipping line companies tend more complex in their departments and internal workings.
When it comes to workflows, each organization has developed their own sequence. The lack of standardization makes the design of a software tool for all clients to use very problematic.
The user profile for the scenario calculator was quickly identified as the Berth Planner at terminals and Stowage Planners at shipping lines. However since everyone has their own workflows, understanding similarities and differences was essential. The goal was to develop a solution simple enough, to be easily adapted by Terminals as well as Carriers.
Understanding the Client's Organization Structure
and their Workflows
Building upon an existing Ecosytsem of Enterprise Applications
leveraging information from a central database
The Database
The core product of our company is an on prem terminal operating system (TOS). It captures, processes and manages all data created by the operational processes of a terminal.
Although it allows the user to perform all kinds of queries, its interface is highly abstract. An extensive training is required to master all functionality of the TOS.
Targeted Data Use through specialized Applications
There are many different ways terminals and shipping lines need to process information. Access to specific data sets is required in order to manage particular aspects of their operations. This is reflected in a family of applications which have been developed by our company over time. Complex workflows are managed by larger core software solutions, whereas simpler tasks are handled by smaller apps.
The Crane Split Scenario Calculator can be classified as an auxiliary tool for the ship call planning process. A vessel will berth at a specific area in a terminal (berth position). This determines what cranes are physically available to discharge and load the cargo. The arrival and departure time of the ship as well as the amount of moves necessary to lift containers in- and out of that vessel, play a role in the calculation of the most efficient crane split and alternative scenarios.
As part of our software ecosystem, the scenario calculator is easily integrated with our TOS. For terminals with a different technical set up, this app should also function as a stand alone. Therefore the UI needs to be able to handle manual inputs, as well as prefill values automatically when integrated with the TOS.
Understanding the required data and its sources
mapping abstract information to its corresponding real world objects and processes
Decoding the underlying Information Architecture
To design a scenario calculator tool the underlying equation and it's variables for determining crane splits must be understood. Short of presenting the math itself, the inputs needed to create a design concept are Container Moves, Location of Bays, Berth Position, Crane Reach and Crane productivity.
The Container Ship's Load Plan for a Terminal Visit
A crane move describes the lifting of a container from the vessel to the landside (discharge) or from the landside to the vessel (load). For each terminal a stowage planner has to create a sequence of loads and discharges that will result in a certain number of container moves for the cranes to execute. This load plan is provided to the terminal via an Electronic Data Interchange file (EDI).
A cargo vessel is structured into bays, each holding several stacks of containers. A load plan can also tell a crane in which bays cargo has to be moved. Some containers might be discharged in bay 01 in front of the ship and some containers need to be loaded in bay 32 in the back of the ship. To calculate a crane split scenario, the tool needs to extract from the load plan the amount of container moves for each bay and map this data along the length of the ship.
Terminal Layout and Crane Reach
A terminal consists of multiple areas like truck gates, rail yard or the container yard. The water facing area where vessels can berth and cranes operate is called quays. Depending of the geographical layout, a section of a quay can be one long stretch or multiple sections facing different directions.
Along each section gantry cranes are moving up and down on a track, changing their position to wherever they are needed. Multiple cranes are lined up next to each other on the same track, thus they are unable to pass one another. This gives each individual crane a certain reach, which has to be taken into account for each load plan.
All the above described information is stored in the Terminal's operating system. If the scenario calculator is connected to this database, it will have instant access to this data. In case the calculator is used as a stand alone app, the user only has to enter all terminal information only once during the setup process.
The need for Calculating Multiple Crane Split Scenarios
The container terminal is a commercial organization. A profit is made when all its operations run at full capacity aiming for peak efficiency. Since multiple cranes work on one ship, a sequence has to be planned that coordinates their move queues, aka "Crane Split". Several crane split scenarios help the berth planner to prepare for several situations. Cranes might have to be coordinated between two ship calls happening at the same time. A vessel gets delayed and the berth planner must switch to a different crane split to meet the scheduled departure time. One of the cranes can be scheduled for maintenance or unexpectedly break down. All of these possibilities need to be anticipated which makes the crane split scenario calculator a very valuable tool for a terminal.
Applying Design Thinking to Enterprise Software Solutions
diverging ideas before converging on a design
Established Patterns vs. Innovation
The shipping industry is conservative in nature and slow in adapting new solutions. This doesn't mean one can't come up with creative ideas. The challenge is to find the right balance between the old and new. When working together with stakeholders one strategy has proven effective: create one mock that fulfills the most common expectations and create at least one alternative design. Once everyone in the room can compare the two, a third design emerges, combining the best of both worlds.
The Gold Standard of the Industry are Tables
The most popular software in terminal and carrier operations is microsoft excel. It is highly flexible processing data in any way possible. Some teams have build very sophisticated spreadsheets in excel. Therefore any software that would replace their creation is expected to provide a similar user experience. For a designer this means tables!
Tables have the advantage to present a large amount of data in a tight and organized space. They are highly customizable through sorting, filtering and adding, removing, reorganizing columns. One can also apply filters or find certain values and patterns in the data through complex queries. However the visualization of information in a table is highly abstract. Simple tables might be just fine, but with growing complexity they become harder to read. A software solution that relies on tables might meet the initial expectations of the client. The disadvantage however is that the user needs to be trained, which results in highly specialized personal. This can make terminal and carrier teams less flexible since only few members are able to use the application.
Graphic Visualization of Data
An excel spreadsheet can also create charts and diagrams, but has its limits in customization. Our applications put emphasis on the graphical presentation of information, enabling customers to easier understand and manage their operations in its proper context.
As described earlier, each number and value in the calculator does represent physical objects. The reach of a crane can be shown as a stripe with a certain length. These stripes can be aligned to a table which shows the layout of the container ship. The ship structure outlines each bay with its planned moves. A timeline visualizes the timespan needed for a crane to complete each move per bay.
The encoding of information through colors further enables the user to quickly distinguish between different stats or values.
Weighting the Pros & Cons of both Design Options
Mock 1 shows a high degree of data abstraction and density. This puts a lot of burden on to the users mind, who has to interpret each value in order to come to a conclusion. A highly trained professional might prefer this compact solution. There is no distraction from reading the numbers and the table format can be quickly rearranged to focus on certain values. All three scenarios are shown simultaneously. For an untrained person this dense layout might initially be difficult to understand.
The graphics in Mock 2 are more intuitive to read as they are an abstract reflection of a real world scenario. It puts all elements into a visual context and uses color to describe each crane. Unfortunately the graphics require more space so that only one scenario can be displayed at a time. A toggle button navigates between the other scenarios, therefore increasing the click through rate. This makes a the comparison of all scenarios harder to do.
Merging Consumer and Enterprise UX/UI Design Practices
Even though the container shipping industry is conservative in nature, modern trends are also recognized. Mobile devices are more and more used by terminal operations teams. The need for quick and easy access to information demands for innovative solutions.
The challenge for the design process is to combine the simplicity of a consumer app with the complexity of enterprise software. What was once a large monolithic computer program is changing into smaller modularized applications. The Crane Split Scenario Calculator is a good example of a solution that is focused on a single task, which allows a more simplified and visual engaging interface.
Converging on a design
Presenting the two alternative mocks to the team enabled everyone to better reflect on their ideas and opinions. The graphic display of crane ranges, moves per bay and the sequence pattern of the crane split was unanimously perceived as the more intuitive and engaging solution. However Mock 2 lacked somewhat the compactness of the design presented in Mock 1.
After collecting the input from every stakeholder a third mock was created.
The horizontal layout of the data input area in the table design (Mock 1) proved to be a good fit for the width needed to show all the graphic parts of the calculator. Some creative thinking was required to tighten up all the various visual elements. Changing the ship bay table into an actual outline of a ship was the ideal solution. Not only improved it the look and feel but also allowed a closer integration of crane reach and crane split into a single contextual diagram. Finally all calculated scenarios had to be brought onto a single screen in order to avoid the extra tab buttons.
Since each calculated scenario was also shown as a graphic with a narrow height and a long width, a vertical stacked layout seemed to be a good fit. Each scenario graph could also serve as a button when placed directly underneath the crane split diagram. Clicking on a single scenario would then load the resulting crane split sequence into the diagram above.
Validating Concept & Design of the Calculator Application
finding opportunities to get feedback on the product design
The Challenges of User Testing for an Enterprise Application
Opportunities to test a consumer app with the user are plenty. One can go into a coffee shop to interview people, find volunteers for a workshop or just take advantage of one of the online testing platforms. Finding the right candidates for an enterprise product, that is targeted at a niche industry like container shipping can be a challenge. The features and workflows are so specific that it requires persons with domain knowledge to give useful feedback. This limits the pool of individuals which would qualify for any kind of user testing. Another problem is that one cannot ask a client to often for volunteering their opinion, as this could have a negative effect on customer relations.
Getting Creative in Finding Various Sources of Feedback
The best option for user testing is the an onsite visit at a terminal to shadow and interview an Berth Planner or Ops Manager. This is rather the exception and must be organized carefully. In some cases workshops are an option but this happens mostly in the context of a certain agreement with the customer. Jumping on a phone call is much less expensive and time consuming. However it isn't always very successful. Simple things like a bad connection, heavy foreign accents or the client being short on time can stand in the way.
An alternative source for user testing are colleagues or the customer support or sales department. Many peers have previously worked for many years at a terminal or shipping line. Analysing common issues gathered by customer support as well as talking to a sales person give valuable insights.
Embedding Validation into the Design Process
Best Practices of UX/UI describe the user testing as a step within an iterative cycle. Due to the limited sources in the enterprise domain, an opportunity to validate might become available at various points in the design process. Any of the above described sources might not be accessible at the time when needed. Therefore a certain flexibility and some creative source mining, paired with an overall domain knowledge can provide the needed feedback.
Bringing a new Enterprise Application to the Market
Integration of a new product into an established workflow.
Customization vs. Education
As mentioned before, the industry has the expectation that a new application matches their current experience to a certain degree. To get their signature under a contract, lots of customizations are negotiated that can also reflect on the design of the product. If possible one should try to engage with the end user during the sales process in order to highlight the advantages of the new designs. Therefore it's always a good idea for a designer to seek early involvement in these conversations with the customer.
Adoption Challenges and "Change of Management"
This term describes the effort it takes to adjust an established workflow to a new application.
Even as the new, more user friendly designed app allows a better performance, it must fit seamlessly into the end user's work routine. Any extra click is perceived as a disadvantage and might interrupt an efficient flow. Therefore it's also important to understand a typical set up of a workplace. It should either already be considered in the design of the product or the simple tips are included in the software onboarding process. Pointing out a quick way of how to create a bookmark, short cut or a desktop alias can make a difference in the adoption process.
Growing importance of UX/UI
for Enterprise Software Development
Being involved from the beginning of the process.
Contributing instead of only Executing
The actual value of UX/UI is still perceived differently from company to company. This can often result in placing a designer as a sole executioner of instructions, handed down by the product manager. When responding to an RFP from a big terminal or carrier, only sales, product managers and parts of the executive staff would assemble the proposal. Today even in a niche market such as the container shipping industry, there are more and more players competing over the business with a few big organizations. To stand out of the competition a product must also be unique and innovative. It's not only the amount of features an app can offer but also it's usability and design that can create value for the customer. A designer should be involved in kick off meetings or workshops, where sketches or simple prototypes are used to quickly visualize ideas, all of which further engage and excite the customer. If enterprise UX/UI design is understood as a contributing part of the product development process, then design thinking can become a driving force for innovative solutions.
bottom of page