商务文件一般都是用电子邮箱传递还是微信传递的多？

对于这个问题，我觉得这个就是要看个人的情况，因为现在这个微信就是大家经常用的。所以，有的也在用微信传，但是用邮箱的也是存在，所以。这个就是看自己方便，怎么用都可以。

随着微信的出现，很多人从QQ转移了阵地。对于现在的人来说，微信似乎是比QQ更常用的软件。同事们想建个群都在微信上；日常生活中想发个动态会选择发在朋友圈而不是QQ空间。再加上微信公众号的兴起，越来越多的人再也没打开QQ了，但也有人仍然没放弃QQ。

第一，QQ在零几年的时候就很流行了，当时很多人都觉得QQ等级能有一个太阳是一件很酷的事。那时候很多人会在空间里发说说、日志，记录下自己当时的心情和生活。虽然日后看起来会觉得二，但也是青春的印记。

QQ还有很多有意思的设置，比如QQ农场，当时很多人守着时间准备偷菜；比如QQ宠物，每次上线它都会跳出来等待投喂；比如空间装饰，QQ秀，很多人会充红钻、黄钻把自己的QQ装饰得漂漂亮亮，虽然现在多数人已经不再这么做了，但看着自己曾经花费过很多心思的QQ还是舍不得丢弃。

第二，微信作为一款主打聊天沟通的APP，在功能上存在很多不足。就拿微信群来说。如果你想跟微信群里的一个人私聊，那么你只能先加好友。可多数情况下你跟这个人聊完之后就不会再联系了，时间长了，好友列表里没用的人就越来越多。而QQ群则方便得多，你想私聊不用先加好友。而且当微信群人数超过100人的时候，你想再加群必需先加群里的人，让他拉你进去，对比QQ群，直接搜群号就可以了，方便得多。微信群还有一个缺点是，不能换群头像。微信默认的群头像就是几个人的头像拼图，看着实在是不美观。

除了群的设计有缺陷，微信聊天功能也有不足之处。微信的聊天记录不能保存，万一你手残删了对话框，以前的聊天记录就找不回来了。而QQ则没有这样的问题，即使你删了对话，聊天记录也还是能找回来的。而且QQ的消息不想看的话只需左滑删除，而微信的话还需要长按删除。

除了上述的两个问题，微信还有一些琐碎的小问题。比如说微信的传文件功能极其不好用，同时它也存在着一旦删了对话框，文件就不复存在的问题。而QQ有群文件的设计，想找哪个文件非常方便。现在我们聊天都喜欢用表情包。如果你在QQ上看到一个有意思的表情包，你可以长按保存到手机上。但是换成微信你只能收藏。所以，这个就是原因。

开发微信小程序需要用到以下技术：

1、wxml，小程序常用语言为wxml，wxml是微信但是你熟悉wxml之后会发现其实它的编程理念和HTML的网页编程比较类似。

2、wxss，wxss更趋向于CSS,wxss，其实主要的实现思想理念也和网页的开发技术差别不大，主要是一些标签的一些简单替换，大部分和原先的css、基本不误，都是通过同页面调用的方式实现的。

3、js，开发小程序还必须掌握js技术，如果html+css+js的基础打的好，再来学习一下微信小程序js，之后在前端开发上就没有什么问题了。

4、服务器语言，如果不是专业的后端开发者，可能后端有一定的难度其学习曲线较陡。但是，仍然建议开发者学习一下后端语言，至少需要了解大致的原因框架，能够看懂其代码逻辑，这样不仅可以很好地实现前后端的配合，也能够在小程序出现bug的时候使用。常见的有PHP、Java、Python、ASP等技术。

5、数据库语言，如果公司数据量不大，架构不复杂的话数据库语言相对来说是比较简单的，一般学会一些常用的命令以及常出现的问题就能够应付使用。常用的数据库有免费的MySQL、msSQL、MongoDB、Oracle等数据库。

有许多厂商在微信小程序聊天搭建方面提供了优秀的解决方案，以下是一些在该领域表现良好的厂商：

腾讯：作为微信的开发者和运营商，腾讯提供了丰富的开发工具和文档，可以帮助开发者构建功能强大的微信小程序聊天功能。腾讯云也提供了强大的云服务支持，包括即时通讯服务和人工智能相关的能力。

百度：百度同样提供了完善的开发工具和文档，帮助开发者实现微信小程序的聊天功能。他们的开发者平台提供了丰富的接口和 SDK，以及人工智能相关的能力，例如语音识别和自然语言处理。

阿里巴巴：阿里巴巴也在微信小程序聊天搭建方面提供了许多解决方案。他们的开发者平台和云服务平台提供了丰富的工具和资源，用于构建和扩展微信小程序的聊天功能。

字节跳动：作为一家领先的科技公司，字节跳动在微信小程序聊天搭建方面也有一定的实力。他们的开发者平台和技术支持团队可以帮助开发者实现丰富的聊天功能和创新的用户体验。

云南亿倍网络科技有限责任公司，专注品牌数字化建设和智慧系统开发领域，提供智能型网站、小程序、数字名片、APP和数字化管理系统建设等服务。旗下SaaS智能建站系统，可对接百度、微信、抖音头条和支付宝小程序，支持电商供应链、在线支付、物流快递、同城配送、门店自提和硬件设备对接，针对订单处理可对接公众号、APP、短信和邮箱等消息提醒，系统可增加不同类型的管理员，设置订单分配自动下发各个管理员协同处理。平台提供网站建设教程、小程序制作流程和搭建公司网站步骤等操作指导，7x24小时专职售后服务，为广大创业者、商家和企业保驾护航。

这些厂商在微信小程序聊天搭建方面都有一定的经验和技术实力，但具体选择哪家厂商要根据您的具体需求、预算和团队技术能力来决定。建议您在选择之前进行充分的市场调研，了解各个厂商的产品和服务，以及他们在行业中的口碑和客户评价。

微信轻应用是时下的一个香饽饽。一方面是因为随着H5语言的定稿及其开发经验的沉淀，开发者以较低的成本即可打造出具有一定可用性的Web App。另一方面，微信作为一个超级社交App，天然具有巨大的流量入口价值与传播分享价值。因此，在微信平台宣布全面开放接口后，无数互联网创业团队、企业，甚至是个人，纷涌而入，杀成一片红海。

但是，实际使用时，微信轻应用的体验并不是那么的“爽”。诚然，这与H5语言的技术局限性有着很大的关系。但抛开这一点，走肾而不走心的设计也是造就“不爽”体验的重要原因。本人在体验过一些的微信轻应用后，尝试总结出了一些对微信轻应用交互设计的思考。

在亮出个人总结之前，我想先谈谈进行微信轻应用设计时的难点与机会。

微信轻应用设计的难点源于H5技术的局限性以及微信平台本身的局限性。

1 H5的局限性：

2 微信的局限性：

但很多时候，限制即是机会。 “聊天气泡+底部操作栏”的设计规范，反而为应用的信息框架与导航设计提供了更多的思路。一方面，IM工具的输入/反馈机制，为用户与应用的交互方式和信息的呈现方式带来了新的可能；另一方面，底部菜单栏可以是对Native App中Tab Bar选项的隐喻，恰当使用可以降低用户学习成本。

废话了一大箩筐，下面马上向个人总结页面跳转。

用户的认知模式是长这样子的： 会倾向于把公众号的对话窗口视为微信轻应用的首页。底部菜单栏中，每一个标签即是一个功能模块的入口（相当于Native App中的Tab Bar）。点击标签后进入的第一个页面即是该功能模块的顶层页面，从该页面返回则必然是回到对话窗口。

这带来的启示之一是，在设计页面架构时， 可以考虑将对话窗口中的底部菜单栏视为Native App中Tab栏的隐喻， 将功能模块平摊到这些操作栏中，并削弱模块之间的关联性。如微信轻应用“Yolo优洛会”中，每个底部操作栏标签均对应一个功能模块，且功能模块之间彼此独立，点击进入后可获得独立、完整的沉浸式体验，让用户专注于任务本身，并降低了学习成本。

启示之二是， 对话窗口与功能模块的顶层页面之间必须建立唯一的上下层级关系。 一个反例就是，“行动流”微信轻应用中，点击对话窗口底部操作栏中的“圈子”，进入新页面后，再点击左上的“圈子”按钮，试图返回，却发现跳转至了一个全新的页面。该页面顶部是Icon和Slogan，下面是“我”、“圈子”、“梦想”这三个功能的快捷入口，正是设计师眼中的“首页”。然而，该页面的到达路径并不符合预期，容易把用户灌醉。

微信已经强制为所有应用套上了顶部导航栏枷锁，其中就已经包含了“返回”按钮。然而，仍然还有不少应用坚持添加上自己亲手设计的“返回”按钮。

双重“返回”样式增加了认知障碍、挤占了屏幕空间。就算是出于“左上返回按钮位于拇指热区外我们来让它更容易被点到吧”的出发点来考虑，其存在意义也仍然十分牵强。相反，将其移除后，腾出来的空间可以激发更丰富的设计思路(比如，用来放置全局导航)。

即使是在高配置、强网络的条件下，页面跳转在微信轻应用中仍然是非常痛苦的体验。而灵活高效的导航是减少页面跳转的一大杀器。

微信轻应用上，常见的导航样式如下：

1 对话窗导航

2 一级导航

3全局导航

4场景式导航

H5的技术限制，使得一些在Native App上司空见惯的动效套用在微信轻应用上时显得笨拙无比。当然开发水平是影响动效是否流畅的一个决定性因素。但过重的动效需要占用大量的用户资源，同时也加大了开发的成本与难度，违背了“快速开发”的初衷。因此，在进行微信轻应用的设计时，要尽可能地避免“使用动效解决问题”的思路。

但这并不意味着要舍弃一切动效。事实上，比起Native App，微信轻应用对“微交互动效”更加依赖。主要表现在以下几个方面：

1 Loading态

微信轻应用需要源源不断地发送网络请求，也就留给了用户大量用于等待的焦虑时间。而Loading态的微交互的使命正是化解这股焦虑。

Lodaing态的对应加载方式是全局加载，这种方式比较适用于数据请求量不大的页面加载场景。而数据量较大的页面则普遍使用异步加载的加载方式。异步加载即各项元素按照一定的优先级顺序来进行加载，因此在加载过程中会出现各种空元素。这时候就需要缺省态的微交互上场了。

由于H5的效能问题，在“用户进行操作”与“系统执行操作”之间往往会存在一小段延迟。在这段延迟期间，若没有任何反馈，用户很容易会误以为自己操作失败而做出什么不好的事来。操作反馈的微交互可以间接加快应用的响应速度，阻止用户犯错误。

正在输入的文本框必须要在视线焦点范围内。这点听起来似乎是天经地义。但很不幸的是，这个世界上存在着太多的无情无义的微信轻应用了。

“如何让用户觉得运行速度很快”是进行微信轻应用设计面临的一个核心问题，而页面加载的速度正是衡量“运行得快不快”的一个重要尺度。

用户是如何感知、判断页面加载的速度的？这主要取决于第一个可视元素出现所用时间和“感觉这个页面已经完整了”时所用时间。将这些用户视角的体验需求转化为指导设计的方法论则是， 减少页面中可感知到的信息的数据加载量。 这些可感知到的信息必然是重要的、高展示价值的。至于其他 次级信息 ，可 选择性地将其隐藏，并降低其加载优先级。 这样，即使次级信息仍在加载中，但由于其已被隐藏，用户感知不到，因此仍会认为当前页面的加载速度是nice的。

隐藏信息的方式总结有以下几种：

1 将一段长信息不完整展示

由于技术限制，现阶段大部分微信轻应用从详情页面返回至列表页面时，并不能定位到最后停留的列表位置上。

突破该技术瓶颈固然是最有效的解决方法。但据观察，目前只有微信钱包中自带的“京东”轻应用解决了该问题。因此可以基本断定该解决思路暂时无法实现。

面对如此艰苦的设计背景环境，另一个解决思路是 提高列表筛选效率，降低用户从详情页返回列表页的概率。 比如，往列表中注入更多的辅助用户决择的信息字段；又或者是将详情页中的关键入口前置，缩短用户到达路径。

在微信钱包中自带的“大众点评”轻应用中，店铺列表页处囊过了该店铺的团购入口，一来团购信息可以辅助用户进行店铺筛选，二来缩短了购买团购的路径，极大地提高了列表的筛选效率。

设计师或许掌握了成吨的让跳转页面无感化的技巧，但一切真相都逃不过“返回”按钮的审判之眼。按照微信的逻辑， 每一次点击“返回”的结果，必然是回到上一次加载的页面。 这使得一些在正向操作时感觉高效简洁的设计方案在逆向操作时让人疼到无比。

比如微信钱包中自带的“美丽说”轻应用中，使用Segmented Control控件承载化妆品分类。切换类别时，体验近乎无感。然而，当点击“返回”按钮时，并不是回到微信钱包首页，而是回到上一个化妆品类别的列表视图，严重不符合用户预期（明明就是同一个页面，怎么点了返回没反应的）。

正因为如此， 在技术上无法解决该问题的前提下，并不十分建议使用那些容易引发“不需要进行跳转”的错觉的导航样式 ，比如Tab式导航。不仅在正向路径中违背了“肯定不需要跳转啊”的用户预期，也在逆向路径中也显得臃肿低效。

用户正在使用微信轻应用，手机突然震动了一下。这时候用户是会选择将当前任务进行到底，还是会离开应用查看微信信息呢？这取决于用户使用应用的目标强度以及获取新信息的迫切程度。但无论如何，用户一旦离开了应用，如果想要再次回到最后停留的页面，就必需从头开始。

无论是对用户还是开发商而言，这种交互逻辑都不是什么好东西。那么， 能否在浅层级的页面中提供返回最后停留页面的入口呢？ 比如，在轻应用的页面中提供“稍后阅读”按钮，点击之后，公众号可以将该页面的链接以信息流的形式推送给用户。这样，用户只需要重新进入公众号对话窗口，直接点击信息中的链接即可以重返最后停留的页面了。

当然，这只是个人YY，是否具有可实现性仍需要技术同学的审批。

由于个人知识体系实在浅薄，关于微信轻应用设计的思考暂时就只有这么多了。在此真心希望H5的开发技术快高长大，让微信轻应用与原生应用之间的体验差距越来越小。

如果对楼主有帮助，给个采纳好不，谢谢

我们做产品设计的设计师日常工作粗略分一下，可以分为两类，一类是ToC产品，面向消费者的产品，一类是ToB产品，面向企业或者特定用户群体的面商类产品。平常大家讨论比较多的是ToC类产品，因为大家都在使用，且设计师很多在从事ToC类产品的设计工作。

在知乎、微信、微博等平台，有不少设计师朋友来问我，做ToB类产品，信息架构复杂，功能繁多，流程很绕，怎么才能设计好呢？正好最近在做一个很复杂很绕的产品设计，这里正好一并总结回答。

为了方便描述，我这里极端一点，描述ToC类产品为信息架构相对简单的产品，例如微信，核心故事为聊天、朋友圈、支付等，因人而异，每个用户的核心场景不算多。而ToB类产品动辄就是上百个核心故事，各种功能模块繁杂且对用户的亲切性低，使用起来学习成本高，例如银行交易系统、电信客服系统等。

简单类比一下，信息架构复杂程度的感觉由弱到强是这样的。

设计或者操控以下交通工具：

自行车。

汽车。

飞机。

火箭。

宇宙飞船……

现在基本了解了信息架构复杂产品的样子，咱们一起来看一下一些设计这类产品需要注意的点。

一、逻辑清晰

设计复杂信息架构产品，第一要素，就是设计师逻辑要非常清晰。这类产品伴随的海量功能、大量模块、错综复杂的交互流程、难以理解的业务技术背景，都是对设计师达到逻辑清晰的挑战。

如果极端简化一个ToC类产品的任务流程，可能是这样的：

一个机智的用户来使用是这样：

一个不太机智的用户来使用是这样：

然后看一个ToB类产品，信息架构复杂的时候，如果设计师没有达到逻辑清晰，那设计出来的任务流程可能是这样的：

这时，

萌萌的用户会：-_-””

默默的用户会：呵呵……

凶狠的用户会：设计师你过来我保证不砍你……

所以做ToB类产品设计，一定不能像写散文一样，随心而至，随时下笔，得像写议论文那样，做足功课，想清楚重点和逻辑，脑中成图，再动手画稿。

二、角色与场景

虽然ToC和ToB设计的特性差异明显，但是基本的设计方法还是通用的。角色与场景设计依然是复杂信息架构产品设计的法宝。有着1000个功能的产品，先分角色，降低每个角色模块需要思考的信息量和业务逻辑量，然后再根据真实用户的使用情况，来划分场景进行场景设计。把一大块任务有逻辑地细分到小任务，才有逐步实现的可能。

切记，最好不要仅仅依靠业务功能来划分模块，不然体验设计会乱得一塌糊涂。

角色设计需要对用户群体有清晰的了解和划分，能做到业务使用的共感。

场景设计需要设计师有足够的全局观，不然分开了场景，完成了设计，合不起来，就麻烦了。

一个复杂信息架构产品，分角色，划场景，可以让设计师对产品目的了解更深刻，全局把握更强，另外在页面层级上，会把之前需要10层的功能任务流打薄到2-3层，大大提升用户的使用效率和舒适度。

三、学习成本

做产品设计的一个基本要求，就是要保证用户学习成本足够低，低到没有最好。做ToC产品这个目标很明确，也很容易靠拢，而做ToB产品很难。

我见过一个中国电信客服的界面，一个PC界面密密麻麻上百个功能，业务员完全凭借自己的记忆力和习惯来进行操作，没有太多的任务流清晰度可言。这样的产品使用，是需要一定时间的学习才能达到基本使用，学习成本肯定不低。

还有不少ToB产品，需要有专门的培训和讲解，才能勉强让新用户开始使用。

这个时候，如果单纯以学习成本低到没有来要求ToB类产品，非常难。信息架构复杂起来，是很难通过认知设计、视觉设计、交互流程简化来解决学习成本高的问题。

有几个点可以帮助到，一是灵活有效的提示（生僻专业术语提示、关键操作提示、报警监控提示等），二是充足有价值的用户测试，保证不出现设计师以为很好用，用户学到哭的情况，三是深刻理解业务，设计师的业务理解水平接近架构师和产品经理的水平，才能从体验侧做一定范围的有效改动，来帮助产品的可用性得到提升。

设计复杂信息架构产品时，想做到学习成本低到没有，这时的设计方法应该是，虽不能至，心向往之。

四、业务理解度

做复杂信息架构产品，最难的就是业务理解入门。例如做微信、QQ音乐等产品，设计师相对好入手，因为设计师本身也是用户群体。而复杂信息架构产品一般不是给普通用户使用的，是给一个特定群体的用户使用的，大部分情况，设计师与这个特定群体是没有交集的。

例如设计师接到一个任务，做银行交易系统，首先，设计师没有在银行工作过，对银行交易流程基本不了解，第二，设计师完全不知道使用这个交易系统的用户的心理模型、工作状态、用户场景、喜怒哀乐。如果这个银行交易系统是给尼日利亚的某个银行做的，可能设计师连当面和用户交流的机会都没有。

所以做这类产品时，动工前，设计师大部分时候业务理解度无限趋近于0……

最好的方式，我是建议设计师能自己跑去真实使用场景做做自己的用户访谈，例如到用户群体做一天的跟踪访谈、用户深访、任务流程记录、用户痛点记录等，这些真实的感受和体验带来的价值远远大于架构师或者产品经理给设计师描述带来的价值。

自我经验的比较也是一个好方法。没有设计师能站出来说，我做过任何类型的产品设计，但是优秀的设计师可以找到一些让以前自己成功的设计经验适用到现有产品的方法。

做一个云平台的服务购买场景，虽然设计师可能没有接触过云平台，但是能否类比到去京东淘宝买零食的流程，来看看有没有共性可以利用。其实是有的，因为人性是相通的。

五、拉通

做复杂信息架构产品，最难的一点是拉通。

做一个ToC类产品，可能一个设计讨论会，来4-5位产品与开发的同事就能启动讨论，且很快会有结论和执行项。做一个复杂信息架构的ToB类产品，一个模块拉通会轻轻松松就是来30多人，一个讨论就能引发2个小时的混战。

这个时候对设计师的全局观和项目把控能力的要求是非常高的。不然就会出现一个情况，拉30多人讨论10个设计点，讨论到第2个设计点的时候，大家争起来了，很快就争论到商业、业务、技术、平台等非设计的论题，吵了3个小时然后大家都崩溃了就散会了。这个时候设计师才想起来，还有9个设计点没有讨论……

拉通需要设计师有掌握全场讨论的能力，控制时间，控制争论方向，避免没有结果的讨论，主动提出并控制设计的执行项。

六、做减法

有很多ToC类的设计黄金准则，在ToB类设计不一定适用。例如做减法。一个页面，产品经理提出了20个功能，设计师说，简洁！减法！砍成3个！产品经理说，不行，10个！设计师说，好了，5个，赶紧的我还要出图呢。这个减法讨论就结束了。（当然，简单信息架构产品做减法也是需要技巧和思考的）

而ToB类产品，一个模块100个功能可能来自20个不同的业务需求群体，这个时候砍任何功能，都会造成整个大功能模块闭环的缺失。所以单纯的砍功能做减法不一定在ToB类产品设计上适用。

七、设计师的成就感

很多设计师在网上给我抱怨，说做的产品是ToB的，密密麻麻的功能、表格、筛选、流程图，一点美感都没有，不像做一个音乐、聊天、工具的ToC产品那么有成就感。

的确，做一款好的ToC产品，首先，样子足够好看（能放弃一些次级功能追求简洁和美观），第二，大众使用，App Store有人夸，家人朋友可以点赞。

做ToB产品，先不说好不好看，一般来说ToB产品的交互价值远远大于视觉暂时，而且主要是没人夸。设计师花半年给南美一个运营商做一个大数据分析系统，做的再好，南美那边也不会有用户跑来赞你啊，要是真有一天有个用户高兴的不行，给你打一个电话，你也听不懂啊…… 哈哈哈

我觉得换一个角度来想。

找到乐趣。

做什么设计都是有乐趣的。做ToC产品，把一个首页做的漂亮精致，肯定是有成就感的。做ToB产品，把一个需要10步的流程通过打散、整合、聚集等方式减少到3步，也是一种乐趣。

设计复杂信息架构的时候，设计师千万不要放弃自己对专业的美好理想，让自己完全受制于业务和技术来出稿，而是时刻记得自己的专业能否帮助整个系统得到提升，这样的乐趣和成就感也是很大的。

什么是产品的信息架构

信息架构是对信息进行结构、组织方式以及归类的设计，好让使用者与用户容易使用与理解的一项艺术和科学。好，说人话，信息架构就是让用户更容易理解你的产品是怎样的，让他们在使用你产品的时候可以更顺利，更自然。

信息架构的作用

1、传达产品定位

一个好的信息架构，可以让用户第一眼就知道这个产品做什么事，今日头条的信息架构让你一眼就知道是新闻阅读类app，微信信息架构看后就知道是社交类app，淘宝的信息架构让你一眼就知道是电商类app，好的信息架构让用户第一眼就知道我能用这个app做什么，这个app能满足我什么需求。

2、在需要的时候更快的找到某个功能

好的信息架构可以让用户在需要的时候更快的找到某个功能，就像上面的商场，如果没有楼层简介，可能用户得在里面找半天，有了楼层简介，用户只需要直奔相应的楼层就好。

一个好的信息架构不仅让用户一眼就知道产品如何使用，当他下次进入的时候，更能很快的找到产品的使用路径，一个相对混乱的信息架构，会让用户不知道这个产品到底从何开始，不知道如何使用这个产品。

一个好的信息架构不仅可以提升用户体验，更能提高产品的留存率。

信息架构设计的准则

“分、排、删、藏”，“分”即按照功能的属性，将有相似属性的功能归到一类，“排”即按照功能的优先级将其排序，“删”即删掉非必要的功能；藏”即隐藏次级需求，强化核心功能（二八法则）。

设计信息架构在照顾到用户的使用习惯和心理认知的时候，也要考虑商业价值。比如微信朋友圈这么重要的功能微信为什么没有拎出来，试想如果朋友圈单独拎出来，那么用户就不需要去“发现”模块点击了，隐藏在发现里面的扫一扫、附近的人、小程序等功能也就无法更多的曝光，自然也就无法产生更多的商业价值。

如何进行信息架构设计

张小龙在分享他的产品观的时候，说过，设计就是分类。分类为了更好的传达信息，需要对信息进行选择和组织，所以信息架构设计说到底就是在做分类。分类分为两种，一种是自下而上，一种是自上而下。

1、从下到上

把所有需要呈现的内容罗列出来，然后按照一定的类别进行分类

常用的信息分类方法有：精确分类和模糊分类

精确分类：按拼音首字母、按时间顺序、按地理位置

模糊分类：按任务、按比喻、按主题、按用户

word的工具栏就是按照任务来划分。

电脑桌面的回收站、文件夹、防火墙等就是按照比喻来进行分类。

爱奇艺将内容划分为电视剧、**、儿童、动漫，这就是按照主题来进行分类。

产品经理可以把功能点都写在卡片上，然后找一些目标用户来进行分类，并反馈相关标准作为我们产品经理去梳理信息架构的参考。实际工作中，也需要产品经理自身对信息有一定的梳理、筛选、分类的能力，然后通过用户测试去检验分类的有效性。

2、自上而下

这种分类方法从产品目标去进行分类。先把一级分类想好，然后再进行二级分类。比如微信按照其社交软件的定位，把组织结构分为微信、通讯录、发现、我四个大类。然后“发现”里面又有朋友圈、扫一扫、看一看、附近的人等这些。

这就像我们整理自己的衣物，按照春夏秋冬四个季节，把相同季节的衣物放到一起，最后你在不同季节里分衣服、裤子

可拓展性

有的人可能说产品功能一，就会显得臃肿，那是你的信息架构没做好。比如下图的滴滴打车，已经从最初的出租车服务变成有专车、快车、代驾、ofo单车等多种服务，即使那天加个飞机、加个船，只需要加一个tab选项就行，产品也不会显得臃肿，为什么？人家的信息架构做的好啊！微信最初只是一个聊天软件，渐渐的加入了购物、游戏等功能，但是微信的用户量越来越大，产品也没显得臃肿，为什么？人家的信息架构做的好啊！

保证分类标准的一致性、相关性、独立性

西红柿就可以做为水果，也可以作为蔬菜，如果你要以水果作为分类标准，那么其他都需要按照水果大类进行分类，分类标准的唯一性不仅方便用户理解，而且能保证入口的唯一性；“相关性”是指上下层级内容以及层级中内容必须具有相关性，你不能在**的大类下面放电视剧。独立性是指同一层级分类应该是相互独立的，嘀嘀打车中的代驾，和出租车两个同一层级，就是相互独立的。

符合产品定位、满足用户需求

新闻阅读类app一般按照时间倒叙的方式来展示新闻内容，从而满足用户了解最新时事的需求，但是今日头条旨在为用户提供个性化的新闻资讯，实现内容与用户的精准连接。所以它会有一个推荐栏目，根据用户的浏览习惯推送用户喜欢看的内容。

贴合用户的心智模型

心智模型是符合用户以往社会生活经验的，符合人本能认知。（比如，方向盘是圆的，圆的是可以转动的。）等等…

在进行信息架构的时候，应尽力使信息的组织和展现更加贴合用户的心智模型，让用户更容易熟悉和使用你的产品。也就是说，让用户在使用的时候能更快的形成心智模型。

比如我们去超市购物的时候，会一直推着购物车，最后去收银台结账，所以在淘宝的信息架构中就有购物车和我的选项。

如何评判产品的信息架构设计是否合理？

1、用户是否在你不介绍具体产品的情况下，通过短时间的使用，说出产品可以用来做什么

就像我们在产品经理如何做好信息架构（上）里面提到的的微信、今日头条、淘宝的底部导航，它们的信息架构让你一眼就知道这个产品要满足的用户需求，知道产品大致如何使用，而一个成功的产品信息架构设计，就应该要满足这样的条件，所以第一个要测试的是给用户看一眼你的主界面，用户是否就能在你不介绍的情况下，短时间就能说出这个产品大致是用来干什么的，而且是准确的说出。这是第一点，它可以用来帮你评判你的产品信息架构设计在用户这个层面，能否让用户容易理解。

2、让用户进行核心流程的任务，检查完成任务是否顺利

举个例子，比如你的产品是个IM产品，你自然要让用户尝试一下使用你的产品，来完成一个发送消息的任务，比如说找到一个联系人，发送消息。你也可以尝试一下让用户来完成一个建立群聊这样常见核心流程，通过这样核心流程的测试，你可以检查一下你所设计出来的产品，是否能让用户容易的跑通这些核心任务流程，让用户在做最终事情的时候不容易碰到困难。

3、给用户一个找寻一个相对层级较深的功能任务，检测用户是否能通过信息架构名称找到功能

比如说让用户去寻找某个设置项，我们一般会以此来检测用户是否能通过信息架构的名称，顺利的找到这样的功能，这也是检查你的信息架构是否合理的非常重要的环节。也就是你的层级是否过深，以及你每个层级是否取了正确的名字，以引导用户找到他想找到的功能。

所以在做用户测试的过程中，如果你要测试的是你的产品信息架构是否合理，这三个任务是必不可少的，通过这三个任务，他可以很好的衡量产品经理是否设计出合理的信息架构。

当然在用户测试中还有很多需要注意的地方，比如说如何跟用户进行交流，如何引导用户而不至于干扰用户，包括如何寻找被测试者，如何产出用户测试报告，以及最后如何落地到设计方案，改进设计方案等等。

前端。微信公众号接口是轻前端带来良好用户体验，重后端更是保证这种体验的前提，特别是微信公众平台，产品一出生即面对数以亿计的用户群。轻前端，重后端的架构设计，无疑对平台的后端处理能力提出了非常高的要求，而这种云计算能力也正是腾讯的优势。

　　协议。手机终端跟后台服务器之间的交互协议，这个协议的设计是整个系统的骨架，在这一点做好设计可以使得系统的复杂度大大降低。容灾。当系统出现了若干服务器或若干支架(宕机的时候)，仍然需要让系统尽可能的提供正常的服务。轻重。如何在系统架构中分布功能，在哪一个点实现哪一个功能，代表系统中间的功能配置。监控。为系统提供一个智能仪表盘。

　　在协议设计上，移动互联网和常规互联网有很大的区别。首先有CMWAP和CMNET的不同，在中国现在有相当多的手机用户使用WMWAP连接，还有就是在线和离线的概念，当QQ下线的时候叫离线，当你登录的时候叫在线。但是在移动互联网这两个概念比较模糊。从微信的设计中，不管在线还是离线系统表现都应该是一致的。还有一个是连接不稳定的问题，由于手机信号强弱的变化，当时信号很好，5秒钟走到信号不好的地区，连接就必须断掉。这个中间带来不稳定的因素为协议设计带来较大困难。此外就是资费敏感的问题，因为移动互联网是按照流量计费的，这个计费会使得在协议设计中如何最小化传输的问题。最后就是高延迟的问题。

　　对此，业界标准的解决方案：Messaging And Presence Protocol：1)XMPP;2)SIP/SIMPLE。它的优点是简单，大量开源实现。而缺点同样明显：1)流量大：状态初始化；2)消息不可靠。

　　微信在系统中做了特殊设计，叫SYNC协议，是参考Activesyec来实现的。特点首先是基于状态同步的协议，假定说收发消息本身是状态同步的过程，假定终端和服务器状态已经被迟了，在服务器端收到最新的消息，当客户端、终端向服务器对接的时候，收取消息的过程实际上可以简单的归纳为状态同步的过程，收消息以及收取你好友状态更新都是相同的。在这样的模式之下，我们会也许会把交互的模式统一化，只需要推送一个消息到达的通知就可以了，终端收到这个通知就来做消息的同步。在这样的简化模式之下，安卓和塞班都可以得到统一。这样的系统本身的实现是更为复杂的，但是获得很多额外的好处。

　　让剩下系统实现的部分更加简单，简化了交互模式，状态同步可以通过状态同步的差值获得最小的数据变更，通过增量的传输得到最小的数据传输量。通过这样的协议设计，微信可以确保消息是稳定到达的，而且是按序到达。引用一句俗话：比它炫的没它简单，比它简单的没它快，没谁比他更快，哪怕在GPRS下，微信也能把进度条轻易推到底。