我碰巧在Alfa-Bank中创建了一个设计部门，并担任设计总监。 花了五年时间。 结果，我们得到了一个设计系统（以代码形式）和一种数字产品设计方法。 实际上，我将在这里讨论这种方法。 更准确地说，这是我于2018年初在莫斯科，彼尔姆，新西伯利亚和圣彼得堡进行的一次演讲的文本。 五月份，我决定离开银行，现在我可以发表演讲的文字。
在Alpha Lab，我们只是根据Scrum构建产品开发流程，每个团队都是一个独立的部门，能够尽快交付（理想情况下，每周或每两周冲刺）。
重要的免责声明：全文讲述了Scrum团队中设计师的工作。 请记住，这是一个非常重要的警告。 我在演讲中顺带提及了这一点，这是理所当然的事，因此有人可能会失去故事的意义。 对于看板和传统方法（合同设计-布局-组装-行为），此方法可能甚至有害。 因此，如果“ scrum”的概念对您来说是陌生的，请研究该方法-也许它将帮助某人更好地组织他们的工作。 在文字过程中，我倒入了文章和书籍的链接。
截至2017年底，实验室中大约有30个团队（也许更多），几乎每个人都需要自己的设计师。 即使是在相对较大的规模上，在战略，顶级概念和方法级别上工作也更为重要，因此，不可能“技术上”管理30名设计师的工作，这些设计师使用不同的产品，不同的团队和不同的速度。 在这一切魅力中，战术是由每个团队独立决定的。
1.目的：人们使用的工作产品
这样简单的目标。 我们将分析每个词，因为这些词不只是如此。
注意缺少过程词，例如“ creation”，“ design”等。 流程根本不是目标。 目标只能是结果，而不是过程。 但是，全世界的设计师都陷入了流程的精神陷阱，所以他们的工作结果是流程工件，而不是有效的产品。
我有可悲的统计数据。 在“创造产品并影响产品”的十位设计师中，一位专注于结果，其余专注于流程。 它要花很长时间，如果有的话。
在激怒之前，我将澄清：我不会降低流程的重要性并了解它们。 框架，研究，设计，方法论，规范，指南，设计系统，专业软件等。 一旦产品落入用户手中，所有这些都变得毫无意义：该产品有效或无效。
对过程和怨恨的无聊解释如果用户下载了某个应用程序，但该应用程序无法正常工作或无法解决其任务，那么绝对一切都变得无关紧要：数据的收集和研究方式，布局，运行的软件，流程图和灰色正方形的内容，程序员的拼命工作方式在发布之前，该聚会以纪念该产品的发布而传出了多么酷的视频。
任何专业的附件通常都会简单地“加速”或“改善”流程（已经是附件，实际上是多余的现象）会增加流程和官僚主义，而不是解决问题，也不会使团队向目标移动，而是使团队远离目标。 采用相同的原型1 ：开发而不是开发，我们创建的仿真器可以充分发挥产品中10-30％的经验。 和设计。 和研究。 和布局。 以及在布局之前的线框（有些将这一阶段与设计区分开来，并用相同的术语表示不同的含义）。 然后是指南的描述。 还有“作者的监督”（一个偷窥开发人员和咕gr声的非常粗俗的名字-在这里揭示了所有这些“研究”和“原型”细微差别中没有的十亿）。 因此，设计师或经理们没有以产品形式追求结果，而是制造了许多高成本的麻烦事。 诸如“设计者”，“界面设计者”，“ UX / UI设计者”，“研究者”等独立的职业正在增长。 在会议上，他们认真开始讨论粘合UX和UI的合法性，并说不同的人应该这样做，使用不同的工具和任务。 我们不再关注工作产品，而是关注流程，每个附加组件都偏离了实际目标。
您需要了解，这里我们仅在谈论与我们称为设计师的人员的工作最紧密相关的过程（无论谁提出了这个集体概念）。 长期存在的公司中被称为“业务流程”的流程通常不会对产品和用户体验产生最大的影响，因此这些流程已不复存在。
无论如何，回到措辞上。
- 有效的产品是可以用来解决问题的产品。 这是使用产品解决问题的技术能力。
- 该产品是一种整体的整体实体，其成分数量要比单独使用的所有成分具有更高的价值。
- 使用-谈到需求和便利。
- 人是比“客户”，“用户”，“雇员”等更广泛的概念。 在为人工作时，我们会考虑人体工程学和一些标准。
假设该产品无效。 这里的一切都很清楚：它们将不会被使用（至少用于其预期的目的）。
还是不是产品：一组没有任何符号互连的完全不同的组件（这种情况也会发生）。
或者有一种产品，但他们根本不使用它。 失败也可能是任何人：缺乏市场营销，不舒服，速度变慢。
我承认，如果没有人使用它，那么将会有完全不同的设计原则。
当他们谈论敏捷，频繁交付，Scrum和团队合作时，会从不同角度讨论这个想法，但是即使采用这种实践，设计师有时也会以某种方式陷入“过程”的喧嚣中。 我承认这些原因：
- 他们不了解技术及其对他们的影响，
- 无法影响结果（害怕“他们不听”，缺乏动力，发明了从属“他们没有告诉我这样做”）
- 不了解他们的角色
- 在不了解目的的情况下利用scrum，例如框架（另请参见Cult of Cargo ）-那么它绝对不比瀑布更好（甚至更差）
- 在Scrum内安排小瀑布：-)-“首先设计，然后进行前端”，而不是至少工作两个/两个。 出于某种原因，这对于设计人员和开发人员都特别困难（但是，如果这样做的话，那么他们将不再希望返回到微型水-水模型，因为从每个角度来看它都是有缺陷的）。
PS链接到列出的方法学说明，维基百科：
2.设计师在Scrum团队中的角色
通常，设计人员在产品团队中的作用会被夸大，因为他们是根据流程和动作顺序（瀑布）而不是结果来考虑的。
（根据目的类别从结果中正确思考。）
刚按照标准和规范完成所有工作的开发人员最有可能比通过设计师的模型更好地解决问题。 甚至杂货店指标可能会更好。 在完全没有设计师的情况下。
“我们正在等待布局”-如果听起来这样，则说明团队中的流程未正确组织。
（可惜，许多开发人员和设计人员并不了解这些标准-至少是针对Web的W3C ，并且有许多基本原理有助于构建更好的体验。以此类推，对于领先的移动和桌面平台（ iOS ， Material ）有描述/标准。）
注意与Microsoft合作的初创公司-Facebook，Vkontakte，Odnoklassniki和Apple：它们基于工程解决方案（沃兹尼亚克，盖茨），设计师随后加入了这些解决方案。 他们根据目的创建了产品。
首先是一个有效的产品。
（为了公正起见，施乐实验室中的思想家确实很帅，但是后果的程度却完全不同。）
•••
设计师的角色是什么？
增值 。
您可以添加到现有的东西中 ，注意。
在顾客，用户眼中看重价值。
•••
通常，顺序会颠倒过来，然后“等待设计”。 当然，这说明了团队的不成熟和这个团队管理不力。
•••
“版式”是一种过时的事物，是静态网络的遗产，用于遵循杂志和报纸图形的美学和过程。 在产品设计中，这已不再重要，但是在过程和意识方面都保持了这种方法（在没有其他方法的情况下）。
从代码而不是布局开始。
应用-动力学，运动，交互。 因此，产品设计师的工作布局通常是不合适的，并且与目标背道而驰。
这就是为什么高级设计师迁移到具有真实数据的原型的原因。 这样好吗 我认为这是多余的-为什么当您可以（逻辑上）立即对产品进行编程时，对原型进行编程？
最好立即从开发过渡到设计。 从代码开始-以最小的方式执行客户任务的原型。 可以投入使用的原型（稍后回想有关客户开发的信息）。
（开发人员的开放性和成熟度在这里很重要-他们愿意尝试和改进程序，甚至可能会多次重写代码。我敢肯定，很长一段时间都有很多现成的解决方案。）
抒情离题：来自物理世界的例子与纸张相比，物理事物非常有吸引力，因为到目前为止，它比其他事物更清晰。 因此，我将屈从于诱惑，并从平面设计师的生活中进行类比。
想象一下，一种工作产品就是出版物（书，杂志，报纸）的内容。 正确包装并提供给读者很重要。 没有内容，设计就没有意义。 空书使读者不满意。 开发人员的角色，比较作者的角色。 如果没有好的设计，本书的内容仍然很有价值。
并且您可以根据需要进一步分发内容。 顺便说一下，现在内容已在从纸质到电子的各种媒体之间分配。 电子形式的同一本书以不同的格式和读者使用，从而确认了内容优先于设计。
（谈到设计系统：这些是用于快速内容设计的样式解决方案。开发工具，而不是设计工具。）
外卖
实现用户的任务。
从发展开始。 与开发人员（作为美术指导和撰稿人）协同工作。
改进工作产品而不是布局。
考虑目标，结果而不是过程。
产品设计师创建产品，而不是布局。
3.方法
这种方法以及组件库已成为银行设计系统的基础。
我建议按以下顺序工作：
- 识别客户端（用户）的任务，并将其提交为用户案例。
- 定义指标。 我们如何理解用户的任务已经解决？ 提交。
- 提出假设。 提交。
- 客户旅程图。
- 工作原型。 最有价值球员 客户发展。
布局。 （有了团队合作和现有的设计系统，您可以不进行布局）。
客户任务
这里的一切似乎都很清楚，但事实并非如此。 界面假设与客户任务混为一谈，它们是由经理的愿望清单给出的，通常用于不太漂亮的团队操作。
根据投诉（“客户痛苦”）或研究需求来确定客户的任务。
（顺便说一句，我们注意到投诉和任务是两回事，保持冷静头脑，不要急于根据投诉“解决问题”，这一点很重要-任务可能有所不同，并且投诉是由无关的情况引起的。有经验。请使用“五个原因”方法-有时有助于深入了解制定客观任务的基础。）
实现任务后，将其记录为用户故事。 关于这一点的文章和书籍很多，所以我在这里不再重复，请自行研究。
要深入探讨该问题，我强烈建议用户故事映射：发现整个故事，构建合适的产品（Jeff Patton和Peter Economy） 。
两种类型的指标（同时修正两者很重要！）
- 问题“我们如何理解用户的任务已解决”的公式化答案。 我们想要以解决方案的形式获得的东西。
- 数字：相对和绝对值。 更多关于定量指标（财务，速度，客户，时间）。 我们如何理解该决定是成功的。 有一个窍门：通常在演示中，相对值被隐藏，夸大或失去了决策的客观尺度。 例如，“受众群体增长率为3％”-是多少？ 如果是15万人（一个城市型的定居点，有学校，幼儿园，商店和它自己的行政部门），那么这个数字已经是一个了不起的数字，尽管看起来似乎很少。 另一方面，“ 300％利润增长”，如果是每月300卢布，已经是一个可疑的指标。 再说一遍，如果在整个产品受众群体的规模上存在统计错误（例如，每年访问搜索引擎的主页），则有15万人，尽管我们谈论的是同一城市型村庄的人口，但这些规模很可能会被忽略。
通常，结果是在产品或功能已经完成之后才出现指标。 用于报告和精美的演示文稿。 这很可悲，没有技巧，但是相反，它破坏了画面并产生了错误的平静感（总是发生重击）。 关于世界上最好的弓箭手的笑话很好地说明了这种情况。
关于弓箭手的笑话世界上最好的弓箭手
从前有世界上最好的弓箭手。 假设是在日本-为了剧情。 他可以比远处的任何人都更好地击中目标，甚至甚至是罗宾汉如何击中自己的箭头。 阿切尔周游全国，他的技能使其他人感到惊讶，分享了他的经验。
在一个村庄里，他发现了许多惊人的目标，它们位于最意外和最难以接近的地方。 弓箭手意识到师父住在这里，他无法达到的掌握水平。
弓箭手意识到自己的任务已经完成，继续生活毫无意义。 当一个农民经过他时，他正准备举行仪式自杀-sepukka。
“发生了什么，阿切尔？” -农民很惊讶。
“我发现一位大师居住在您的住所中，这在技能上远远胜过我，因此我的任务已经完成，我可以离开这个世界。”
“您可能在谈论最离奇的地方命中目标？” -突然猜到了农民。
“哦，是的，你是对的。”弓箭手遗憾地说道。
-弓箭手！ 要知道：这些是当地傻瓜的把戏。 他随意射箭，后来绕目标射击。 我们都可怜他。 你错了
假设-有关解决用户问题的最快方法的问题的答案
对于该问题始终有几种解决方案。 在开发（设计）上不能局限于一个！ 没有人预先知道哪个会最有效。
做脑力劳动，并提出至少三种不同的解决方案。
请记住，以逐渐变化的布局形式“开发”一个想法是一种解决方案，而不是三个解决方案（或您已成功制作多少个不同的布局）。
为简单起见，请尝试以下三种方法：
- 接口解决方案。 可能还有几个。
- 自动（例如，事件发生时在服务器上执行任务）-无需用户干预。
- 流程-可以在流程中进行更改的内容，以便用户完全不会遇到任务，但是会在适当的时间收到解决方案。
最佳解决方案完全是凭经验找到的（请参见“科学方法”）。 乍一看，即使是最疯狂的解决方案/想法，也必须加以检查。 假设需要检查。 理想的情况是检验以MVP形式执行的所有三个假设。 您将为此制作一个原型。
客户旅程图融入背景
如果您只有一个具有单一功能的小型产品，那么CJM允许您查看用户解决问题的整个过程并找出痛点，真正完成任务。
如果任务是在现有应用程序中开发功能，则CJM将沉浸在上下文中并为该问题提供无缝，无缝的解决方案。 通常，设计师和产品经理会忽略上下文，创建一个“新部分”，传播实体，使导航复杂化，并在界面中造成混乱。
关于CJM的文章很多，您需要自己研究它并将其应用到您的工作中。
您可以从Jeff Patton的《 Custom Stories 》一书开始。
工作原型。 最有价值球员 客户发展。
与开发人员安排并制作一个可行的原型来测试每个假设。 从技术和美学角度来看，这不一定是理想的解决方案-重要的是要创建一种最低可行的产品（ MVP ），在该产品中进行测试时，您可以涉及新客户和现有客户（客户开发）。
« . Lean Startup -» . .
MVP, . .
,
在MVP的开发和原型测试期间，您一定会在每次交付中以及每次用户反馈之后都完善很多小事情。要做的最大工作是按照样式调整并重新测试现成解决方案的屏幕。对产品的重新审视可以提出新的解决方案，进一步简化并重新考虑，使结果对用户而言更加方便和美观-这就是增值的地方。
外卖
用户案例如何确定成功假设（解决方案）CJM原型，MVP，客户开发布局（如果需要）有关信息
您能做的最大的事
, / , . , .
.
, - , . , , . -. : , - , . , , , .
: , , . . , , .
, . ( ), , , , . , ( , «»; — ).
: , . , . — -: , — . -, . , , , , . ( «»), /. / , : / , , .
, .
, .
?
, / (), , , , . . , , .
, .
: ?
? ?
?
30 ? ?
? , ?
?
, ?
— , . .
, . — , : , . .
.
« », .
, . , . . , - . .
,“ 科学方法是由类别，价值，监管原则，论据方法，样本等组成的系统，可指导科学界开展活动。
, , . ( ) . . , .
, , , . - , . , , . , () .»
: .
? . ? .
. , — «» :-)
.
. : , , .
, , . ( ).
: , . : / .
:
- , : , -, (// ). . ( ).
- , , — . , : , «, » ( ), , «», . — .
- , . , — . — /, . — , , , , . - . , — . « ».
合计
- — .
- — .
- «» .
- 只有“专家意见”和“经验”（在特定的界面/产品解决方案中）支持的所有内容都会大胆地发送到垃圾箱中-您只需要专注于观察实际用户的行为即可。
还有另一个好处
我收集了一个主题集-主要是关于设计的，自从我离开银行以来，公司中对设计主题的思考也不可避免。不用粉红色眼镜的工作环境。
下载ePub
看一下集合的内容2022, .
. , , , ( 20 10 ) .
***
— :
- — . , .
您必须了解，这主要是关于在Scrum团队中工作，这在历史上是我最喜欢的合作形式。
***
三个原则：我在产品上经常遵循的原则：
•科学的方法
•一半
•您可以做的最大的事情
***
说明或“成功成功秘诀”-为什么您没有对他人有用的东西，以及我们如何学会欺骗自己。
***
公司陷阱
对我来说令人惊讶的是， 甚至我的陌生人也进行写作和讨论，甚至要求将其翻译成英文以供其他国家的同事阅读。
***
招聘为产品或“ Vanya，找到我们的设计师！” --
公司内部从头开始进行产品开发案例的详细描述。 我喜欢这个故事，它启发了许多朋友和以前的同事，Alpha Eychars在几次会议上都告诉了我（已经没有我了）。
我用与该过程的所有工件相关的链接对文章进行了调味-我们的文章，Molinos的出版物，Kommersant上的文章等等。 我本人有兴趣将一年前的想法与一年后启动该项目所写的内容进行比较。 Umberto Eco的科学出版物之一对此现象进行了描述，在这里我研究了它如何在我的示例中起作用。 有趣
***
我的第一个产品是
这个故事是关于一个同学和我是如何制作出真正的产品来创造公司的。 这个故事已经是1998年的故事了，但它非常具有启发性，它讲述了我的原理和方法是如何发展的，在我的工作中得到应用，有时在这里写到。
***
关于体育
我认为，体育专业的话题已经超出专业主题的范围，被人们遗忘且徒劳。 甚至三年前记得我的人都会明白我的意思：虚荣和工作使我筋疲力尽，这看起来很糟糕。 我希望本文能帮助其他人提前认真考虑自己的健康状况，而不必等待我的可悲结果。