曾经一直困惑从需求到界面设计的落地过程，从事交互设计工作已经有几年时间了，多少有一点心得体会，和大家探讨沟通。
这些年从事的大多都是B端的产品设计，所以更偏重这类设计比较多，拿到手的是需求文档，一般会说对需求文档进行分析理解，然后就得出了一个产品框架，具体怎样分析理解的呢？
首先提醒自己不能先入为主，需求文档的架构，映射到具体产品的架构，很容易就陷入这套方案，限制思维，难以脱身了。很多时候需求文档的结构，根据不同公司，不同需求人员的习惯都有所不同，整理的方式，不一定在界面上就行得通。
要思考产品需求,有以下几个维度，需要梳理：
逻辑梳理
最先进行的逻辑梳理，是贴近需求文档，最容易梳理的内容，就像每天梳理头发，千丝万缕的，一把梳子按照一个方向，就可以条分缕析，梳理清楚。按照需求文档的模块梳理：
1.当前界面都有哪些元素（大块的）
2.元素之间的层级关系
3.元素有哪些操作及关系
4.如有多个角色，需要梳理各角色的功能模块
方法及输出:这一步停留在脑图阶段，方便讨论内容，便于修改
情景梳理
逻辑梳理完毕后，很重要的一步，梳理情景逻辑，界面设计中，情景故事展示是契合用户心智模型的有效方式，按照情景逻辑进行梳理，相当于，打碎需求逻辑，重新整理。
情景梳理主要有以下几个方面：
1.当前界面的主要情景流程
2.次要情景流程
3.异常情景流程
方法及输出: 这一步可以结合流程图，多种情景以及各角色之间交流情景都可以清晰可见。
关联梳理
以上两种梳理后，对整个产品有了较为清晰的认识，但不应止于此，产品逻辑中的相似、关联、以及功能分割需要在这里进行梳理,并作出提炼
B端产品较为复杂,很容易越做越大,越做越乱.所以这一步梳理尤为重要,可能的合并,精简都可能发生在这一步.
关联梳理的主要方向：
1.当前界面是否和其他页面有数据沟通？
2.是否需要合并或拆分关联模块
3.当前界面引用的模块是否可以提炼为通用模块？
方法及输出: 结合原有脑图,整理完善产品结构图,标注共有模块
状态梳理
最后一层梳理,是从时间维度的考量, 不同状态变更可能在产品中穿插,可能带来界面的变化,对整个产品个元素状态变更的把握,也能和开发和开发沟通更顺畅.
状态梳理：
1.当前界面元素的状态有哪些
2.导致状态变化的原因：操作？外界因素
3.状态变化的影响
方法及输出: 这一步梳理,可落实在表格及原型文件中,表格展示包括触发状态变更的原因,清晰明了,原型中,可展示不同状态可能不同显示.
这几种维度的梳理,就像在黑屋子里看东西，一个灯光（逻辑梳理）能看清物体的一个方面，另一个灯光（情景梳理）可以看清物体更多的信息，多个灯光后，这个物体就清晰可见了。帮助我看清产品的具体形态,为需求转化为设计,提供保障.
网友评论