查看地图导航 分类信息导航( 二 )


二、导航小贴士了解了导航的结构分类和使用场景 , 不妨给大家一些关于导航本身的小技巧 , 作为解决实战中一些问题的原则性参考 。
1. 导航尽量扁平、保持稳定就算要多一次点击稳定性对于B端产品非常重要!由于B端产品对用户使用和学习的成本和门槛较高 , 如果你频繁修改和调整其路径 , 用户很容易因为产品不符合操作习惯和心智模型而对产品滋生负面情绪 。对于产品本身来说 , 需要尽可能避免这样的伤害 。
2. 最好便于拓展从稳定性方面来说 , 我们需要保证导航的变化不会因为产品的变化而有很大的变化 。
举个很简单的例子 , 当我们产品的功能增加 , 尤其是二级导航的项目增加 , 原来横向布局的导航不得不改成纵向布局的导航 , 这叫因产品变化而产生的巨大变化 。所以在选择导航布局的时候 , 要为以后的拓展打好基础 。
3. 清晰可见 , 操作易懂这是从外观和交互的共同层面来看的 。导航的尺寸必须足够大 , 位置必须足够清晰 , 让用户能够在视觉反馈的层面上保证对用户的友好 。
其次 , 相对于内容区 , 所有的交互区都需要一个积极的响应 , 可以称之为界面的热情 。这也是一个优秀界面的自我修养 。
4. 导航项可以重复一个页面允许两个主导航 , 同一界面允许两个相同的导航项目 。并不是说一个条目在导航中只能出现一次 , 也没那么死板 。
5. 不要让用户有惊喜这对于To B的设计非常重要 , 不同于To C的产品 , B端产品的一个重点就是满足用户的预期 , 所以一定要避免“这个设计就是为了好玩”的想法 。
6. 导航的反馈需要保持一致隐喻可以在所有界面布局、所有组件、所有控件和所有模式中找到 。例如 , 单词链和带有“跳转”的单词链代表不同的隐喻 , 因此我们需要赋予它们不同的外观和交互响应 , 以向用户提供反馈 。
7. 导航不一定是有层级关系的回到导航最初的定义 , 它的本质是将信息分类 , 让用户快速完成任务 , 这也是导航的工作 。
很多时候 , 我们不必拘泥于这个项目应该严格存在于哪个层次的想法 , 而是如何根据用户的需求 , 合理地将这个项目划分到最合适的集合中 。
8. 按权重布局的三种导航样式这是一个基于外观的点 。根据大量的案例研究和眼动测试 , 市面上最常见的导航按照信息权重布局可以分为:横向、纵向和垂直 。由于不讨论这部分 , 我们在上图中直接梳理了各种布局的特点、优缺点和应用场景 。
三、六步导航设计法知道了上面的分类和注意事项 , 下面我们就用一个具体的案例来深入体会一下导航的交互设计(因为这个内容很精彩 , 涉及到保密 , 所以这里就不具体展示了 , 用示意图的方式来描述) 。一共六个步骤 , 看看这是不是也是你工作场景中的一个头疼的问题 。
1. 搞清楚每一个导航项的定义有必要搞清楚导航项的定义 , 因为导航项的定义决定了你的目标界面是什么 。所谓目标界面 , 就是导航带你去哪个分类信息的地方 。
那么我们先来梳理一下导航中各个导航项的接口定义 , 这也是我们日常工作中整理导航非常重要的一步 。
问题一列 , 我们自然会有各种各样的疑问 。例如 , 导航分类之间存在一些现有的流程关系 , 但有些分类不属于该流程 。为什么?
比如有些导航类别和导航项目名称相同 , 但内容不同 。这是为什么呢?(想想这是不是我们工作中经常遇到的问题)?这些都是我们后期需要优化的地方 。
2. 搞明白用户的使用路径保留以上问题 , 我们来做第二步 。在这一步 , 我们需要搞清楚用户的使用路径 , 因为这样才能对任务产品进行一级分类 。
通过基于不同角色的用户体验图 , 可以得到不同的用户操作路径 , 因此可以顺利得到这套操作流程的大框架 。
基于业务中的任务链接 , 推导出每一步的操作路径 , 这样我们就可以将用户的操作路径细化为一级导航 。
3. 区分一下权限我拿到了一级导航 , 需要角色的权限进行区分 , 这也是B端产品的本质属性 。


推荐阅读