← 返回作品

产品探索 / 设计与工程

Office Garden

探索可漫游的办公空间与助手,如何帮助员工熟悉组织,并让跨团队交接的责任更清晰。

可运行原型 · 虚构公司与人物

这是一个个人产品探索项目。这里展示的组织、员工、汇报关系、文档和客户案例均为虚构,并未在任何公司部署。

30 秒速览

要解决的问题

当任务需要跨团队处理时,即使找到一个名字或一份文档,员工仍可能不清楚该找谁,以及对方需要哪些信息。

我做了什么

我设计并开发了 3D 办公空间、基于来源的助手,以及包含审核、修改和明确接收责任的请求流程。

结果如何

完成了浏览器本地原型。下一步应将一个交接流程与简单表单比较;采用情况和实际业务收益仍未验证。

团队之间的一道问题

假设 Maya 刚加入一家虚构的服务公司,客户希望下周一启动云评估。她可以给同事发消息,但首先需要弄清:哪个团队负责范围界定、对方需要哪些信息,以及谁会接手下一步。

  1. 这类请求应由哪个团队处理?

  2. 哪份指引适用?答案来自哪里?

  3. 对方是否已接手,还是我只是发出了一条消息?

这些问题构成了设计假设。我尚未测量它们在真实组织中的发生频率,也未证明 3D 界面能改善处理结果。

可以探索的空间,也有直达任务的入口

原型将三层办公园区、可搜索的通讯录和工作面板连接起来。用户可以探索两翼、拜访部门向导、寻找同事、预订工位并与桌面互动。搜索和表单始终可直接使用,无须先走遍虚拟办公室。

运行中的原型实拍:虚构的三层办公环境,可控制角色和镜头。布局属于设计练习,并非真实办公室蓝图。

我的工作

我负责概念、交互流程和视觉方向,并借助 AI 辅助实现持续开发 React 原型。工作涵盖场景导航、虚构组织数据、本地状态、跨标签页协作,以及请求审核流程。

职责
产品探索、交互设计与前端工程
形式
React / TypeScript / Three.js / PWA 原型
协作范围
同一浏览器、同一来源下的标签页
数据
400 个虚构档案;不代表并发容量

体验原型

以 Maya 的身份点击 Start handoff demo,体验请求审核、补充修改与接收责任;也可以自由探索办公室。只有点击打开后,演示才会加载。

演示界面为英文。数据保存在浏览器本地,使用来源搜索与引导模板;未连接公司系统或外部 AI 服务。请仅使用示例信息。全屏打开

让组织结构更容易理解

通讯录展示团队、示例主管和办公位置。部门向导解释六种虚构职能,帮助新员工找到起点,同时明确区分通讯录位置、分配工位与角色的实时位置。

虚构通讯录与个人档案。位置和汇报关系均为示例,不代表真实人员或实时出勤。

Ray 先收集依据,再建议下一步

Ray 是跟随角色的助手。它搜索示例业务部门资料,并显示准确段落、文档标题、版本、审核日期和标注的负责人。用户可以先检查来源;需要人来决策时,再准备交接请求。

使用虚构资料的助手界面。文档被加入资料库,并不意味着它是正式获批的公司政策。

AI 在哪里发挥作用

在兼容的本地环境中,设备端模型可辅助选择段落并准备有依据的修改。托管演示使用明确标注的来源搜索、引导模板和离线证据检查;这些路径用于展示流程,不暗示每个回答背后都有云端智能体推理。

原型会保留缺失证据的状态。建议修改需要本人审核;发送请求与接收责任是两个独立操作。

跟随一份请求走完整个流程

Maya 的评估交接成为最具体的体验。客户提出的周一启动时间,在相关人员确认前始终只是偏好。

  1. 01

    找到合适的职能

    Maya 通过 Hana 的欢迎指引和 Priya 的评估说明,了解接收团队需要什么,再为伙伴 Leo 准备请求。

  2. 02

    让修改可检查

    Leo 在另一个本地标签页打开请求,要求补充信息。辅助功能提出逐项、有来源依据的字段修改。Maya 对照修改前后的值,批准并保存,再单独重新提交。

  3. 03

    记录下一步由谁负责

    Leo 接收完整交接,随后附上依据记录完成结果。两个标签页都能看到修改记录和事件历史。

虚构演示中的请求审核。来源依据、建议修改和人的决定始终可以查看。

这里展示的是同一浏览器内的协作,不会向客户发消息、创建外部工单,也不支持跨设备员工协作。

我学到了什么

搭建空间帮助我探索交互,而跟踪一份完整请求,更有助于判断产品究竟应该改善什么。

空间体验需要证明自己的价值

园区可以提供情境和方向感,但完成任务的人需要更短的路径。我在 3D 体验旁保留直接搜索和工作面板。未来应比较:何时空间有帮助,何时反而增加操作。

信任来自可以检查的依据

来源不清楚时,自信的回答也难以使用。引用、准确的字段差异和未解决问题,让用户在行动前更容易判断助手究竟贡献了什么。

缩小流程,实验才更明确

概念逐渐扩展到入职、工位、知识、访客和社交活动。交接流程提供了更聚焦的下一步:改善请求完整性,并明确接收责任的人。

能运行的演示只是一种证据

实现检查可以证明原型中的行为,却不能证明员工采用、时间或成本节省,以及 SaaS 需求。这些需要观察真实工作并进行比较。

下一步会验证什么

寻找一个愿意提供少量妥善匿名化请求的团队。在同等信息条件下,将简单清单或表单与辅助交接比较。观察首次接收率、澄清轮次和总处理投入,并计入审核与维护。测试前先约定如何做出下一步决定。

如果简单表单同样有效,这也是有用的结果。下一轮设计应由任务证据来决定。

原型目前证明了什么

本地可运行
3D 与平面图、虚构通讯录、示例知识检索、角色和桌面交互、请求修改,以及同一浏览器内的标签页同步。
尚未连接
Supabase、公司身份验证、跨设备协作、邮件、日历和生产业务系统。
仍待验证
流程负责人、自愿持续使用、相较现有工具的改善、内容维护,以及 3D 体验的价值。

技术实现

  • React
  • TypeScript
  • Three.js
  • React Three Fiber
  • Vite
  • 浏览器存储
  • BroadcastChannel
下一个项目: Relay