为了阅读效率，直切主题，直抛结论，并按照" 内因- 外因 “ ”微观-中观-宏观“ 的顺序拆分讲解。

一图搞定产品设计流水线 《产品设计生产流水线-全局模型》

左漏斗图A: 极不稳定的产线                                        右漏斗图B: 相对稳定的产线

最左侧:   工作流中的工作者                                    最右侧：从想法到落地经历过程

流水线上每个岗位职概括都在做3件事，解读、产出、推进（再循环）。

解读他人需求或要求- 做好自己工作-交付 

循序渐进，好比盖楼打桩，缺一不可。上图中，我把从业人员中产品经理放在上游，测试童鞋放在下游，是基于大部分公司驱动模式（下的组织架构中岗位），若你在设计驱动型公司，那么上游就是设计(咨询公司) , 若是技术驱动，开发就是上游。

一.输入质量决定输出质量，但是如何保证输入质量？

1.答题前解清题？    -  一层、基础

2.解题后紧扣主题    -  二层、验证 -逻辑自洽 

3.出题是否正确？    -  三层、再定义问题 -设计思维 IDEO

二. 如何保证随时随地“稳定”输出?   

我多年经验总结必须利用“工具”和“大家”的力量，建立在两个抓手： 

利用沟通工具同步（大家）思考，利用思维工具

1.工作习惯 - 解题、自查表、设计习惯、

2.产出规范 - 设计、文档规范

3.交付规则 - 协作两方，80%明确的规则以及20% 不明确的机制

4.管理       - 情绪控制、时间控制、项目控制。  先有控制，再谈管理。

1-4逐层提升难度，量化方式和复杂度也逐级提升

无论是作为产品，还是设计师，排除上下游de不确定因素，要整合信息！整合信息！整合信息！

----------  上述都能做到，继续往下-------------------

熟练到精通de突破点 - 分层 ，我引用下经典模型《用户体验要素》，出自同名书籍

概念基石-产品体验五要素

分层，“即区分再归纳，通过对比 1.共性  2.差异性 ， 将概念拆解到最细（统计/量化）

若你精通上图，还懂量化，那大致能感受到“进步的阶梯就是区分再量化”

----------  还有兴趣，往下看-------------------

           "物质是能量的，能量是信息的" 

                                               -  -  by吴军「信息科学家、原腾讯副总裁」 

驱动物质的是能量，而驱动能量的是信息，驱动产线上所有人 (角色)把项目做出来的是“信息”（其中含目标、目的）。我们大家熟悉的是PRD , 也称产品需求文档，但其实工作中并不止这一种。（后面附表《交付产出物一览》）

好的输入决定好的输出，这句话相信大家不陌生。 然而怎么度量需求文档的好坏？？？

对于大部分的从业者来说都是一座高墙，无论是设计师还是产品，往往会陷入，设计师来说或开发来说，只能靠PRD文档规则来评价，并不能避免"需求"的黑洞或是残缺，更别提需求可能是伪需求。这种情况自然是屡见，所以就孕育出了，设计思维和敏捷开发。从问题的根源去避免问题。

设计思维

且国内，大部分企业和机构只有上游能改变输入信息的好与坏，下游只能通过产出交付物“质量&规则 ”来约束限制上游产出"需求"文档，并不能左右其质量，这也为什么，很多团队招募了“执行团队”再牛，也很无法为产品CEO产品的逻辑“坑” , 开发需要看设计师的设计稿。

信息决定能量的去向，能量的去向决定质量。

敏捷开发

前情提要

对于互联网“商业UI 、UE设计师来说，日常是"表现层、框架层”的工作，无论是主项目(赚钱)或新项目(不赚钱)，都经历过设计做了很多界面和交互稿，但"无用功"的情况。这就是为什么？

有点项目经验的设计师，一定会在设计执行前去推敲需求合理性和逻辑性，即“结构层、范围层”的工作。但是仍可能是加班、徒劳赶工，这又是什么？

即便是设计职场老司机，也偶有在项目中翻车现象，这又是为什么？

如果没从上图看懂，继续往下

第一章、自身原因                 基层必看

第二章、设计团队内部原因    基层必看

第三章、外部团队原因          中层必看

第四章、组织架构原因          中层必看

第五章、企业战略原因          中层必看

如果你是设计高管，不必看了，因为设计师管理和设计执行管理，请看下篇

PS: 在我看来设计基层执行问题，中层管理，都能用"规则"约束，毕竟管理只是手段，领导才是精髓。 

第一章节  自身原因    

新人设计师  (有设计师带，但没经验)

1.设计执行前没有实施"设计勘探"  -  规范、团队过往案例

2.执行中没有更新信息 - 需求问题、上下游沟通

3.设计产出后，没有自查

4.交付前没有验证

高级设计师  (有设计主管或上级、有一点经验)

1.执行前没有做”需求勘探“  需求转化产品需求转化为“设计”需求

2.没做竞品分析  行业案例、行业规范

3.执行中没有量化工作量，和产能

4.沟通汇报问题

资深设计师  (有经验、自己负责项目线)

1.需求评估 - 分析、梳理、量化

2.设计目标-执行计划

3.项目管理-进度管理

4.效率- 质量和工时

关于能力分级，除了某些大厂有明确的职级量化体系，其它公司都是”很随意“。自己对应就行，至于如何考量自己能力，请看《》篇

1，

好的输入是好的输出的前提，但是怎么做到好的输入？ 

斯坦福的设计思维/  IDEO设计思维

能力突破点  - 下图来源于网络，出自书《用户体验要素》

除了对于项目"产品"的“用户体验五要素"理解和运用，还有就是在工作中，不断通过设计稿展现自己的思考和能力。怎么做到，只有靠自己”刻意练习"。

需求文档好比是输入指令的说明书，”说明书“写得好不好，对于后续开展的工作起到关键作用，

后话，有相对稳定输出交付能力的下游开发团队，固然非常重要，但是可遇不可求，作为设计师，落地验收工作好比是工作的”最后一公里“，重要程度可见一斑。

分工产生效能- - 无论是脑力工作还是体力工作，大道至简亘古不变。

明确分工以及协作规则是效率产能提升的前提，

A情况详解

A情况是商业设计师团队遇到的最可怕问题，所以我将其做成了图

关于“奇点” - -   当设计师工作产出，设计稿成为下游开发评审或预启动节点的基础时，"设计稿"在项目中权重就变得过重，我称之为”奇点“

用好奇点能提升”设计价值“，用的不好就是给设计团队挖坑，而往往大部分团队是在走后者道路。

原因

1.没有意识到“设计稿”权重那么高 - 无知

2.知道不知道怎么做 

3.知道怎么做，却无法改变环境

交付产出物规则-  涉及 需求文档、泳道图、功能流程图、原型

0.交付产出物是信息的载体，产出物规则和标准相当于是信息的范围和信息准确性基线。

1 .在没有明确的上下游交付产出物规则的情况下，沟通往往不能挖掘并解决原型或需求文档中的隐藏问题，设计师需要用设计产出来解决或是发现需求问题。

2. 发展中的项目线，按产品的生命周期，用不同的交付产出物规则和标准。

  如:   

      1.雏形期的产品  

     2.

     3.成长期

      4.中年期

总结:错误的输入-错误的输出

- - - - -- - - - - - - - - -- - - - -- - - - - - - - - -- - - - -- - - - - - - - - -- - - - -- - - - 

沙堆建楼 需求不停改，设计不停改

工作中大几率出现的坑

上游产品：需求和目标、目的断层、功能需求、设计需求不明确

中游设计：1.设计团队无敏捷，UI视觉的高标准标准与产品开发对于设计产出标准不一致，且不能满足快速更新迭代产品开发节奏

                 2.设计价值被自我否定 由于经验不足或能力不足，违背经济学第一性原理“分工产生效能”

下游开发：开发验收标准和规则不明确，导致设计师验收工作增加，消耗精力且无实际“显性”价值提升。

设计解决方案 

解决方案

1.敏捷设计

2.敏捷团队

3.敏捷组织

方案原理

模型思路：漏斗模型、双砖模型、PDCA/OODA、叠叠高、奥森豪威尔象限(四象线)

针对痛点：公司或团队中，产品-设计-开发工作流混乱无序，或不规范、无明确标准

导致问题：设计频繁修改、设计师做无用功、设计稿(信息载体)权重过高

根因：职能划分不明确、工作流中交付产出物（信息载体）没有标准和规则、

- - - - -- - - - - - - - - -  扩展阅读，非核心内容，可跳过 - - - - -- - - - - - - - - -

应用方法论和理论：思维可视化、设计思维、用户体验五要素、项目管理和人力资源管理等

管理难点: 传统的KPI类考核机制不能衡量设计价值、对设计师更不能起到激励作用

关于标准- 相当于目前团队中产出(交付物)的中位线，也是未来提高的基线

一套标准- 不能用一套标准用语

双标

多标准

标准策略

- - - - -- - - - - - - - - -  扩展阅读，非核心内容，可跳过 - - - - -- - - - - - - - - -

Powered by Froala Editor