About GreyOrange
GreyOrange builds complex warehouse automation software for real-world operations.
Their product doesn’t live on one clean dashboard. It spans warehouse solutioning, layout planning, robotic task orchestration, inventory logic, order lifecycles, auditing, operator interfaces, handheld devices, touchscreens, and multiple warehouse personas.
For a PM, that means every requirement has a long tail.
A small product change can affect the solutioning journey, the artifacts generated for a warehouse, the services that consume those artifacts, and the operators using the interface on the floor.
As Mohit put it:
“For any requirement, you have to start from the solution journey. How does this feature impact solutioning? How does the artifact change? Who consumes it? What do the other modules do with it?”
That is the kind of product where generic AI mockups fall apart very quickly. Pretty screens are not the hard part. Understanding how the product actually works is.
The problem
GreyOrange already had a strong UX team, but the problem was that PMs could not easily experience the flow before development.
They could get screens made. They could use tools like Sketch or Marvel. But those outputs often stayed closer to static screen design than a real working experience.
“We were calling them UX designs, but they were mostly screen designs. As a product manager, I only got to experience the journey properly once it was developed.”
By then, it was usually too late.
In warehouse software, waiting until development to feel the flow is expensive. A wrong interaction, missing state, or unclear step is not just a UI issue. It can create review churn, engineering questions, and the classic PM problem:
“If anything broke, it came back as: where is it written that the journey should work this way?”
The deeper issue was expression.
Mohit had the product context. He understood the workflow, the edge cases, the devices, and the operational constraints. But turning that context into a clickable UX direction still depended on designer availability, repeated explanation, and the PM-designer “move this here, change that there” loop.
That loop was slow. And worse, it made iteration expensive.
Why this was hard to solve
GreyOrange’s designers already worked within a disciplined design system.
They had components. They knew the product. They could maintain visual consistency. But that also meant PMs often saw one polished direction instead of exploring multiple possible ways the flow could work.
“The UX team maintained design consistency really well because they were working inside a bounded box. But it didn’t allow me, as a PM, to think visually before the handoff.”
That’s the important part.
GreyOrange didn’t need Figr to replace design judgment. They needed Figr to make product thinking visual earlier.
Before Figr, prototyping meant waiting for someone else to translate the requirement. If the designer didn’t have the full context, the first round could easily become a context-transfer exercise.
One small requirement Mohit mentioned had already taken another person two days just to understand. He had the context himself, put it into Figr, and got the work done.
Not glamorous. Very real. This is where PM time quietly disappears.
The Figr workflow
GreyOrange used Figr on an operator interface for a new type of warehouse workflow.
The existing interface was functional, but old. It had done its job, but the team had a chance to rebuild it as a new Android app. That opened up a rare opportunity: rethink the interaction model without being trapped by the previous interface.
The team started with requirements and flows. Then they used Figr to create a complete clickable prototype.
For the first time, Mohit could interact with the operator flow before production design and engineering.
He could click through it. Scan through it. Share it through a password-protected URL. Open it on real devices. Test whether the behavior made sense where the actual operator would use it.
“For the first time on the operator interface, we had something workable and usable. I could click, scan, and see how it would behave.”
This changed the review conversation.
Instead of discussing abstract requirements, the team could ask better questions:
Is the action in the right place?
Does the flow make sense on the actual device?
What does the operator see at this moment?
Where does the journey feel slow or unclear?
Where does the process path split?
That is a much better review than arguing over a PRD paragraph.
What changed
Before Figr, initial alignment with UX could take one to two weeks.
Not because everyone was slow. Because the work depended on schedules, explanation, shared understanding, first drafts, and PM-designer tuning.
“Earlier, I would explain the journey to Lalit, explain what I was looking for, then wait for the first output. It depended on how well your frequency matched with the designer. Now I do it in a day. It’s up to me now. I have to sit down, but I’m not dependent on anybody else.”
With Figr, Mohit could do the first pass himself.
Figr does not remove designers from the workflow. It removes the dead time before the workflow becomes useful.
PMs can now bring designers a clearer first version. Designers still apply the design system, refine components, and take the work to production quality. But the first conversation is no longer, “Can you imagine what I mean?”
It becomes, “Here is the flow. Let’s make it right.”
Design system alignment, a major unlock
GreyOrange did not need Figr to invent a design language. Their UX team already had one.
The value was getting to a design-system-ready direction faster.
Figr helped the PM align the structure, behavior, and screen direction. Then the team moved the strongest screens into Figma and completed the production pass using GreyOrange’s own components.
“We got what we needed from Figr. We got alignment. This is how everything is going to look and behave. Then we started working on the final screens.”
Mohit estimated the Figr output got them roughly 80–85% of the way toward the final screen direction before production cleanup.
That’s exactly the right role for an enterprise AI design tool.
Not “magic final design.”
Not “replace your UX team.”
A better starting point, with enough product context for the real team to move faster.
Collaboration became easier because the prototype was shareable
The team could open the prototype on actual devices, not just a design file locally on a laptop. They could test the operator experience closer to the environment it was meant for.
“I could easily send it to someone. We opened the links on our own devices and the actual device we had. We could mock the behavior ourselves.”
For PMs, this is where collaboration changes.
Stakeholders don’t have to interpret requirements.
Designers don’t have to guess intent.
Developers don’t have to ask what the journey is supposed to do.
Operators can be simulated earlier.
The prototype becomes the shared object.
The impact for product teams
For GreyOrange, Figr created a new layer between requirement writing and production design.
That layer gave PMs more independence without creating chaos for designers.
Before Figr:
- PMs described flows in documents and conversations
- Designers translated that into screens
- Early UX validation was limited
- The real experience was felt late
- Alignment took one to two weeks
After Figr:
- PMs could turn context into a working prototype
- Teams could review the flow on real devices
- Designers started from a clearer direction
- Small requirements could be closed faster
- Initial alignment moved to a day
The biggest change was not speed alone.
It was that Mohit and his team could use the context they already had before it got diluted through handoffs.
Why this matters for Heads of Product
Every Head of Product knows this pattern.
Your PMs understand the product. Your designers understand the system. Your engineers understand the constraints. But the first version of a feature still gets stuck because no one has a shared, visual version of the idea early enough.
So the team waits.
Waits for a designer.
Waits for a review.
Waits for a better brief.
Waits for engineering to reveal what was unclear.
Figr compresses that wait.
It gives PMs a way to turn messy product context into something the whole team can react to.
For products like GreyOrange, where every requirement touches multiple systems and real-world operations, that matters more than another static mockup ever could.
The takeaway
GreyOrange used Figr to make complex product thinking visible earlier.
A PM could take warehouse workflow context, build a clickable prototype, share it securely, test it on real devices, and align with design faster.
The team still used its own design system and Figma process for final production work. But the expensive part changed: the first serious UX conversation no longer had to wait one to two weeks.
It could happen in a day.
“At least if these small things keep getting closed, it removes a lot of overhead. It leaves us time to work on the big chunks.”
That’s the real enterprise win.
Not faster screens.
Faster alignment on what should actually be built.