网站UI/UX内容架构方法

在产品开发的流程中，UX Designer 往往需要参与不同的阶段，包括前期的需求厘清、中期的设计开发以及后期的验证评估等等，不同阶段所面对到的关系人（Stakeholders) 也都不太相同。

而随着设计工具的云端化，共编、共享的功能也越来越完整了，设计部门因此着重于提供单一而完整的设计文件(Single Source of Truth)，而不再像过去一样，比较偏向根据角色分工分别提供相应的独立文件。

过往不同角色会分别产出不同的文件，现在则主要提供单一整合的设计文件

因着设计文件的统一，以及分享的便利性提高，越来越多不同角色会进来阅读设计文件，过去以呈现UI spec为主轴的Wireframe，逐渐转变成为各个开发阶段所使用的沟通工具。但是每个角色在阅读文件时，可能都会带着不同的需求和角度，怎么让各角色能够在文件中找到自己需要的部分，成为 UX Designer 们在编排设计文件架构时所面临的问题。

究竟要如何让设计文件可以更加被易于理解呢？在经过几次的尝试和跌跌撞撞后，我想或许可以从以下三个方向和步骤，来思考这个问题：

 #1 了解需求和目的

不同的角色、关系人往往会带着不同的目的来阅读设计师的设计文件，因此首先必需要厘清的问题是：谁会来阅读？他们为什么需要？以我碰到的情境而言，大致上可以分成五个主要的角色，而他们的目标分别如下：

1、Product Manager:想要确定一开始提出的 Feature Requests 和 Use cases 是否有在此次的设计中被考虑。

2、Project Manager / Architect:需要理解技术架构怎么和设计相配合，譬如说UI上面的信息是对应到后端数据的哪个部分。

3、Co-editors (Visual designer / Writer):需要知道整体的UI 流程，以及各个元素、信息想要表达的意义，才能调整相对应的视觉设计和文字内容。

4、RD/FED:UI 的细节规格，包括UI flow, behavior, style & wording…

5、Researcher / Data analyst:需要明白设计的目标是什么、设计假设为何、有哪些数据需要被收集以及需要利用数据验证什么问题等等。

 #2 厘清需要的内容

根据第一阶段整理出的人物和需求，接下来可以进一步归纳出设计文件所需要包含的面向，过程中会发现，有些不同角色的需求，事实上可以通过相同的主题内容来涵括，譬如说 PM 和 Researcher / Data analyst 都需要理解此次设计要解决的问题为何，只是对于PM而言是一种厘清和确认，对资料分析者来说则是做为他们后续工作计划的基准。因此综合来说，延伸第一阶段的需求，文件内容应可以分成下面四个主题：

1、问题描述：此次设计要解决的问题、需要满足的案例为何？

2、目标功能/假设:根据问题，我们提出的功能为何？为什么我们认为这个功能可以解决此需求和问题？

3、流程架构:为了满足此功能，产品需要发展怎么样的使用流程？跟后端系统间的运作架构有什么关联性？

4、UI Mockups:具体的接口画面和互动流程，以及细节规格规范

 #3 编排文件和架构

大致上确定内容和方向后，最后一步需要思考的便是文件的编排顺序。如同前面所说，设计文件常常被做为一种沟通工具，因此在顺序的安排上，搭配讨论流程和产品发展阶段会是一个比较明确的方向。

基于这个方向，第一大区块需要呈现的便是问题描述、功能设定和设计假设等，这往往也是进行细节设计前，需要先和团队确认的内容。

第一区块示意图（问题描述、功能设定、设计假设）

第二区块示意图（架构流程）

最后一个区块就是最主要的Wireframe 和细节UI Mockups了，这部分的排列方式可以基于 User flow 去编排，主要是让阅读的人可以比较知道整体排序的逻辑，也比较容易找到相对应的内容，Co-editor 可以根据架构迭加上其他内容，而细节的Design spec 也可以直接在画面旁附注说明。

除了这三个区块外，为了方便记录和沟通，我后来也常常把各种相关的会议记录直接列在文件周围，或是直接记录在相对应的 Flow / 功能附近，主要是让各个信息都可以集中在这里，不会散落在各种不同地方，避免日后如果找不到时真的会超头痛的！

这就是我近期在写设计文件时的小小心得，如果你也跟我一样苦恼的话，或许可以尝试看看这三个方向，来找到最适合自己工作流程的编排方式喔！