← Back to work

Product exploration / Design & engineering

Office Garden

Exploring how a walkable workplace and an assistant could help people find their way—and hand work over with clearer ownership.

Working prototype · Fictional company and people

A personal product exploration. The organisation, employees, reporting relationships, documents and client cases shown here are fictional. This is not a company deployment.

The 30-second version

The problem

When a task crosses teams, finding a name or a document may still leave someone unsure who can help and what the next person needs.

What I did

I designed and built a 3D workplace, a source-based helper and a request workflow with review, revisions and explicit acceptance.

Where it landed

A working browser-local prototype. The next useful test is one handoff against a simple form; adoption and operational benefits remain unvalidated.

A question between teams

Imagine Maya has just joined a fictional services company. A client asks for a cloud assessment next Monday. She can message a colleague, but first she needs to work out which team owns the scope, what information they require and who will take the next action.

  1. Which team handles this kind of request?

  2. Which guidance applies, and where did that answer come from?

  3. Has someone accepted the handoff—or have I only sent a message?

These questions shaped the design hypothesis. I have not measured how often they occur in real organisations or established that a 3D interface improves the outcome.

A place to explore, with a direct route to work

The prototype connects a three-level campus with a searchable directory and practical work panels. People can explore the wings, visit a department guide, find a teammate, book a desk and interact with their workspace. Search and forms remain available without walking through the world.

Captured from the working prototype: an invented three-level workplace with controllable characters and camera views. The layout is a design exercise, not a real office blueprint.

My contribution

I shaped the concept, interaction flows and visual direction, then built and iterated the React prototype with AI-assisted implementation. The work includes scene navigation, fictional organisation data, local state, cross-tab collaboration and the request-review journey.

Role
Product exploration, interaction design & front-end engineering
Format
React / TypeScript / Three.js / PWA prototype
Collaboration
Tabs in the same browser and origin
Data
400 fictional profiles; no concurrency claim

Explore the prototype

Start as Maya, choose Start handoff demo and follow the request through review, requested changes and acceptance. You can also explore the office. The demo loads only when you choose to open it.

English demo UI. Browser-local data; source search and guided templates. No connected company systems or external AI service. Use sample information only.Open full screen

Make the organisation understandable

The directory makes teams, sample supervisors and office locations visible. Department guides explain six fictional functions. The aim is to help a newcomer understand where to start, while distinguishing the directory, an assigned desk and a character’s live position.

Fictional directory and profile details. Locations and reporting relationships are sample data; they do not describe real people or live attendance.

Ray gathers evidence before suggesting a next step

Ray is the character’s helper. It searches sample business-unit references and shows exact passages with document titles, versions, review dates and listed owners. People can inspect the source before using it, then prepare a handoff when a person needs to make the decision.

The working helper with fictional source material. A document being in the library does not make it an approved company policy.

Where AI fits

In a compatible local setup, an on-device model can help select passages and prepare evidence-backed revisions. The hosted demo uses labelled source search, guided templates and offline evidence checks. Those paths demonstrate the workflow without claiming a live cloud agent is reasoning behind every response.

The prototype keeps missing evidence visible. Suggested changes wait for the person’s review; sending a request and accepting responsibility are separate actions.

Follow one request all the way through

The most concrete journey became Maya’s assessment handoff. The client’s requested Monday start stays a preference until the relevant people confirm it.

  1. 01

    Find the right function

    Maya uses Hana’s welcome and Priya’s assessment guidance to understand what the receiving team needs, then prepares a request for her buddy Leo.

  2. 02

    Make the revision inspectable

    Leo opens the request in another local tab and asks for missing information. Assistance proposes exact source-backed field changes. Maya reviews the before-and-after values, approves and saves, then resubmits separately.

  3. 03

    Record who owns the next action

    Leo accepts the complete handoff and later records completion with evidence. Both tabs show the request’s revisions and event history.

Request review in the fictional demo. Source evidence, suggested changes and human decisions stay visible in the workflow.

This demonstrates same-browser collaboration. It does not send client communications, create external tickets or coordinate employees across devices.

What I learned

Building the world was useful for exploring interaction. Following a single request was more useful for deciding what the product should improve.

The spatial experience has to earn its place

A campus can provide context and orientation, but a person completing a task needs a short path. I kept direct search and work panels beside the 3D experience. A future comparison should test when the world helps and when it adds effort.

Trust comes from inspectable evidence

A confident answer is less useful when its source is unclear. Citations, exact field changes and unresolved questions made the assistant’s contribution easier to assess before acting.

A smaller workflow gives a clearer experiment

The concept grew to include onboarding, desks, knowledge, visitors and social activities. The handoff offered a more focused next step: improve request completeness and make the receiving owner explicit.

A working demo is only one kind of evidence

Implementation checks establish behaviour in the prototype. They do not establish employee adoption, time savings, cost savings or demand for a SaaS product. Those need observation and comparison in actual work.

What I would test next

Find one team willing to review a small set of appropriately anonymised requests. Compare a simple checklist or form with the assisted handoff, using equivalent information. Look at first-pass acceptance, clarification rounds and total handling effort—including review and maintenance. Agree the decision rule before testing.

If a simple form works just as well, that is a useful outcome. The next iteration should follow the evidence about the task.

What this prototype establishes

Working locally
3D and floor-plan views, fictional directory, sample knowledge retrieval, character and desk interactions, request revisions and same-browser tab updates.
Not connected
Supabase, company authentication, cross-device collaboration, email, calendars and production business systems.
Still to validate
A workflow owner, repeated voluntary use, benefit over existing tools, content maintenance and the value of the 3D experience.

Built with

  • React
  • TypeScript
  • Three.js
  • React Three Fiber
  • Vite
  • Browser storage
  • BroadcastChannel
Next project: Relay