标签：color 文件 问题 on 工作 管理 设计 用户 ui
最近在设计一个庞大的产品体系，在设计的时候跟领导和其他同事交流的过程中发生了很多思维碰撞，在此记录：
1.关于风险问题
对整个产品的前期来说，风险识别是不是重要的工作。目前有两个意见：
1）应该尽可能的识别各个级别的风险（尤其是根据以前经验积累的风险），考虑风险应对措施，减少项目失败风险。
问题：
初期容易陷入细节讨论，前怕狼，后怕虎，不利于整体规划。
细节性的风险可能不在领导的管理范围内，你不能让领导去关心一个很细小的技术问题如何实现。因此容易造成领导的反感。
2）不应该考虑过细的问题，只需要考虑大的风险即可。等遇到风险时，在根据实际情况解决风险。
问题：
容易忽略一些极其重要的风险，一方面不利于架构设计，造成设计的缺陷高。另外一方面后期在进行风险规避的成本会极高。容易拖延项目工期，造成项目失败。
个人意见：
还是应该考虑各个方面的风险，不一定在初期专门来进行风险的评估。初期的风险主要来自于以前项目的经验。单是对以前项目中遇到的风险要有足够的重视。避免出现以前出现的问题在后期还会出现的问题。
2.关于用人的问题
在前期规划时，碰到一个问题，对于组内UI设计师的岗位职责的问题，如果进行人员安排的问题。
从目前的实际情况看，国内小企业中的UI（UE）设计师实际上在干一些平面设计的工作，界面布局，用户体验一般是开发经理或者产品经理说了算，而架构师也从实现角度给予意见，因此UI设计师的限制很多。
从目前的规划中，我们期望对UI设计师的职责有两个方面的声音：
1.按照现有的工作来进行规划；
优点：风险小，但是开发经理，架构师需要负责更多的工作。
2.让UI设计师独立完成产品的UI设计工作，包括了解用户需求，设计出良好的用户体验，又能方便系统进行开发实现。
优点：让UI设计师有更充分的设计空间。
缺点：风险高，有很大的风险造成项目延期。
个人意见：
采用第一种方案，当然在真正实施的时候，可以给予ＵＩ设计师充分的讨论空间。但是一定不能交给UI设计师之后，其他人员就不在参与。
3.关于初期设计颗粒度的问题
关于小系统的设计，一般来说都是在初期将所有的情况考虑好，之后再进行各种文件的编写和设计。因此一般不会出现大的设计偏差。
但是在大的系统设计过程中，如果继续采用这种方式，容易造成对需求理解不清，无法工作的问题。
自下而上的设计：
初期工作量巨大，不容易理清思路，但是一旦理清，后续工作容易开展，而且不会出现大的偏差。
在这个过程将能想到的所有问题，一个个进行确认，知道所有问题确认完成。
自上而下的设计：
初期工作容易开展，领导层容易接受，但是后期在具体的设计和实现时容易出现变动，甚至项目失败。
个人意见：
个人还是习惯采用自上而下的设计理念。
标签：color 文件 问题 on 工作 管理 设计 用户 ui
原文地址：http://www.cnblogs.com/sdjnzqr/p/4019290.html
