返回履历

MegaETH · Terminal · Product Engineering Case

Terminal

一个月,把不断变化的产品方向收敛成可上线的生态地图

Terminal 是 MegaETH 官方生态门户,用户通过地图探索应用、完成任务并积累积分。我独立负责前端,并在需求持续变化、后端未齐、上线窗口固定的情况下,与 JY(PM)反复澄清产品语义、交互表现、状态边界和交付优先级。

31 天
新方向提出至 Stage
独立负责
前端实现与产品边界定义
10+
持续变化的需求与冲突组
3:24
长版项目复盘影片

10 章 · 3 分 24 秒

01

问题不是“把设计稿写出来”

3 月 26 日的产品仍是传统 Dashboard。两天后,JY(PM)发来偏 GameFi 的地图方向:平移缩放、节点探索、战争迷雾、登录、积分、Weekly App(每周选择参与积分加成的应用)、Recap(每周积分回顾)和通知陆续进入。需求还在 finalize,但上线窗口已经固定。

02

每一个模糊词,都要展开成产品表现

“地图可以缩放”至少要回答:100% 是什么、cover 还是 contain、默认视角、缩放中心、输入方式、刷新行为和边界约束。“Filter”“Live Soon”“Pin”“What’s New”同样需要明确状态优先级、关闭行为和触发顺序,否则设计、开发和验收说的不是同一件事。

  • 地图尺寸 = 2400×1599 × baseScale × zoom
  • 100% 始终铺满容器,不露黑边
  • 滚轮、捏合、按钮、键盘共享同一套边界约束

03

Filter:不是“高亮”,而是改变地图结果

JY(PM)确认 Filter 的语义是只显示匹配 App,不是让匹配项高亮、其余节点继续保留。我进一步确认关闭 AppList 后的行为:如果筛选仍然生效,而地图上没有任何提示,用户只会看到节点莫名消失。最终关闭 AppList 时会同步清除 Filter,地图恢复全部节点。影片使用实际 Terminal 操作展示了这三个状态。

  • 打开 APPS,点击搜索栏旁的 Filter 图标
  • 选择 Consumer DeFi 后,地图只保留匹配节点
  • 关闭 AppList,同时清除 Filter 并恢复全部节点

04

访客登录不是把弹窗往后挪

原本设计要求用户登录完成后才能交互地图。改成“未登录也能玩”,不是简单增加一个 Explore First 按钮,而是直接动了整套流程:Splash / Get Started、Profile 点击、Auth Gate、访客地图状态、登录取消、钱包切换、localStorage 和后端补账都要重新定义。这带来了不小的实现与联调麻烦。最终我提出 Lazy Discover:访客先获得地图价值,本地立即揭示节点;登录后再把待办批量补到后端。

  • 待补队列最多 50 条,写入 localStorage
  • 探索 3 个 App 后每个 Session 只提示一次登录
  • 失败项 30 秒后重试;换钱包时清空归属

05

Weekly App:规则一致性最终由用户验证

我先确认 Boost 是否与锁定时间挂钩。JY(PM)的定义是:只要在积分结算前锁定,就能获得完整一周的 Boost;但锁定后本周不可修改。既然收益与锁定时长无关,“本周不可改”就缺少合理的产品依据。上线后用户反馈强烈,最终规则改为锁定后本周仍可随时调整。

  • 提问:Boost 是否按锁定时长计算?
  • 初始规则:结算前锁定即可完整 Boost,但本周不可改
  • 最终规则:用户可在本周内继续调整选择

06

亮眼效果必须有机制,而不只是视觉稿

战争迷雾用 SVG mask 反向挖洞,feTurbulence 与 displacement 扭曲边缘,弹簧半径驱动揭示。App Detail 使用节点到全屏面板的 FLIP 动画,关闭时按节点当前坐标缩回。

07

PostHog 不是“今晚接一下”

上线前仍在持续增加 Feature,测试窗口却越来越窄。PostHog 也不是装一个 SDK:业务埋点会进入登录、Discover、Detail、错误上报和隐私脱敏等核心路径。我因此提出 Feature Freeze 和 Stage 验证窗口,避免把跨全链路修改当成一晚的无风险任务。

  • 上线前每日仍新增约 2,000–3,000 行 Feature
  • 完整手工业务埋点可能再增加约 2,000 行代码
  • 上线前一周只修 Bug,并保留至少两天 Stage 验证

08

当前可以承接,后续增长要提前规划

JY(PM)转述,运营侧认为 Terminal 效果很好,希望它进一步承担 Rabbithole 的 Featured Apps / 发现职能。两边本来就是同一批 App,所以承接这项职能没有问题。我需要提醒的是,如果后续 App 继续增加、节点交互继续变重,地图渲染和 DOM 成本会越来越高。

  • 40 多个 App 是当时可以承接的规模基线
  • 100 个 App 用于评估后续增长可能带来的地图压力
  • 如果每个节点都加入 Tooltip,可能额外产生约 2,400 个 DOM

09

Stage 不是句号

4 月 28 日进入 Stage,次日收到 “even the haters like Terminal” 的反馈。之后仍继续定义 Notification 与 Recap 的弹出顺序,处理第三方图片 404、BFF proxy、App Hover 和标签可读性。案例的结果不是一张最终截图,而是一套在高频变化中持续收敛产品的方法。

关键时间线

03.26

旧版 Dashboard

真实 API Demo 已存在,但 Weekly App、后端数据和 UX 状态仍有缺口。

03.28

方向切换为地图

JY(PM)发来新设计;缩放、节点、相对坐标仍待进一步定义。

03.31

缩放模型对齐

把 100% / 150% / 300%、设备差异、输入方式和 PRD 对照写成产品可读说明。

04.09

未登录地图改动提出

原设计要求登录后才能操作地图;新方向直接改变了入口、身份和地图状态。

04.13

Weekly App 初始规则

确认结算前锁定即可获得完整周 Boost,同时保留“锁定后本周不可改”的限制。

04.19

Lazy Discover 上线

访客先在本地揭示节点,登录后再批量补账,并补齐取消、换钱包和失败重试边界。

04.20–04.27

身份、状态与范围持续收敛

确认 Terminal 可以承接 Rabbithole 的发现职能,同时提前提示 App 数量继续增长和逐节点交互带来的容量风险。

04.28

进入 Stage

面对当天生产与 Marketing 窗口,完成 Live Soon 等最后变化并提交 Stage。

上线后

Weekly App 规则修正

用户强烈反对“锁定后本周不可改”,最终调整为本周内仍可修改选择。

04.29–05.07

验证与收尾

继续处理 MOSS、Notification、Recap、第三方图片 BFF 和 Hover / DOM 风险。