在公司中，设计通常完全取决于设计师。 尽管有“阵线”和“ mobilshchiki”的抗议声，他甚至可能会突然完全改变它。 我们有不同的意见：设计师的内部世界观或开发商的远景不应极大地影响产品。 产品设计是与客户互动的业务的可见部分。 设计师无法亲自介绍自己的“愿望清单”，而必须关注客户的需求。 良好的产品有机地发展，着眼于客户。 这适用于功能饱和和设计。
设计者不应该是应用程序需求的载体；企业应该决定它将是什么。 无论由谁来设计ePayments，网站和应用程序都将变得美观便捷，并且样式不会在180°范围内发生巨大变化。 该原则对前端和移动开发人员有利。
今天，我作为项目设计师Timur，将告诉您我们如何重新设计移动应用程序以及设计系统的外观。
一切如何开始
当我第一次进入该项目时，该应用程序如下所示：
在此之前，通常是这样的：
什么不适合我：
1.应用程序无法扩展。 最初，我们有2种货币（欧元和美元）和2张卡（相同货币）。 它们在视觉和逻辑上都紧密地联系在一起。 美元部分是美元卡，依此类推。 然后添加了RUB，整个布局开始“开始”。 要添加新元素，必须使用拐杖。 EPayments计划扩大货币种类，我们需要弄清楚如何在不给客户带来麻烦的情况下添加货币。 在所有屏幕上的行为应保持可预测的。 如果一个屏幕上的货币列表是通过特定的行为模式处理的，则在另一屏幕上，应该重复使用货币的模式。
2.过时的设计。 该应用程序看起来非常“垃圾”并且很难，我想要更多的空气和更少的不必要元素。 如果5分钟后眼睛开始疲劳，为什么我们需要渐变和“透明”？
3.设计上的差异。 对于iOS和Android，有2个根本不同的应用程序。 如果一个人从一个操作系统切换到另一个操作系统，他将失去所有累积的用户体验。 三星的所有者无法告知iPhone的所有者如何进行该操作。
4.非最佳工作流程。 当我们有了一种从钱包中转移资金的新方法时，这项任务就交给了造成损失的分析师。 然后她来找我，画了一个屏幕进行翻译。 然后，移动开发人员将所有内容都转换为代码并将其夯实到应用程序中。 这是一个不健康的过程，有可能浪费80％的劳动力成本。 您可以在这里省掉很多时间，只需从装配线中省去设计师即可。 如果有现成的界面元素，则可以从中组合翻译窗口。
设计更美好的未来
于是我开始工作。 首先，我想制作一个用户友好的应用程序。 金融服务通常不应长时间占据客户。 在其中，您需要快速导航，选择一项操作，进行一项操作并进一步开展业务。
另一个重要的常数是开发人员友好性。 如果我们有新的筹码，货币或服务，那么战线和动员者就不应受苦并激怒所有风格。 他们只是添加了一个看起来清晰且预期的新功能。
我一直在寻找最简单的类比，并意识到我们需要一个窗口构造函数。 我们有一组控件（后退，前进，帐户选择，输入详细信息）和使用它们的规则（颜色，缩进量，元素大小）。 在设计人员中，分析师和移动工作者可以自己制作新的服务卡和模式窗口，而无需向我“鞠躬”。
重要的是要考虑到该产品正在广泛发展。 今天，我们有3种货币，一年内可能有33种货币。今天，我们提供15种汇款方式，明天则有115种。在应用程序中，可能会出现全新的实体：虚拟卡，股票购买或其他服务。
摒弃束缚的束缚
问题 ：项目中包含越来越多的元素-货币，转移方法等。 许多元素是水平排列的，越多，使用起来就越不方便。
解决方案 ：事先提供扩展，选择方便的元素定位。
先前版本的主要问题是缩放。 因此，我们有一个分辨率为480 * 720像素的条件屏幕。 并且在其水平上有3个带有汇款方法的标签。 好吧，明天他们将是15岁。谁在他们的右脑中将向右滚动15个选项卡？ 还是需要将它们制成微型尺寸，以便仅用小手指就能进入它们？
在ePayments中，客户有一个带有多个货币部分的钱包。 移动UI最具可扩展性的元素是列表。 可以通过完全熟悉的动作将其几乎无限地向下翻转。 即使元素过多，也可以始终固定过滤器或搜索。
便利限制大约为10种货币或转帐方式。 当它们更多时，我们将连接第二个机制，即正在开发的部分。 客户自己选择哪个货币部分对他来说更重要，并用星号标记它们。 或在构造器中构建仪表板，就像Jira中的“开始”屏幕一样。
另外，我在左侧有一个“汉堡”，在底部有一个水龙头栏。 我们在底部面板上进行了最重要的操作。 首先，您将了解部分和卡片的平衡。 然后，您可以转到接待处或转账处，查看交易历史记录或兑换货币。 我放到“汉堡”中的所有次要的东西。 例如，现在存在一个会员程序，该程序访问频率较低。
好的，问题已解决，请转到下一个。
我们保留过去的差异
问题 ：iOS和Android应用程序不同。 他们的设计已经过时，界面有很多额外的元素。 客户很难集中精力，他很快就累了。
解决方案 ：根据准则进行应用程序设计，但具有统一的设计。 清除渐变，提高可用性。
正如我所说，Android和iOS的版本本质上是不同的应用程序。 对客户或我们来说都没有好处。 此外，开发人员在滚动新功能和测试时遇到问题。 因此，我们决定将所有内容统一化。
您不能进行相同的应用程序。 Google具有Material Design，Apple具有人机界面。 但是我们制作的基本元素相似。 网格，大多数控件和块的位置都相同。 负责基本结构的控件是针对操作系统指南量身定制的。 最简单的解决方案是完全移植应用程序。 但这只是向导懒惰和无知的标志。 指南是由比我们聪明许多人的人编写的，值得倾听。
首先，我们在Android上更新了该应用程序。 在“故事点”上它更便宜，我们的大多数客户都使用此操作系统。 此外，在某些时候，我们的移动开发团队不平衡-Android开发团队中的人员更多，我们可以分配其中一些人进行重新设计。 这个版本已经问世，而iOS的版本现在正在逐步赶上它。
它基于“材料设计”指南，因此，我们有了一个应用程序，有条件的小米人对此非常熟悉。 他很快学会了如何将赚到的钱汇到银行卡上。
当我们启动重新设计时，我们开始收集反应和建设性的批评。 首先，那些不喜欢将重新设计视为一种现象的人产生了负面影响。 这是正常现象，不应该害怕。 每个服务都面临着这个问题。 然后，一切都会平静下来，您可以收集有用的信息。
最初，评分下降了一点，然后又回到了4.6。 我们发表了一些批评意见，评论再次变得很好。 从这一刻起，您就可以使用iOS的应用程序了。
现在的应用程序非常相似。 有些事情不是按照准则故意进行的，但主要指标是客户的反应。 一切对用户来说似乎都很方便：评估没有改变，我们感谢对评估的重新设计。
应用程序变得相似的事实反映在开发中。 现在它们更易于测试，Testrail中的情况相同。 所有案例文档都是重复的-自然而然地是经过修改的。 例如，当我们在iOS应用程序中准备功能时，它已经具有来自Android的JSON，并且开发人员无需进入请求。
我们掌管政府
问题 ：开发过程未优化。 每个新的翻译卡都是从头开始绘制和开发的。
解决方案 ：制定一套现成的元素和规则，将流程转变为“设计师”。
设计师的想法随着应用程序的重新设计而出现，但是我们稍后才实现了。 如我所说，该应用程序不应该依赖我。 如果我们引入一项新功能，则任务将从分析师到移动开发人员。 他们从完成的控件中组装一个窗口，检查其样式，边距和其他所有内容-瞧，窗口已经准备好了。 我可以制作图标，但是我的直接参与应该在此处结束。
首先，我分别绘制了每个屏幕。 然后，他对重复元素进行了分组：列表，控件，按钮，插图，确认屏幕等。 准备好应用程序后，我就拥有了完整的组件UI。
看一下元素，每个人都有类似的东西：
•标题
•“后退”
•下拉列表
•用于输入详细信息的行
•“下一个”
我们提前完成这些要素。 另外，我们还会为颜色，缩进和字体准备指南。 在输出中，我们获得了一个构造函数，开发人员在其中将开发人员将有条件的Paint中的图形从分析人员转换为完成的翻译窗口。
自然，移动工作者必须努力将一堆屏幕变成一个整洁的组件系统。 但是后来发生了这些事情：不再需要去Zeplin进行屏幕布局，以后再进行整理和存储。 有组件，有严格的样式表。
总结一下
我喜欢我们所做的。 该应用程序变得越来越漂亮，受到了客户的赞赏。 对于前线和动员者来说，工作变得更加容易。
我们尚未充分利用显示用户行为已发生变化的指标。 因此，现在我们只能根据客户的评分和评论来判断。 评分保持不变-在Google Play上为4.6，在AppStore上为4.8。 大部分负面评论都与验证过程有关，在客户看来似乎很长一段时间。 从正面看，该应用程序经常受到赞扬。
另一个度量标准，仅内部度量标准：我很少使用移动项目打开草图文件。 开发人员正在添加新的方法来在没有我的情况下进行存款和提款。 这意味着组件用户界面正在运行，并且我能够在没有设计者独裁的情况下进行系统的设计。
现在，我们计划将产品展示在不同的平台上，包括台式机版本。 此外，我们计划“挖掘”移动应用程序中功能的整个方案结构，以使客户在操作上花费的时间更少。 好吧，与此同时，我们将放弃左侧的汉堡-这是一种过时的模式，有更多方便的选择。
找工作？
我们正在寻找在圣彼得堡的办公室工作的员工。 如果您对金融科技感兴趣，我们正在等待您。 在下面，您将找到空缺和链接到hh.ru的相应页面。