An Android application that works together with the motus web application. This application is mostly used for scanning, verifying, and moving handling units through a warehouse.
Motus is an industry and logistic software with a focus on fast, safe, and more transparent logistic processes. One critical area of motus is the warehouse product, which is currently under active development. The motus warehouse Android application is the central part of scanning, verifying, and moving handling units through a warehouse. With that in mind, the Android app is the key to a fast, safe, and reliable logistic process.
The Android application is the daily driver and most essential tool for any worker inside a warehouse. With this app, a worker can see next orders, execute a particular order, and scan handling units, plots, etc. In other words, the Android application guides the logistician during a workday and tries to minimize any potential error while verifying every step during these operations.
REICHHART digital logistics GmbH
08/2016 - 04/2018
Design & Prototyping
Since the start of the motus Android project in August 2016, I have been part of the product development team as a UI/UX designer. My primary focus during the Android project has been the conceptual and visual design. In close communication with our founders, our PM, and other stakeholders, I have tried to build the user interface in a component-based manner. The primary goal of this approach is a strong foundation for any further developments. I also participated in planning or attended conceptual meetings that exceeded the boundaries of only doing visual design work.
A considerable aspect of my work on the Android projects has involved prototyping. Prototyping is a quick and efficient way to test ideas and communicate them with co-workers and stakeholders. It is also great for executing detailed developer handoffs when it comes to precise animations and user flows. My primary tools for prototyping different ideas were Marvel and Framer.
This Android application is one of the critical factors when it comes to motus as an entire logistic solution. The primary goals were to enhance the way workers did their work in the warehouse and to speed up their processes while doubling down on process reliability.
These significant and challenging goals are even harder to accomplish when you are designing for a specific device with outdated specs. As a consequence of the logistics industry and their particular requirements, we couldn't choose any standard smartphone as a target device, but we needed a specific and industry robust device running Android.
Besides these fundamental limitations, the primary challenge was still the overall guidance through the specific processes. In a stressful and time-focused industry, human errors are inescapable and mostly pretty expensive. We had to build an application that would guide all workers and help them to minimize any chance of making mistakes during a process. This app had to become not only a helpful waymarker but also a supporting companion.
At first, we built many different prototypes to test our various strategies and ideas. In close communication with stakeholders and experts in the logistics area, we sat down to review our findings. Early in the process, we decided to divide every single logistic process, such as incorporation and outplacement, into its own sandboxed process. With this early idea in mind, we built our different processes as our first version.
On the visual side of things, we tried to stay as close to the Android platform as possible. Firstly, I studied the Google Material Design Specs. Together with our mobile developers, we extracted the conceptual and development benefits from using this excellent design language.
While designing the specific components and screens, we found that the Material Design Library was limiting us in some ways. That was the reason we tried to re-create some components on our own, without leaving the overall style and aesthetics from the Google Material Design Specs behind.
Prototyping played another massive role in this project. We developed different kinds of "Click-Dummy" applications to test the flow throughout the application.
During the development phase, I was part of the product development team as a UI/UX designer. My primary responsibilities were the conceptual/visual design and the in-depth prototyping of user flows and some specific interactions.
The main idea behind our Android application is the segmentation of specific processes. Every process, like "Goods Receiving" or "Goods Outwards," is its own entity and acts completely independently. Furthermore, each process has its own visual theme, which helps the worker in different situations like, for example, recognition. With that in mind, the worker knows that process "X" always has the blue theme and is alarmed when he accidentally opens the wrong process.
Furthermore, the guidance throughout any process is highly customized and as reliable as possible. Besides visual clues, the application supports different kinds of direction through audio and vibration techniques. With these various cognitive elements, we tried to make the Android app into a companion that helps the worker with very subtle but distinct notifications.
Another big idea behind this application is the so-called "Cargo List." A cargo list is more or less an abstraction of a shopping basket and displays any scanned handing unit and the corresponding information and destination. In this setting, a worker can select any order or handling unit inside a cargo list for further transfer.
The general starting point when a user is opening the motus Android application. It is a very straightforward design, and is mostly based on the Google Material Design standard components.
Collection - Start
The very first screen of a process, called "Collection." In this process, a user has to scan different values from a label to add this item to their cargo list.
Collection - After Scanning
A simple representation of the different states of the list items while scanning a label.
Collection - Cargo List
Every scanned box becomes available in a personal cargo list. From there, a user can manage all loaded boxes and prepare them for the next step.
Incorporation - Scan Target
This is the final step inside the "Incorporation" process. After scanning different boxes, a user is asked to book them onto another area.
The "Outplacement" process is an order-based process. Every scan represents a single order with all the relevant information. A user can now go to the declared area and load a specific box.
Outplacement - Item Proofing
In some processes, a user has to proof all boxes in another step. This step ensures data correctness and overall logistical process security.
Every idea and concept has to be tested and validated before handing it over to the developers. Prototyping is a great way to build a nearly realistic version of the design in a fraction of the real development time. With that in mind, I was heavily invested in different ways of prototyping for testing ideas or mimicking user flows for further explanation or discussions.
Our primary tools for prototyping were Marvel and Framer. The overall user flows and click-dummies were made with Marvel, because of the faster setup process. When it comes to specific interactions and animations, I switched back to Framer. Framer gives you a vast opportunity and flexibility in making interactions or animations. With Framer in our corner, we could develop some great interactive prototypes to eliminate confusion and great blockers better.
What I’ve Learned
One hard challenge while designing the motus Warehouse Android app was the decision-making process for some UI components. As I mentioned earlier, we didn't want to reinvent the wheel on every single pixel, because Google has great resources like Material Design for building Android apps. Sadly, in some situations, the Material Design components didn't fit as well as we were hoping for, and I had to make some components to solve the upcoming issues in a meaningful manner.
One takeaway from this experience is definitely that one should build applications in the environment the platform gives you, but it's okay to break these boundaries when it benefits the user. Breaking boundaries doesn't mean creating in the opposite direction. It only means taking the problem you are trying to solve into account and finding a suitable solution.
Another lesson I got from this project is early feedback with on-device prototyping. In nearly every situation, initial feedback is an excellent way to start, but when it comes to personal devices like smartphones, on-device testing is a real game changer. Testing different lighting situations, sounds, and more only works on the device and in action. Stakeholders and others can see ideas and design on a screen on my fancy iMac, but the real usage and feeling only comes when they are using it on a device. A prototype should feel like the real thing in order to be the perfect counterpart for seeking feedback, not just a pretty visualization of an idea.