背景与架构
案例
Buy&Sell Marketplace
在团队共同开发的交易平台中,我将 UX/UI 设计方向、设计系统与自己负责的前端实现衔接起来。
- 3 种角色
- 不同的权限与用户路径
- Figma → Angular
- 将设计系统转化为组件
- 全栈
- 连接 API 与数据的界面
协作: 这是团队共同完成的硕士毕业项目;我的创作贡献仅限于本案例所述部分
一个可运行的学术项目,不将其表述为商业产品或个人独立作品。
设计系统
让基础规范成形。
产品体验
探索、理解并行动。
问题
我的起点是一个问题,而不是一张页面:在交易平台中,每种角色需要看到什么才能做出有依据的决定?买家、审核人员和管理员面对同一产品,却在做不同的决策。
我们研究了常见模式——商品页、销售状态和卖家信息——以理解支撑各条用户路径的信息。这一分析使我关注审核流程:在这里,我们必须决定哪些内容应当展示,哪些操作应当阻止。
基于这一分析,我们定义了草稿、已发布、审核中、已下架、已预订和已售出的生命周期,它同时影响数据模型与各角色的体验。我没有把产品当作孤立的页面:每种状态都会改变谁能够做什么。
方法:参考交易平台的对标分析 · 按角色提出用户假设:买家/卖家、审核人员、管理员 · 信息架构与产品状态图 · 在绘制任何页面之前,先梳理站点地图与各角色的流程.
系统
在 Figma 中,我按原子、分子和组织的层级组织系统,使团队在打开 Angular 之前就能讨论变体与状态。徽标、按钮、卡片、搜索与面板都被设计为需要在代码中保持相同逻辑的元素。
角色之间的差异很快在页头中体现出来:我们需要的不是通用页头,而是与各自权限匹配的入口。我利用这种区分,让视觉层级与每个人可以查看或管理的内容保持一致。
交互原型让我们能够逐一走查各角色的流程,发现尚未解决的决策,并在我实现所负责的前端部分之前调整结构。
流程中的 AI
AI 被作为有记录的加速工具融入流程,而非作者。它用于探索组件变体、加快重复性基础代码的搭建,以及评估架构决策。每个阶段的最终决定都由人作出,并考虑清晰度、无障碍、系统一致性与技术可行性。
- 工具
- Claude · Codex(编程与设计助手)
- 阶段
- 探索变体、搭建组件基础代码及评估架构
- 人的贡献
- Figma 中的原子设计系统、数据模型、无障碍与一致性标准
- AI 输出
- 供评审的组件变体与候选结构
- 选择标准
- 清晰度、无障碍、系统一致性、用户证据与技术可行性
- 发现的局限
- AI 提出层级与流程建议,但不作决定。每项输出都要与原型和数据模型对照审查
- 最终决策
- 每个阶段均由人作决定。AI 加速,判断引导方向
实现
作为 UX/UI 负责人,我定义了视觉语言与共享系统的结构。在开发阶段,我使用 Angular 实现了注册、个人资料和资料编辑流程,并使其与桌面端及移动端设计保持一致。
完整产品连接了 Angular、Node/Express API 和 MySQL。后端与数据库由另一位团队成员负责;我的工作是设计体验,并让自己负责的前端部分对接团队约定的接口。
实现过程揭示了理想原型与团队开发产品之间的差距:共享应用框架的限制、API 依赖,以及由不同成员开发的组件。这些协调取舍是案例的一部分,而不是需要隐藏的内容。
证据
我能够分享的证据包括硕士毕业项目的学术评审、按角色开展的流程功能测试,以及依据 UX/UI 硕士课程所学原则进行的启发式评估。这些工作帮助我检查设计、代码与数据之间的一致性,但我不会把学术练习表述为商业验证。
从原型到组件
系统组织方式
- atoms / badge · button · button-icon · icon · link-icon · toast
- molecules / cards · buscador · user-card · user-contact · breadcrum · report-modal
- organisms / guest-header · user-header · moderator-header · admin-moderator-header
- organisms / admin · reports · incidents · historic-moderator
代码 · 实现证据
import { Component, computed, input } from '@angular/core';
import { BadgeIcon, BadgeIconPosition } from './badge.types';
@Component({
selector: 'atom-badge',
templateUrl: './badge.html',
styleUrl: './badge.css',
})
export class Badge {
variant = input<string>('Como nuevo');
icon = input<BadgeIcon>('none');
iconPosition = input<BadgeIconPosition>('left');
protected label = computed(() =>
this.variant().replace(/_/g, ' ')
);
protected classes = computed(() =>
`app-badge app-badge--${this.cssVariant()}`
);
}frontend/src/app/components/atoms/badge/badge.ts
硕士毕业项目中的实际组件:Angular 的 Badge 原子组件(signals)。它的类型化变体直接映射到 MySQL 枚举——从原型到组件,再从组件到数据。
BadgeEstado = 'Borrador' | 'Publicado' | 'En_revision' | 'Retirado' | 'Reservado' | 'Vendido' ← productos 表中的 MySQL 枚举
证据
开放工作成果,接受审阅。
原型是流程中的一部分:它记录了支撑产品的系统、决策和流程。
在 Figma 中打开设计收获
我认识到,Figma 中的原子设计只有经得起交付才有价值:前端结构必须保留同样的逻辑。
即使审核流程在产品首页上几乎不可见,它仍然会塑造数据模型。
按照数据库枚举为前端定义类型,帮助我限制界面不应允许的状态。
开放问题:信息架构如何影响非技术岗位人员对管理系统的采用?
联系