统一的文档规范和设计规范，可以降低合作伙伴的学习成本，即使产品、需求、设计者不同，也可以给前台、后台、底层、QA带来一致的文档体验。
虽然交互设计师的工作不仅仅是画交互稿，但是一份好的交互稿不仅能完美的阐述产品内容和设计师的设计思路，还能在项目中起到协调各方的重要作用。保证展示产品需求和设计思路的完整交互稿，让各方工作人员有相同的工作目标，体验好的交互稿也能方便各方理解，提高后期开发中设计的还原度，提高各方工作效率。
对于一个设计团队来说，统一的文档规范和设计规范不仅可以降低合作伙伴的学习成本，还可以提升设计师和设计部门的影响力。即使产品、需求、设计者不同，也能给前台、后台、底层、QA带来一致的文档体验。也许每个设计团队都有自己的内部交互文档规范，不同类型或级别的产品部门可能有不同的交互设计文档的卷数和组织方式。我们设计部是刚满一岁的宝宝，部门的设计师都是设计行业的大一新生。但在这一年中，我们不断积累和学习，完善设计文档经验，在集团内部构建设计文档规范。下面就来分享一下，互相学习。
一、结构化文章-交互式文档目录
对于大型产品或中小型产品，文档目录需要有清晰的页面结构。无论以何种形式呈现，整体交互项目都应尽量包含清晰的修改记录、交互规范、整体设计说明、业务设计等。
1。易于查找的信息修改记录
明确迭代的上线日期:前后台，QA人员可以对产品迭代有一个持续的了解，知道一次迭代要做什么；
业务需求及对应设计师:方便合作者分工，随时可以找到交互设计师；
内容修改和前端开发人员:明确说明某个需求修改了哪些页面或者增加了哪些页面，让合作者了解设计的细节。指定前端开发人员，有助于你和QA找出对应功能点的前端开发人员是谁(我可能在一次迭代中对接了好几个前端开发人员，但记不清哪些需求是谁实现的，好蠢~)。
2。全局页面描述和全局交互
全局页面描述主要包括Z轴内容层次结构、X轴和Y轴适配方案、整体跳转逻辑等。，这些都需要在产品开发的前期就让前端和可视化的同事知道。准确传达他们的整体产品设计思路，以便他们建立框架或可视化定义。此外，还可以指导后期复杂需求的交互设计。
全局交互是为了组件设计，既保证了产品设计的一致性，又提高了可视化和开发效率。
3。总体计划
全局方案不仅包括404/403方案、全局请求异常、空状态、页面/信息流加载方案等。，还包括一些全局业务方案，如基于平台的欠费止付服务流程(所有产品模块都需要)。
二。布局章节-交互式文档布局
1。单页文档设计
我们组基本上是做网页端的设计。由于每个页面内容丰富，交互逻辑复杂，逐渐形成了每个文档页面只设计一个页面的规则，保证了设计文档中的页面与真实产品中的页面一一对应，便于交互文档按照产品业务进行组织，减少了协作者查找内容的时间。
其实单页设计类似于一页只讲一件事的设计方法。在表达这个页面的设计内容时，需要明确与其他页面关联的每个用户接触点来自哪里，以保证开发者和QA在阅读交互描述时，能够理解当前页面内容与其他内容的关系。
2。统一的页面内容布局
作为一个交互文档，它的目标用户主要是前端开发人员、QA人员以及与我们合作的可视化伙伴。其实我们很容易就知道，几乎90%都在用公司配置的显示器。公司配置的显示器基本尺寸为1920*1080，所以我们可以根据显示器尺寸来定义网页的大小和互动讲解显示区域，以保证相关内容尽可能的显示在第一屏。
此外，根据开发者的理解，他们更习惯于在Y轴方向浏览信息(其实大部分人都喜欢在Y轴方向浏览信息)，所以文档页面和交互描述的布局以垂直为主，在一个方向浏览时可以看到所有的交互点。
页眉主要包括页面名称、设计者信息和时间信息；
主页面可以在Y轴方向延伸，X轴方向尽量不要延伸，但不排除有特殊的业务需求需要在X轴方向延伸(比如在运营平台中有强烈的需要在表格中横向显示十几条信息)；
交互的描述主要包括交互点数和交互逻辑。
三。颜色和字体
1。尝试使用灰度颜色
很多交互设计师在做交互稿的时候都是很认真的。他们会尽力做出高保真的设计，包括蓝色或绿色的按钮，橙色的警告图标等。有时候，他们会直接使用视觉设计定义的视觉色彩规范来制作交互稿，呈现一个完美的交互稿。说实话，这真的是一个很漂亮的交互稿，几乎不需要视觉设计师做任何修改。如此完美的交互稿，无形中给视觉设计师、开发者、QA人员造成了困扰。
关于这个问题，我和对接视觉设计师有过深入的交流。对于视觉设计师来说，交互稿中出现的色彩其实会对他们的视觉设计造成一定的干扰，而表示不同明度的灰色调其实是他们能够理解交互设计师想要表达的东西。此外，互动稿中的色彩内容也会成为视觉焦点。我与开发人员和QA沟通过，他们说这将无形中干扰他们对交互逻辑和细节的关注。
关于这个问题，我们总结了一些灰度颜色的使用范围。基本上说明度数低于#333的灰色尽量不要用。大面积背景基于尽量不使用亮度地狱#999的灰色等一些原则，也可以让交互看起来干净整洁，有一定的美感。
2。统一字体大小和字体
其实对字体没有什么特别的要求，只要字体统一就行。我们组统一使用微软雅荷。选择这种字体纯粹是因为它是无衬线的，看起来很简单。而且微软雅荷是浏览器适配系统字体时常见的默认字体。
对于字体大小，有一些要求。比如普通页面文档就不应该使用小于12px的字号，一般的字号是14px。强调可以通过放大字体和加粗来解决。字体有正常页面文档中唯一可以使用的颜色，即警告色#ff6666(尽量使用饱和度较低的颜色)。
四。内容
关于见面和展示我说了很多，内容主要是互动页面和互动讲解。这是一件复杂的事情。针对不同类型的业务需求做出不同的页面设计，我简单说几个需要注意的细节。
1。不同类型的需求应该有不同的方式来呈现设计
众所周知，产品需求大致可以分为两类:基于任务的需求和基于信息的需求。根据不同类型的需求，我们应该能够通过一些基本的设计方法来呈现我们的设计。
例如，对于基于任务的需求，我们可以提供必要的流程图来帮助开发人员和QA更好地了解用户在完成任务的过程中可能会去哪里，并帮助他们进行R&D设计和测试设计。对于基于信息的需求，提供信息结构图和业务结构图，以便他们更好地理解宏观层面的需求。
2。交互式说明应该易于阅读和查找
交互描述尽量用稍微大一点的字体。我们使用的交互描述的字体大小是16px，比一般字体大2px。一方面可以区分交互描述的文案内容和页面内容，另一方面也便于开发者和QA阅读。
在表面上组织内容和交互式解释的方法有很多，如画连接线、编号和标记等。目前我们集团的业务需求还是比较复杂的。考虑到不希望页面变成类似织网的东西，我们采用了实用编号的方式来组织互动讲解。如果互动讲解中有内容不同的点需要重新书写，则编号采用N-N的形式，每个互动内容在互动时钟处以中间破折号开头。如果互动内容有什么分级，可以用无序编号等等，等等。
如果在交互描述中有与其他页面的关联，突出显示出来，以便开发者和QA在阅读时快速定位跳转或d回的页面，明确这个页面与产品其他部分的关系。
3。交互式解释应该符合逻辑
或许逻辑性是每个设计师的必备属性。无论我们使用MECE还是逻辑树分析，它使我们能够遍历或枚举我们想要编写的交互点的各种情况。我在这里想说的是要真正符合逻辑。虽然我接触过的一些设计师可以对一些用户接触点进行详细的解释和说明，但他们往往说一套做一套，导致交互说明冗杂，难以阅读。真正的逻辑是能够知道每个用户接触点你想要讲解的场景和处理方式，尽量减少每个用户接触点的交叉讲解，保证交互讲解思路清晰详细。为此我也总结了一个简单的方法，就是PTC4。这里简单说明一下，以后再介绍这个方法。
4。交互过程应该被封装
封装的概念其实来源于研发中代码封装的概念，它说的是如果一个方法被封装了，那么在使用这个方法的时候，你只需要传入不同的参数就可以得到想要的结果。在这里，我引用流程的封装。全球需求流程可能会有所不同。通过定义变量参数，您可以在不同的模块中调用这个逻辑。这很符合开发者设计代码的主要思路，所以和开发者解释起来非常流畅，而且可以减少重复设计。
文/李微信微信官方账号:网易
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）