公交用户出行时，有通勤和陌生两种场景，当用户对出行线路越熟悉时，该场景下对信息需求越少；越陌生时，信息需求越多。通勤场景下，用户已熟知在什么地方可以坐哪一趟车，往什么方向，去哪下车，对于用户来讲，只需要知道目标车辆什么时候来到即可；而对于陌生场景，用户可能只知道目的地(陌生程度最高），其他信息都还未知，这种场景下，我们需要帮助用户规划好线路，具体包括从哪上车，坐那一趟车是否需要换乘等信息有序告知用户。不同出行用户所处的位置及所需车辆信息可能各异，但相同点是，每个用户都是以自己所在位置为中心向周围寻找车站车辆相关的信息。

公交出行助手希望通过提升出行用户的信息获取效率及对出行信息的掌控感，从而提升用户的信息获取体验，让乘坐 "低调的百万豪车"出行也有私人定制感。（大中城市的公交车一般都不便宜，从100万到300万不止）那么用户到底在什么样的场景下需要什么样的信息呢？城市公交出行覆盖了男女老少群体，包括了工作出行，社交出行，生活出行各方面的场景。在广深地区，尤以学生和上班族两个群体居多。对广州深圳两地很多用户，并针对性的对某些代表性用户进行了深入观察，访谈，了解用户公交出行的场景及遇到的一些困难点，希望更全面地了解公交出行用户的行为与诉求。

公交出行与私家车出行体验截然不同。公交车辆及线下信息资源具有共用性及限制性特征，在使用时间及地点上不由使用者的个人时间与意志而随意变化调整。乘客线下获取出行信息的主要方式是通过公共车站站牌，需要时挤入人群走近站台查找站点及车辆信息，然后等待车辆的到来。有时候在查找信息时已错过目标车辆，只能默默等待下一趟车的到来。这样的信息获取方式，不仅有很大的不确定性，从信息获取效率上来讲也是比较低效的。

对用户核心路径的优化，页面中露出内容、便捷入口比如XX APP，旧版本用户在追更、继续阅读时，通过点击书架，然后再次点击作品进行阅读。在观察用户行为时，发现用户持续阅读的行为次数远大于浏览寻找新作品的行为次数，为了让用户最方便地进行追更与持续阅读，在首页放出了最近在看的作品，让用户能快速进行阅读，同时采用横封的形式，以保证该栏目不会过高。A.采用这个方法通常要观察用户的行为数据，分析用户的行为路径，同时也要与产品沟通确定好优先级与产品策略。B.采用这种方式时，通常都是结合左滑的手势露出更多的作品。

列表型、宫格型入口架构改为tab的形式，把跳转页面改为滑动页面当页面承载信息少，并且不展示每个模块二级内容的时候，可以采取列表型、宫格型的导航设计，这样可以帮助用户快速的定位到相应的页面，但是每次信息获取时，需要点击跳转到另外一个页面。当每个模块都需要展示一部分内容的时候，假如采用列表型导航设计时，往往就会导致页面高度过长，用户需要滑动好几屏幕才能浏览完信息，这样导致信息获取的效率大打折扣。此时考虑采用tab的导航方式，把不同类型的内容形式通过tab的形式展示出来。这样做可以有两个好处：1.用户能快速掌握全局内容类型2.能快速切换定位目标内容进行信息获取

信息的无限性和手机屏幕的有限性之间的矛盾，如何把信息合理的展示给用户，需要重新对信息进行组织分类，使信息能更高效有序地被用户认知。在进行信息设计的时候，会经常遇到“扁平化设计”这个词，扁平化设计可以理解为：“精简交互步骤，用户用最少的步骤就完成任务”。层级太多了用户就会看不懂；即使看得懂，层级多了用起来也麻烦，因此：手机上能不跳转就不跳转。那就来看看有没有办法减少跳转…

关于手机使用场景对文本输入交互的影响手机输入本身就麻烦，再加上用户在移动状态下还特危险，很多交通时候、抢手机事件都是用户处于输入状态下发生的。如果拼音不及格，死活输入不了想要的文字，那就更要命。如何解决输入问题是用户体验的突破点之一。以搜索为例，Google Search提供了语音搜索功能，丰富了搜索输入的交互模式，如果你不是恶作剧，以及普通话过关，一般精确率很高。

客户与用户的概念--群体不同：客户在ToB类项目中可以理解为项目的招投标方，是金主、是客户方的管理者；而用户可以理解为最终使用人员。--利益诉求不同：做ToB的项目首先需考虑客户的利益，简单理解就是这个项目对客户企业有没有价值，是否帮助该企业提升效率，降低成本；然后才考虑用户体验。产品与项目的概念--阶段性目标：在ToB类项目中，客户的每一次招投标/立项就会催生出一个带有周期性交付工作的任务，我们就可以把它理解为一个项目。

定义ToB项目管理ToB业务中包含两类：1）纯ToB的业务，不跟C端用户直接产生产品交互，比如给客户提供基础的云服务，至于客户用云服务提供什么给他的用户，可不纳入我们考虑的范围；这类业务也包括传统的软件服务，如用友、金蝶提供的ERP软件等。2）ToB再ToC的业务，例如金融业务里和B端客户是合作关系，一起为C端客户提供产品价值，存在产品交互。比如理财通就是B端的客户接入，再给C端用户提供理财产品。我方为用户和企业之间建立了一个可连接的平台。

迭代优化迭代优化的关键其实在于认知了解自己的差距，“不只是低头干活，而是需要抬头去看这个行业”，多去和周围成功的项目交流，去把自己当前已知的问题拿去请教，把自己当前手中的实际工作状况去比较，从而发现未知问题，是迭代优化的第一步。信息量充足，可以有非常多的优秀项目去学习，请教，找到差距，平台的技术能力也是产品优化的一个重要亮点

“把错犯在前面”如果我们广泛去定义bug是一切不符合初始设计的结果，那么很多事，都可以结合这个思路去尝试优化，游戏逻辑bug也好，玩法也好，数值平衡也好。包括后续看起来在实际运营过程中看起来并没有发挥特别大作用的体验服，我们最终还是决定把他留下来，并去优化他，主要就是在于：对于没有灰度服以及版本兼容的游戏，体验服是一个唯一的灰度的部分，他的存在本身，是不可替代的。Tips:产品上线，基本会经历一次大规模轻测，1到2次付费测试，而随着苹果政策的开放，testfight测试的规模量级表大，实际的可操作空间也被放大。而在当下，测试的留存数据（次留以及登录比）的优先级由于在正式测试中发现问题，而给我们的机会，就主要是在上线前组织的小规模测试。

风险的认知以及应对对于风险，最理想的，当然是能彻底消除掉了。当然这是一个比较理想的情况，而理想如果没有办法达成，我们只能沉下心，面对这些现实，我们到底有哪些风险，而这些风险，我们应当如何去应对这些风险。光鲜的页面活动和游戏画面在玩家面前，而冰冷的现实拍在我们的面前，直面实际项目的风险，也是直面项目客观存在的问题。这里有一个心得：所有的风险都会有相应的处理方案，也会付出相应的代价，没有无法解决的问题，首先是，你要去直面这些问题。Tips:筹备重要节点的时候，总有一种枕戈待旦的感觉，不可控的风险不需要去恐惧，需要做的是，将其影响范围在一开始降到最低，以及及时有效地去应对。

善用流程实际工作中，流程也是一个较为好用的管理工具：有些时候，我们目标一致，建设流程以提高配合的工作效率；而有时，宏观目标一致，而细节量化时，存在认知差异，导致难于实际推动。那我们可以依靠建设流程来驱动各模块共同为了一个不完全一致的目标完成自己阶段性的工作。而个人认为，推动事项的过程中，流程的优化会对推动效率有直接的帮助。离散型推动：简单称为单向沟通跟进，一种较为原始的手段；梳理流程，大家按照流程去执行，PM按照流程check进度。这种手段更加适用于强管理关系的组织；找到关键点，形成自驱动：是较为高效且省力的一种推动手段，流程是串联其中的一个方式，而核心是在于，找到关键事项来驱动各模块协同工作

流程梳理“人，事，时间”所有和项目管理打过交道的同学都应该为这几件事操碎过心，想要调动一个大的团队协作，是一件非常不容易的事情，流程是否清晰直接决定了整个团队的配合效率。以一个怎样的流程展开工作，是开工前，一定要明确的一件事。核心串联一个流程的是“事”，以事项前后为线索去梳理整体流程，倒推时间，分配负责的人力。而在实际的工作中，运营侧的版本管理对于开发侧的程序、美术、测试等实际掌控力较为有限，主要是协调公司内部同事（运维，测试，安全，以及等等其他相关支持的同学）协同工作，这里如何去驱动各模块同学配合，也是考验一个版本管理沟通以及关系维护的能力的时候。