如何设计复杂信息架构产品.pdfVIP

如何设计复杂信息架构产品 最近忙于一个技术平台类项目，信息架构非常复杂，所以想写一些关于设计复杂信息架构产品的想 法和经验。 我们做产品设计的设计师日常工作粗略分一下，可以分为两类，一类是 ToC 产品，面向消费者的 产品，一类是 ToB 产品，面向企业或者特定用户群体的面商类产品。平常大家讨论比较多的是 ToC 类产品，因为大家都在使用，且设计师很多在从事 ToC 类产品的设计工作。 在知乎、微信、微博等平台，有不少设计师朋友来问我，做 ToB 类产品，信息架构复杂，功能繁多 ，流程很绕，怎么才能设计好呢？正好最近在做一个很复杂很绕的产品设计，这里正好一并总结 回答。 为了方便描述，我这里极端一点，描述 ToC 类产品为信息架构相对简单的产品，例如微信，核心故 事为聊天、朋友圈、支付等，因人而异，每个用户的核心场景不算多。而 ToB 类产品动辄就是上百 个核心故事，各种功能模块繁杂且对用户的亲切性低，使用起来学习成本高，例如银行交易系统、 电信客服系统等。 简单类比一下，信息架构复杂程度的感觉由弱到强是这样的。 设计或者操控以下交通工具： 自行车。 汽车。 飞机。 火箭。 宇宙飞船 …… 现在基本了解了信息架构复杂产品的样子，咱们一起来看一下一些设计这类产品需要注意的点。 1 ，逻辑清晰。 设计复杂信息架构产品，第一要素，就是设计师逻辑要非常清晰。这类产品伴随的海量功能、大量 模块、错综复杂的交互流程、难以理解的业务技术背景，都是对设计师达到逻辑清晰的挑战。 如果极端简化一个 ToC 类产品的任务流程，可能是这样的： 一个机智的用户来使用是这样： 一个不太机智的用户来使用是这样： 然后看一个 ToB 类产品，信息架构复杂的时候，如果设计师没有达到逻辑清晰，那设计出来的任务 流程可能是这样的： 这时， 萌萌的用户会： -_- ”” 默默的用户会：呵呵 …… 凶狠的用户会：设计师你过来我保证不砍你 …… 所以做 ToB 类产品设计，一定不能像写散文一样，随心而至，随时下笔，得像写议论文那样，做足 功课，想清楚重点和逻辑，脑中成图，再动手画稿。 2 ，角色与场景。 虽然ToC 和ToB 设计的特性差异明显，但是基本的设计方法还是通用的。角色与场景设计依然是复 杂信息架构产品设计的法宝。有着 1000 个功能的产品，先分角色，降低每个角色模块需要思考的信 息量和业务逻辑量，然后再根据真实用户的使用情况，来划分场景进行场景设计。把一大块任务有 逻辑地细分到小任务，才有逐步实现的可能。 切记，最好不要仅仅依靠业务功能来划分模块，不然体验设计会乱得一塌糊涂。 角色设计需要对用户群体有清晰的了解和划分，能做到业务使用的共感。 场景设计需要设计师有足够的全局观，不然分开了场景，完成了设计，合不起来，就麻烦了 。 一个复杂信息架构产品，分角色，划场景，可以让设计师对产品目的了解更深刻，全局把握更强， 另外在页面层级上，会把之前需要 10层的功能任务流打薄到 2-3 层，大大提升用户的使用效率和舒 适度。 3 ，学习成本 做产品设计的一个基本要求，就是要保证用户学习成本足够低，低到没有最好。 做ToC 产品这个目 标很明确，也很容易靠拢，而做 ToB 产品很难。 我见过一个中国电信客服的界面，一个 PC 界面密密麻麻上百个功能，业务员完全凭借自己的记忆力 和习惯来进行操作，没有太多的任务流清晰度可言。这样的产品使用，是需要一定时间的学习才能 达到基本使用，学习成本肯定不低。 还有不少 ToB 产品，需要有专门的培训和讲解，才能勉强让新用户开始使用。 这个时候，如果单纯以学习成本低到没有来要求 ToB 类产品，非常难。信息架构复杂起来，是很难 通过认知设计、视觉设计、交互流程简化来解决学习成本高的问题。 有几个点可以帮助到，一是灵活有效的提示（生僻专业术语提示、关键操作提示、报警监控提 示等），二是充足有价值的用户测试，保证不出现设计师以为很好用，用户学到哭的情况，三是深