协同设计–成功的企业产品设计指南 _协同设计

本文概述

认识玩家
如何与利益相关者合作
企业中的设计不一定是噩梦

你可能听说过敏捷软件开发, 看板流程管理和精益UX。协同设计是企业产品设计的另一种哲学和战术方法。
协作设计是在参与性, 参与性和逼真的全手或大脑信任环境中进行设计的过程。它不是在真空中进行设计；相反, 顾名思义, 协作设计使设计师处于各个团队和部门的中心, 与每个人一起工作以构建具有凝聚力的产品。这样, 就不会遗漏任何人, 并且可以在所有利益相关者的参与下构建产品。
每个企业组织都是不同的, 围绕任何想法或任务来组织利益相关者似乎就像是在放羊。在本指南中, 我们将介绍与主要参与者合作的提示和技巧, 不仅可以获取他们的意见, 还可以采用这种以设计为中心的新方法来吸引他们。

文章图片
认识玩家设计师在很多事情上都很出色, 但是他们的角色始于解决问题。这需要了解专家的身份并与他们合作。产品开发团队的每个成员都有自己的需求和责任, 因此了解它们与实际完成给定的任务一样重要。
因此, 事不宜迟, 让我们与团队见面：

产品经理定义产品和功能的范围, 要求和开发迭代周期；他们通常是最终功能是/否之前的功能守门员, 并经常与包括行政人员在内的整个组织进行沟通。
工程师制造产品, 因此他们了解技术能力和局限性。这使它们成为确定主要问题的关键资源, 包括开发时间表, 使用的技术, 范围以及通常的设计可行性(如果在技术和时间限制的情况下甚至可以实现我们的概念)。
数据库和系统架构师知道如何集成数据, 并对继续保持现有产品/平台之上的保持性能所需的知识有深刻的了解。
内部主题专家(SME)非常熟悉业务流程, 用例, 历史和政治, 以及管理层, 客户和用户的总体期望。
销售着重于向潜在客户展示产品。这使销售成为第一联系点, 因此他们对产品的了解对于关闭(并经常创建)潜在客户至关重要。
培训师(或SaaS中的客户成功代理人)可以直接与销售团队以及新用户或试用用户接触, 他们可以提供大量有用的信息, 以说明产品在体外和体外的性能。

文章图片
当所有参与产品工作的各方都参与设计过程时(敏捷方法论的基本原理之一), 最终产品获得成功的机会就会大大增加-不是因为设计师与利益相关者一起工作, 而是因为利益相关者经常而不是以我们可能不了解的方式了解特定的用户和业务需求。协作始终似乎是最好的选择, 但是我们该如何做呢？
如何与利益相关者合作产品经理, 产品的关门和计时人员
产品经理通常对产品有个人的依恋, 并在公司内部抱有很高的期望。当出现问题, 未兑现承诺或要求新功能时, 他们还必须回答产品的用户或客户。
他们高度重视简单的沟通, 需要及时了解进度, 问题和任何更改。他们喜欢首先并经常查看草稿, 并且因为它们可以在不同的规模上工作(从直接产品开发到实际操作, 甚至有很小的改动, 都处于多个层次), 因此你与它们之间的互动可能会发生很大的变化。
【协同设计–成功的企业产品设计指南】由于PM花费大量时间与各种利益相关者(内部和外部)进行沟通, 因此重要的是要使他们保持警惕, 不要期望他们与你联系。为你的PM设置定期签入, 以呈现迭代草稿, 听取他们的反馈, 并始终以下次会议的操作项目列表结尾。

文章图片
很快就会知道他们的产品功能目标是什么。 PM知道设计师是问题解决者, 因此设计师需要提供数据和分析以证明其推理。正确与否无关紧要。证明制造最佳产品是目标, 并且你将获得PM的信任！
工程：负责将设计变为现实
工程师(也称为开发人员)是最接近产品的人员。他们建造它！这使他们具有优势, 因为他们可以直接体验并测试实际使用中的产品的各个组件。这样做之所以如此出色, 是因为毫无疑问, 他们会发现任何设计中的弱点(有时甚至在构建任何东西之前), 这是双重的, 因为在如此多的层次上, 在编码软件之前发现缺陷是巨大的优势。
赢得工程团队信任的最佳方法是制定全面而完整的产品规格, 或者尽早参与其中……或两者兼而有之。
当开发人员被认为是真正的利益相关者时, 他们乐于讨论用例, 场景, 技术挑战以及克服它们的选择。
很容易忘记工程师是真正的产品架构师；他们对解决设计师的问题有既得利益, 特别是当挑战困难或可以通过其他方式解决时。

文章图片
数据库和系统架构师, 数据结构的守护者
数据库和系统架构师知道该产品如何在后台工作。他们完全了解数据的存储和结构方式, 可以集成的内容以及所有系统之间如何通信。与产品如何与各种系统交互(这是他们最终负责的)相比, 他们倾向于较少关注产品如何为用户服务。
对于以用户为中心的设计师来说, 处理它们可能特别困难。重要的是要记住, 即使数据库/系统架构师从不与最终用户进行交互, 他们的重点始终是通过产品可靠性, 速度或简便性来使这些用户受益。
如果没有专家的投入, 他们对于数据结构如何运行的知识以及对产品功能所做的任何更改都会很容易被遗忘。重要的是邀请和邀请系统架构师参加有关产品变更的会议和讨论, 即使他们的职位似乎没有直接关系。
与系统架构师合作的一种方式是创建一个清单, 其中包含以下问题：

功能X是否会影响当前的数据结构？
考虑到当前的体系结构, 是否还有其他设计/开发工作？
设计Y是否与任何现有的用户输入/输出冲突？
功能X是否影响任何外部服务？

这个简单的清单将为你指明正确的方向, 即使你不了解预先存在的(也可能是)整体数据结构如何工作。任何被检查的地方都是应该通过简单讨论进行调查的领域。

文章图片
主题专家和业务分析师, 信息向导
主题专家被恰当地命名；他们是主题领域的专家, 可以成为拥有独特而宝贵信息的金矿。通常, 他们在该领域获得专业学位, 或者他们一生的大部分时间都在行业中工作。他们对业务的运作方式有亲身实践的经验, 并且回想起漫长而??痛苦的历史和政治, 将每个人带到了今天。
业务分析师了解组织如何运作的来龙去脉, 并且如果有可用数据但没有内部专家的话, 通常会执行与SME相同的功能。
与中小型企业(SME)合作, 以了解管理层如何看待该项目, 以确保满足内部期望, 并且你没有踏入危险境地。邀请分析师参加设计会议, 提前告诉他们他们是专家, 并要求他们分享有关历史失败, 政治冲突以及其他对成功发布产品可能至关重要的问题的知识。

文章图片
客户成功经理, 新客户的联系点
当销售最终吸引新客户时, 培训人员(或对于SaaS公司而言, 客户成功经理(CSM))将接手教新用户如何实际使用产品。因此, 不用说培训人员会花费大量时间与新手进行交谈。 CSM具有独特的视角, 因为他们与通常不参与其公司购买决策的客户互动。
凭借这种独特的视角, 培训师/ CSM可以为客户入职和新用户行为提供有价值的信息, 以进行设计决策。许多企业组织跟踪并监视其新客户如何使用各种产品, 并记录从呼叫到投诉的所有内容, 但是培训师对客户真正遇到的困难有所了解。
在所有主要的设计会议中都请一位高级培训师, 并询问与他们有关的任何决定。提出诸如” 最严重的三大客户投诉是什么？” 之类的问题。而且, “ 新客户平均对产品满意吗？” 并且, “ 你认为哪些更改将为你和你的团队带来最大的积极影响？” 这样, 我们都了解幸福的道路是什么。在客户实际使用产品的所有方式中, 培训师都是我们的耳目。

文章图片
销售, 产品与客户的首次联系
销售和设计常常是矛盾的。一些组织是由销售驱动的, 而其他组织则不是, 但是无论如何, 目标都有明显的不同：销售团队希望增加销售, 而设计则希望改善用户体验。它们并不总是对齐的。
不一定如此。大多数销售人员都具有非常合理的挑战要面对：他们对产品决策几乎没有控制权, 被要求做出他们无法真正兑现的承诺, 并被迫实现特定的收入目标。销售和产品团队经常引起激烈的争论也就不足为奇了！
但是, 就像培训师一样, 销售组织对客户需求有独特的看法, 而且通常这种看法是小额销售与引进鲸鱼之间的区别！了解销售团队难以应对的不同领域。尝试参加各种电话会议, 并了解这些潜在客户如何交流。
这将打开与销售的对话。不仅仅是要听取他们的需求；从初次沟通到入门后, 每个阶段都将改善潜在用户的体验。找出销售人员从潜在客户那里听到的最多的信息, 完成交易时面临的挑战以及交易完成后最大的担忧是什么。

文章图片
企业中的设计不一定是噩梦作为设计师, 所有这些活动部件的管理都可能非常艰巨, 尤其是当你在官方术语中不被视为” 经理” 时。作为跨团队交流, 需求收集和设计反馈的关键利益相关者, 你应该在某种程度上可以接触到所有这些专业人员。
做到这一点的最关键但最简单的方法是听取各方意见, 并认真对待他们的反馈。在大多数组织中, 下一步是获取反馈并与产品经理一起将需求组织为可行的工作。
从那里开始, 这取决于优先事项和填补空白。最终, 目标是设计最好的产品, 我们需要所有产品开发人员的帮助。认识到每个角色都很重要, 并让这些人员意识到他们在产品开发周期中的价值, 这使他们能够提供设计师需要的信息, 以便他们做出更好的产品设计决策。
? ? ?
在srcmini设计博客上进一步阅读：