|
我们在白板上标出一个项目需要有哪些阶段。然后我们用一种颜色的便签写出设计师需要在每个阶段做些什么，用另外一种颜色写出我们需要讨论的待明确的问题。
我们对上述的产品还是很满意的，接着我们就与产品管理以及开发团队分享我们的成果。这些成果可以作为他们下一步工作的输入。 为什么我们不采用已有的流程?
毫无疑问的是，我们可以拿到已经发布的经典的流程， 并且可能这些流程可以解决我们80%的问题。但是每个公司，每个团队是不同的。 想要优化工作流要考虑的因素很多。我们的公司目前处于什么阶段?我们多长时间发布一次?我们团队的大小规模?产品和开发的工作模式是怎样的?是使用敏捷、瀑布还是两者综合的开发模式?工作流程需要适应所有的项目，不仅仅是UI项目，还包括CLIs, APIs和其他的开源项目类型。有太多的因素需要考虑。 我们让团队自己来设计工作流程是大有裨益的。自己设计意味着给了团队中每个人发言的机会，大家对最终的成果都有所贡献。 我们最终产出了8个工作阶段，接下来我将逐一进行介绍： 术语定义 设计组长 我们发现需要明确定义设计组长的职责，这样在对设计进行决策时可以很清楚谁有权利决定这样设计以及想要达成的期望是什么。 设计组长是： 整个项目的设计负责人。 对项目的设计方案的易用性、可用性、可行性负责。 除了需要输出设计方案为，还需要对最终产品的效果负责。 在与产品经理、技术组长、开发经理和开发人员合作过程中，需要作为设计师代表。 对于可视化的设计以及用户体验方面有决策权，在制定决策时与产品及开发协商。 负责向干系人收集反馈，并且确保交付符合公司业务目标、设计理念以及品牌要求。 设计类项目 必须要有某种帮助我们在现有的待办清单中组织和定义项目优先级。设计类项目通常是由(产品团队负责的)产品路线图驱动的。也有一些项目是由UX改进或一些组件项目驱动的。 设计项目是由设计团队确认接收的任务。 通常情况下，设计类项目是对要发布的特性或者设想进行用户体验设计，这类设计不一定包括GUI或者CLI。设想可能会是对“发现”轨道的特性想法的验证，未来不一定会真正实施。 每个项目有一个设计组长，可能会有多个设计师。 当设计就绪时(得到其他角色认可)，设计类项目视为“完成”。但是，设计组长仍然需要跟进测试和开发工作，因为可能会存在一些改进的需求和项目。 Mesosphere产品设计流程
第一阶段: 定义 确保你理解待解决的问题，并且这个问题已经在需求、范围和用户故事中定义了。同时，需要确保跨职能的团队在这个问题上达成了一致。 理解谁是提出这个问题或者受这个问题折磨的客户。 与涉及到的跨职能团队开一个启动会。 确保角色和职责清晰。 可视化项目达成目标。 创立于项目相关的文档。(例如：项目范围文档，wiki相关页面和进度跟踪、会议页面，任务，待办) 第二阶段：研究 我们用Dropmark 来记录灵感。
理解用户的问题并且建立同理心。收集尽量多的信息，并且将这些信息整理并转化为团队可接收的知识。 与用户/客户交谈并且尝试体验问题。 与内部专家和干系人交谈，找出拥护者。 看看其他人是怎么解决这个问题的，包括竞争对手或者类似的工具。 记录下来你的分析结果并且在团队内部进行分享。 理解这里是否有一些技术的约束。 第三阶段：想法 跨职能的设计Workshop可以采用6-up方法来激发很多想法。
让跨职能团队的人参与进来，可以扩展你的思路，打开你的脑洞，给出你之前没有想到的一些方向。 使用草图、线框图、流程图。 组织跨职能头脑风暴和设计研讨环节。 为设计团队提供反馈和输入。 检查可行性。对于这点，可以和开发以及产品一起协商达成一致。 第四阶段：设计 我们通过InVision 来管理原型。
用最好的设计来创建一个可测试的概念模型(比如：原型)。在经过讨论并且达成一致后再进行细节的设计。 创建一个可验证的概念模型，比如图形、流程图、可交互的原型(可以使用InVision, Framer等等)。 随着每次的迭代，逐步细化，提高保真程度。 不要在早期就制作保真度太高的概念模型，否则你会发现关注点会失焦：从解决方案的业务流程是否正确被转移到按钮的颜色上。 但是保真度过低可能会无法得到预期的反馈，进而影响反馈的全面性。 第五阶段：验证 和干系人、用户和客户一起来验证解决方案和你的一些假设。得到反馈后对解决方案进行优化，不断循环直至得到达成一致的解决方案。 进行或者参与用户测试环节。 与客户进行直接对话。 与开源社区或者UX研究专家分享工作的成果。 与整个团队确认当前方案的可行性。 与内部干系人进行评审。 第六阶段：交付 我们为大部分的项目都提供了wiki页面，将交互原型和草图文件放在里面。
|
