Responsible for the UI that orchestrates a fleet of autonomous robots in a warehouse that helps to augment the picking process for human warehouse workers.
Principle UI Software Engineer
2021 - Present
Design, Product & Engineering
IAM Robotics was always a robotics company first. I was hired during a transition in the company going from a strictly robotics centered business to one that was focused on offering a warehouse picking solution. This came with some difficult hurdles. One being that there was no cloud fleet management. All interfaces were isolated to an individual robot.
In order for this to scale, we would have to redesign and reimagine how a user would interface with a fleet of robots in a way that translates the functionality needed to make each device operate within the engineering constraints of the hardware.
We started by working out an MVP of core functionality after researching to flush out details in the PRD with several whiteboarding sessions. We reduced it down to:
Lidar and Vector Mapping Tools
Robot Health and Status
After settling on an MVP, I started to flush out the user flow. First step was to verify with each department the expectations of what is needed from the product. To achieve this I created a clickthrough of the intended application and workshopped with the executive team, enterprise engineers, and the robotics engineers.
This was used to bridge and reduce the miscommunication across the business about product intention. This was a very important step in eliminating confusion, aligning expectations, and reducing the amount of potential wasted work which led to more productivity and a better product. Getting this indecision out of the way as early in the process as possible, saved the company both money and engineering effort.
After having our product's expectations confirmed, we decided on a software stack that would match our solution and arrived at React & React Native with code coverage and testing using a visual testing suite called Cypress. I also chose Redux Toolkit as an API model for it's familiarity which will allow other non UI geared engineers to contribute. It also created a straightforward data modeling pattern for all four different teams responsible for API development a simple pattern to work towards. I also went with Material UI as our component system. The complexity of the product was limited enough that we could leverage Material's design patterns which alsp simplified the conversation around of feature addition.
The design process was modeled after the engineering process and business expectations. The idea behind this model was to bring a system to the design process that would allow for a more predictable outcome. This would allow for more accurate time estimates and a more consistent product. The process is as follows:
- Discovery. Compile the business and user requirements of the platform.
- Sticky notes / whiteboards
- Synthesis. Create a wireframe that matches the requirements.
- Balsamic / figma
- Synthesis Analysis. Iterate on the wireframe with business leaders and closest to expected user base.
- Updates to the wireframe
- Technical Analysis. Iterate wireframe with architecture to verify functionality (return to business leaders with results)
- Updates to the wireframe
- Scaffolding. Begin Application development based on approved wireframes (break out into tasks separated by data flow, app state, components, views)
- Design System. Create a design system of typography, iconology, color, padding, spacing, weight, component examples, etc which will be the source for the application’s design.
- Run congruent with 5
- Execution. Apply approved design system to approved wireframes and work towards a demo
- Iteration. Bug fixing and feature approval process ( maintenance )
- React & Figma
The motivation for this was to separate the application's engineering requirements from the visual style system that's established by the brand. This lets the engineering and QA team focus on the functionality of the application while the visual design treatments can be iterated separately. Referencing all aspects of an application componentry, from margins and paddings to color and typography, to a style system theming architecture. Letting the design and engineering be created in parallel or just running default styling if time doesn't afford. Knowing that the system can be applied in the future after we test the functionality.
This also allowed me to interview and hire my team and give them clear and distinct roles on what they were responsible for. UI engineers were responsible for implementing scaffolding and componentry. Our UX researchers were responsible for understanding the bridge between our user's knowledge and the limitation of the engineering and how to ease that. Our UI designers managed the design system and visual renderings. Each party would participate in the overall product discussion and apply their expertise in an agile fashion. Where even UX research was estimated and planned for in the sprint to keep the process as transparent as possible to the business leaders.
Since the design system is separated from the application, we were able to mock up the application using mocked MUI wireframing components. This allows us to get a feel for the application, prevent over complicating engineering by leveraging the component library and design patterns of the library we chose, and help the rest of the engineering team understand what application is going to do. Adding wireframing mocks to our Jira Epics really helped the team understand the purpose of the engineering requirement in tangible terms.
I borrowed design references for the style system around 3 common applications. Jira, Gmail, and Twitter. The patterns used across these applications are easily recycled and familiar to the majority of the MVP's user base. So we leveraged that familiarity to reduce the learning curve and quickly get the user's working with the application. The color tokens and font families were brand associated and were referenced to the devices color scheme. Which was created before my arrival, so I just continued that language.
The high fidelity rendering is an entirely optional step once this pattern is established. The design system controls the entire application's aesthetics and every variable from padding to border radius is globally asserted. But for demonstration reasons, we would use the same design tokens to render out high fidelity renderings for manuals and presentations.
Updated Style System
When we went through a rebranding, I had to update the design system to match the new brand. The decoupled architecture of the design system made this very straightforward. By simply modifying the decoupled theming file the aesthetics was updated and all the functionality remained the same. Every functional unit test passed without any modification. This is an extreme example of modifying visual attributes without the cost of the engineered functionality.
I'm quite proud of my work at Onward Robotics. To see something that started with a PRD and several whiteboard sessions, to a fleet of robots and humans picking in a warehouse, is rewarding. Especially knowing that all of it is being successfully managed thanks to the effort my team put into this product. Now we're working on the next iteration of the product by evaluating our stakeholders' usage and using that insight to improve the experience. Leveraging customer insights and truly utilizing the feedback loop this system is designed to create. I'm excited to see where this product goes and how it will continue to evolve.