WEB前端与UED角色对应关系模型

WEB前端与UED角色对应关系模型
由上图（WEB前端与UED小组对应模型）可以看出，UED主要关注的方向是产品前端的设计。

它不仅要求做出产品，更要求做出让用户更乐意使用的产品；不仅要求外在美，更注重内在美。

UED正确的名称应该是UID(User Interface Design 用户界面设计)。

在中国，我们习惯性地把UI定义为狭义的设计，即侧重于视觉上的、图形界面上设计，这是落后的思想。

互联网是个新的服务性行业，对于任何一个服务性行业来说，―为用户提供优质的服务‖是最重要的，UCD（User Centered Design 以用户为中心）的用户服务概念慢慢地渗透着中国互联网行业，UE（User Experience 用户体验）这个新词汇被大家高度关注。

为了区别狭义的UI设计和突出―用户为中心、用户体验‖的概念，它的名字在中国一般被称为UED。

UED小组中的角色：User Experience Designer （用户体验设计师）
主要职责：
需求挖掘、收集、整理、分析
与需求提出者、方案实施者、项目参与者、典型用户等所有涉及人员沟通、协调
组织相关人员讨论并给出最优解决方案，并进行技术可行性、成本权衡等方面的评估、完善制定方案原型、实施计划、细节、规范，并保证实施过程的顺利进行
最终方案模型的评估和改进
Interaction Designer （交互设计师）
主要职责：
协助用户体验设计师进行需求分析、产品可用性评估
通过任务分解、情景模拟等手段把业务逻辑分解为交互逻辑
在沟通和讨论的基础上确定方案原型、基本交互模型及用户操作流程
协助用户体验设计师进行方案原型的评估和改进
Graphic User Interface Designer （图形用户界面设计师）
主要职责：
在深刻理解方案原型的基础上确定风格样式，并进行图形界面设计
在与团队成员沟通和讨论中进行图形界面的优化和改进
制定界面相关规范及注意事项
配合网页设计师进行特殊页面的设计和ICON的制作
Web Developer （网页设计师）
主要职责：
基于图形界面，将方案还原为完整的高质量的WEB模型
以网站重构的思想为指导，保证结构层、表现层和行为层的完美分离
注重代码的质量、性能、SEO和可重用度，保证页面的加载速度、扩展性、适应性和兼容性
配合技术开发人员的工作，进行特殊页面的制作
他们之间的配合依据以下模型：↓ UED内部需求流向模型↓
要点：
沟通随时存在，在任何时间、任何地点都可以发生
他们对各个领域都有所研究，但都有各自专注的领域
他们配合默契，作品就像是出自同一个人
他们在实施过程中的每一个环节都对最终的模型有清晰的概念
↓ UED的外部需求流向模型↓
需求：
流向UED小组的需求不仅产生于小组外部，也产生于小组内部，总体可分为―被动需求‖和―主动需求‖
被动需求：来自于小组外部部门的需求。

如：由于战略调整或市场举措变动而产生的需求、由于业务拓展而产生的需求、由于增添新的功能模块而产生的需求等等。

这些需求一般具有较高的权重和优先级。

主动需求：UED小组内部自发产生的需求。

在日常工作中，小组成员通过产品的可用性评估、用户需求整理、资料搜集、用户调研、竞争对手分析、创新思路等途径发现和总结当前产品可用性存在的不足或有待改进的地方，将这些问题统一整理、讨论和分析，并综合考虑各种成本、技术难度等因素，对其中一些可以临时解决的问题，临时制定解决方案并执行；对其中的无法独立解决的问题，提出改进方案草案并与相关部门沟通，如有必要可提交至上级领导定夺。

这部分需求一般侧重于产品细节及产品可用性方面的优化和改进，在提升用户体验上意义重大，但往往这部分需求最容易被忽视
需求分析：
这是一个需求转化为方案原型的必经环节。

一般要综合考虑多种因素、经历多次沟通才能得出方案原型。

涉及该项目的发起者、参与者、实施者、执行者等所有人员都应该参与进来并给出建议。

但沟通的过程往往由于各方的侧重点、思维模式的不同和对最终产品没有一个统一的认知等因素而变得没有效率或过于发散，这往往存在于需求的提出者和最终的执行者之间。

这就需要UED小组来促进沟通。

基于以下几点理由：
UED小组不是纯粹的产品人员，也不是纯粹的技术人员。

在关注产品的同时，在技术上也有相当的研究和理解。

UED小组可以以很快地速度给出一个可供讨论的基础原型，避免过于发散的沟通。

UED小组会在讨论中替产品最终的使用者—–―用户‖说话
解决方案：
在这个过程中，需求开始转变为方案。

这个过程可能需要三次各有侧重的讨论。

需求的讨论。

这次讨论的重心主要侧重在需求的挖掘和分析、成本分析、商业利益与技术成本的权衡上。

这次讨论将决定产品的一些功能的优先级和取舍。

交互的讨论。

这次讨论的重心主要侧重在业务逻辑到交互逻辑的转化上。

用户体验人员和交互设计师会整理这些逻辑并用示意图（线型图）的形式展现出来，其中包含了基本的交互流程和细节。

这是一个决定产品体验好坏的关键环节。

经过这次讨论，方案已初具原型。

界面的讨论。

这次讨论的重心主要侧重在产品的图形界面上。

GUI设计师会在此之前为既定方案设计基于图形的界面。

这次讨论将决定产品的最终风格样式
以上3次讨论各有侧重，避免沟通过程的过于发散和缺乏效率等问题。

方案模型：
经过以上环节，WD网页设计师会将确定的图形界面高质量地转化为可用WEB界面，模型，模拟出基本的可操作的交互流程，形成方案模型。

方案模型可邀请典型用户或同事进行模拟操作，并收集可用性及用户体验反馈信息，做出相应改进。

最终模型具有完整性、确定性。

该方案模型不仅作为演示，也作为程序开发人员的开发基础和最终产品的参照。

最终方案模型的讨论。

这次讨论主要起到需求确认的作用，保证所有的参与者对最终的产品有明确的概念。

经过这次讨论后，原则上，除细节调整外，该方案不再做需求或功能上的大的调整，这是为了避免需求反复引起的开发成本增加。

方案确定后暂时没有被采纳的改进提议将作为下一阶段改进的参考。

程序开发流程：
具体的研发流程由技术部门制定。

UED人员会跟进至研发流程。

主要协助研发工作，并对一些存在分歧的细节进行协调，保证研发流程顺利进行。

测试流程：
具体的测试流程由测试部门制定。

UED人员会提出相应的可用性及用户体验相关的测试目标，确保产品与既定方案相符合。

上线：
上线后，UED人员会采取满意度问卷等方式对该产品在真实用户中的使用情况进行跟踪和评估。

对发现的问题和不足收集整理，作为下一阶段改进的参考。