重新设计的故事改变了ISPsystem的开发方法。
我于2016年4月加入ISPsystem。当时，产品设计的情况如下：产品决策由管理层和程序员制定，没有设计师或设计师。 市场情况要求产品具有“其他接口”，因此管理层决定重新设计
BILLmanager客户部分。 这本来应该是一个测试气球，这是对采用新设计的东西的首次尝试。
我是公司中唯一的UX设计师：我研究了现有产品，研究了用户，并熟悉了合作伙伴及其营销人员的反馈。 这些是产品设计的常规做法，同时考虑到复杂产品的细节。 产品经理给了我很大的帮助，因为他最了解产品。
每周我都会以原型，电路等形式向公司管理层展示结果。 这类似于客户设计师与客户合作的方式，各有利弊：您可以减轻决策责任，主要是将其“出售”给管理层。 但是，由于我已经在一家产品公司工作，并且管理层在这些事情上信任我，因此我们很快就开始合作开发我开发的解决方案并将其变为原型。
开发人员遇到原型
到2016年8月，BILLmanager客户的原型已以其概念形式准备就绪。 产品的旧版本的功能已完全转移到新界面，并进行了一些改进。 从视觉的角度来看，原型开发得很好，但是我想要更多，所以我从第三方公司订购了视觉设计。 但是，我们很快意识到这种尝试是不成功的，需要在视觉组件上进行不断的迭代工作，并且我们需要在工作人员上使用视觉设计师。 在几个月内，我们开发了自己的视觉语言。 实际上，那时我们拥有未来设计系统的多个部分：视觉语言，元素和模板。
同时，从2016年8月左右开始，开发人员开始实施新界面。 伙计们认为原型可以替代技术任务。 在这种情况下，问题开始大量出现，归结为一件事：我们是在做程序员快速而简单地实现什么，还是设计师设计和发明了什么？ 为了快速解决这些问题并简化沟通，我们创建了一个设计师和前端团队。
UX部门由设计师和前端设计师组成的团队
到2016年秋天中旬，在我的领导下，公司成立了UX部门，该部门由UX设计师，视觉设计师，前端标书和测试人员组成。 我们的近期任务是在2017年3月底之前通过一个新界面（我们在家中使用BILLmanager）启动ISPsystem个人帐户，而我们遇到了两类问题。 开发人员无法很好地预测他们的工作时间，而且我们不太了解如何在开发人员和设计师之间建立互动。
我们给开发人员的东西
使用Sketch和Zeplin时，设计师和开发人员之间的交互非常简单。 但是我们在交互式原型中拥有150多个页面，我们学会了将其用作程序员的TK替代品和测试人员的规范。 我们不想在Sketch中使用不同的状态渲染所有150多个页面，而得出的结论是，我们只会对唯一的页面执行此操作。 同样，所有元素都应该出现在Zeplin中：按钮，表单字段等。一段时间之后，我们了解了这种方法的名称-这是一个
基于原子设计的
设计系统 。 它仍在开发中，但是设计人员和开发人员已经在使用它。 设计系统公司中的最后一名是视觉设计师。
结果，我们为开发人员提供了两种类型的工件：
- 在Zeplin（或者已经在Figma中）变成设计系统的布局，
- 产品原型，可以替代Axure生成的HTML形式的TK。
同时，UX设计人员随时准备告诉开发人员和测试人员其工作方式以及外观。
与设计师合作
2017年2月，我们决定提高预测截止日期的准确性，并尝试实施Scrum。 Scrum的复杂性在于，团队成员的能力和文化差异很大。 设计师与程序员不同：我们以不同的方式计划任务，对好的结果持不同的态度。
这是我们构建流程的方式：
- 设计师向前冲刺；
- 有一个总体上可以解决的原型待办事项列表，您可以在其中查看整个产品的外观。
- 在计划冲刺时，设计人员提供计划在冲刺中完成的产品部分的原型和模型。 这些原型由UX设计人员进行了详细描述，以使开发人员可以设置和分解其任务。
- 在进行规划时，UX设计人员会积极地建议开发人员和测试人员哪些工作以及如何工作；
- 在计划时，产品经理必须告诉UX设计人员计划在下一个冲刺中完成产品的哪一部分，以便UX设计人员可以计划自己的工作。
开发人员很快意识到了UX设计器的价值，当不清楚如何以及如何工作时，可以很快解决。 冲突仍然发生，但是Scrum的实践，团队合作和共同目标有助于克服这些冲突。
测试人员与它有什么关系？
测试人员在流程中的作用非常重要。 这是最了解产品功能的人。 测试人员是第一个查看UX设计器原型的人，并迅速就原型合规性和功能性提供了反馈。 批准的原型成为测试人员了解产品工作方式的知识来源。 双方对密切合作感兴趣。
结果，团队按时发布了ISPsystem个人帐户的新界面。 我们学习了如何在Scrum上工作，从而预测了由前端和设计人员组成的UX部门的工作。 到2017年夏天，他们面临一个新问题。
BILLmanager是一种灵活的产品。 这对设计师来说是个问题
当设计师绘制海报，排版书籍或为杂志做封面时，他会使用静态信息。 它具有特定的文本，某些图像和其他内容。
当设计师设计应用程序或站点界面时，信息不是静态的。 有关数据可能是什么的信息，但数据本身不是。 假设有一个博客，每个博客条目都有标题，注释，发布日期，图像等。没有特定的标题，但是可以理解总会有一个标题，并且日期总是有日期格式。 任务变得更加复杂，我们有数据类型，但是没有数据：我们需要考虑内容可能是什么，可以并且应该对此施加什么限制。 最有可能的是，它的艺术价值要低于海报，但设计师希望获得一种美观，方便和可理解的结果。
对于BILLmanager，托管服务提供商的管理员可以更改设置，例如，对于专用服务器的订单形式，字段集可以不同。 在一种情况下，我们肯定会拥有处理器，磁盘和内存，而在另一种情况下，它将（（或将会，但是，例如，将是一个）字段）没有，这是无法预测的。 在这种情况下，设计人员甚至没有固定的数据集，我们不仅不知道特定的数据，也不知道这些数据的类型……这使工作变得复杂。
当我们开始制作盒装版本时，测试人员开始检查BILLmanager中所有可能的设置。 然后很明显，一方面，原型还不够完整，无法涵盖BILLmanager灵活设置的可能性。 另一方面，旧产品的体系结构不够灵活，无法实施大量设计思想。 从2017年秋季到2018年春季，我们重新设计了原型并寻找妥协方案以解决此问题。 由于对设置有一些限制，他们于2018年5月发布了
BILLmanager 6 Beta客户端部分的盒装版本 。
用户体验设计师
在用户体验部门以BILLmanager的灵活性解决问题时，管理层决定处理公司其他产品的接口，并在其他团队中实施Scrum和设计流程。 我们从VMmanager 6开始，组建了一支由不同能力的参与者组成的成熟产品团队，能够自给自足地创建产品：后端，前端，测试人员，UX设计人员，产品和项目经理。 显然，所有其他产品将由同一团队逐步开发，我们开始逐步过渡到用于管理产品开发的矩阵结构。
在这种情况下，UX部门应该不再是产品团队之一。 在BILLmanager 6 Beta的客户端部分发布之后，大多数UX部门成为BILLmanager团队的一部分，现在致力于解决体系结构问题和客户端部分的移动版本。 同时，我们开始着手建立可以同时使用所有产品的UX部门。
每个产品团队的UX设计师。 设计能力中心
ISPsystem具有四个复杂的产品。 我们确保每个团队都有自己的UX设计器。 这是负责其产品设计的人。 他的职责包括准备用于sprint计划的原型，并控制开发人员所需的一切都在pixelperfect版本中。 他是团队设计公司的设计方针的负责人。 他的任务之一是确保开发的结果是与设计相匹配的产品。
我们还有几个人构成公司设计能力的中心。 它包括一个视觉设计师。 该中心形成公司产品的设计政策，并在设计系统上工作。 她还以团队方式教UX设计人员，解决最复杂的设计问题，教开发人员，产品和项目经理如何与UX设计人员合作，并在Scrum团队中实现设计过程。