1-minute summary
Lens is a platform for material brands to manage catalogs, inventory, workflows, and everything in between.
I joined the design team when the product was just taking shape and when the team was exploring possibilities of execution.
At this stage, a number of material brand owners could not answer, ‘Where can I see the lifecycle of my SKUs daily?’
We took a step back to understand how to onboard a huge number of SKUs that sat merely in the Tally’s DB.
I collaborated with 2 engineers and 1 product designer.
Shaped the UX and UI into a dev-ready interactive flow.
We used AI models to synthesise user interviews, translate them into actionable UX touch points, create wireframes, versions and stress testing.
Our interviews with material brands surfaced a critical issue, product and SKU information was not system-driven.
Products were often retrieved from memory, and in many cases, customer-facing websites were being used as internal sources of information. Wherever catalogs existed, they were scattered across PDFs, spreadsheets, and physical formats.
Updating or sharing them was slow, inconsistent or even absent in many cases. Granular information was hard to manage, leading to errors and miscommunication.
There was no single structure that could bring this data together and surface the right information when needed.
Let me take you closer to each of these fundamental gaps.
#1 Getting data into the system without breaking existing behaviour
With a large number of SKUs and products, getting data into the system was the first bottleneck.
Data didn’t exist in one place. Some of it lived in Excel sheets, some on customer facing websites, and a lot of it only lived in memory. Instead of forcing a new format, we worked around how this data already existed.
Let me break it down for you,
We facilitated Excel based SKU/product upload which came with its naming convention.
Users could then bulk upload images following the same conventions and our system would map these images to the relevant products and SKUs.
We also let users flexibly map columns so that the catalog structure aligns with their existing sheets.
Once data could be brought into the system, the next challenge was structuring it in a way that made sense.
We defined product and SKU as separate but connected layers to manage variation and avoid confusion.
Product acts as the parent layer for every item
SKUs exist as variations under each product
Information is handled differently across both:
Product-level data is common and editable at the top level
SKU-specific data is visible at the product level, but only editable within the SKU
Editing at SKU level is controlled to avoid accidental changes
This allows users to see everything upfront, while still keeping control at the right level.
With structure in place, the system needed to support how users actually used this data day to day.
#3 Making high-frequency actions faster
With structure in place, the next challenge was speed.
A lot of actions were repetitive, especially when dealing with multiple SKUs of similar products. Instead of rebuilding every time, we focused on reducing effort in these frequent tasks. We did this by providing,
Duplicate SKU creation for similar entries
Quick add flows for continuous catalog updates as a primary action
Quick actions like creating quotes or recording sales
With a lot of information on plate, quick access to the right information became really important.
#4 Designing the catalog for quick scanning
Users needed quick access so that their actions are not lost in translation.
Instead of pushing them into multiple layers, we surfaced key information upfront so most decisions could be made from a single view. We designed the catalog page with,
List view of all products
Expandable SKU dropdowns within the same view
Key information like stock, specs, list and selling price, and quick actions without any clicks.
Finally, the system had to extend beyond internal use and support the catalog’s core sharing functionality.
#5 Making catalog sharing flexible and immediate
Sharing catalogs was a major gap in existing workflows.
Instead of static PDFs, we enabled flexible sharing that fits customers day to day communications,
Custom SKU selection for sharing
Live preview and edits on the catalog being created
WhatsApp sharing for direct communication
Bringing these together, the catalog evolved into a more structured and usable system.
Testing reasoning with our very first user
Testing brought out some flaws and gaps that we wouldn't have otherwise thought of. We re-iterated the PDF preview flow and other smaller details to fit their workflow and their extensive SKU inventory.
Final Resolution
The catalog evolved into a structured system where products, SKUs, and their associated data are organised in a way that supports both input and usage.
Data can be added in bulk, structured clearly, and accessed without unnecessary navigation. Actions like updating, sharing, or creating outputs are built into the same system, reducing the need to switch between tools.
The system balances structure with flexibility, allowing it to adapt to different workflows while still maintaining consistency.
The Impact
Impact was measured across the tests and is further to be measured with growing usage;
Reduced time taken to digitise and organise large product catalogs.
Made catalog updates and operations faster through reusable actions.
Improved clarity of product and SKU-level information.
Enabled quicker sharing aligned with existing communication patterns.