Making 10,000 pieces of furniture count

When I joined Rheaply, Google could not reliably say what furniture it owned, or where that furniture was, across 238 Bay Area buildings. I was the only designer on the team hired to solve that.

I expected to start with screens. I started with a chair. That chair could pass through eight phases, six teams, and several systems before somebody sat in it. I had never managed a warehouse or moved a pallet. That turned out to be useful. I could not guess, so I had to ask.

Ten thousand items were recorded in the first month, more than the platform had held in its entire history. The scanner helped. The shared model is what made those scans count as inventory rather than as a pile of records nobody could add up. More on that in a minute.

Five organizations, five versions of the truth

Much of the knowledge lived with outside vendors, not one team at Google. Together they used ten systems that did not talk to each other. The same chair could have three names depending on who was holding it.

Nobody was wrong. Everyone had inherited a vocabulary that worked for their part of the job. Put those vocabularies into one product, though, and the inventory stopped being searchable. You cannot count what you cannot name the same way twice.

I mapped every system the organizations used. So where did all five organizations already meet? Two rows ran nearly the whole way across, and both were Google Workspace. The system everybody actually trusted was a spreadsheet.

That changed how I saw the project. We were not replacing a file with a nicer database. We were turning the conversations around that file into a process five organizations could share. Before we could design the software, they had to agree on what each kind of object meant.

The work began before anyone chose a chair

We mapped the process from finding surplus furniture through receiving it in another building. Sixteen steps happened before anyone selected a chair. Receiving alone used three separate systems.

If we don’t have furniture at the right space, for the right time, then we’re not helping Google thrive.

Rhonda F., Workplace Operations Manager, Google

That was the first correction to my thinking. The inventory screen was not the whole product. The handoffs, labels, loading docks, and warehouse aisles were part of it too. Saving an hour in the interface meant nothing if a warehouse team spent it relabeling a pallet later.

Forty-six sessions later

We did not arrive at a shared model in one workshop. The research moved from finding the right people, to testing a prototype, to watching the working product in use.

• 16 interviews across the full furniture journey
• 11 people testing a clickable prototype before development
• 19 sessions with the working product, before and after changes
• 6 workshops covering eight shared-model activities

One finding bothered me. People trusted the words in the software even when those words did not match their own vocabulary. I thought the interface was reflecting their language. It was quietly replacing it, and the usability tests still passed, because people used our labels correctly.

We added visible definitions beside shared terms and used the workshops to agree on what each one meant. A common label was not enough. People needed a definition they could check against what they already believed.

The flexible model that could not count

I want to be direct about the expensive mistake. My first information model let people put objects inside other objects. It sounded flexible. A workstation could contain a chair, which could contain a tag, which could contain another record.

It also made the inventory almost impossible to search, report, or count. The structure could describe anything and answer almost nothing. Flexibility is not a virtue if the job is to know how many chairs you have.

We replaced nesting with product sets. One set described a type of table. Four hundred physical tables belonged to it. Each table kept its own condition and location, but now the system could answer the question it existed to answer: how many do we have?

The scanner had to disappear into the work

If you asked me to name the least glamorous, most used thing we shipped, it would be the scanner. Warehouse teams attached a code to each item. Pointing the camera at that code opened the right record. People updated location, condition, and status without typing a long identifier or hunting for a nearly identical chair.

This was not the conceptually difficult part of the project. It was the part people used thousands of times. Screens get the attention. The thing you do with your hands on the floor is what makes ten thousand records possible.

“I really want to have a system where I can say how many pieces I have on the floor of the building and where they are.”

Peter G., Senior Project Manager, Furniture Services, Google

The software could not create more warehouse work

Our product manager, Stephanie, gave the research its clearest principle: a good inventory system avoids pain off-platform as carefully as it creates ease on-platform. I still use that.

An hour saved in the interface is not a win if a moving team loses the same hour relabeling furniture. Individually, the labels, the handoffs, and the spreadsheet habits look small. Together they are the difference between a tool people open and a process they work around.

Ten thousand items, one unfinished result

The scale was real. So was the response from the teams using it.

“It’s fantastic. I’m super, super, super happy. Great job.”

Krista B., Director of Space Management, Google

But only half of registered users became active. One number shows the system could handle the inventory. The other says adoption remained incomplete. I left after the first release, before the team learned why. I will not invent a trajectory for a number that only has a stopping point.

• Items recorded in the first month 10,000
• Registered users who became active Half
• Organizations using the shared model 5
• Off-platform effort we measured None

The bigger picture

What I want you to take from this is not that ten thousand items proved the product. Only half of registered users became active. One number shows the system could handle the inventory. The other says adoption remained incomplete. I left after the first release, before the team learned why.

I found the nesting problem after engineering had started building it. Sitting beside an engineer with a rough prototype of the information structure could have exposed it in a day. Correcting it after development began cost weeks.

I had spent six weeks researching the work. I tested the screens, the language, and the flow. I had not tested the structure holding the data. That was where the most expensive mistake lived.

And we never measured off-platform effort. Stephanie’s principle was right. The number that would have proved it is the one we do not have.