接手医疗行业SaaS产品的第一次上线引发了连续一周的用户需求提报小高峰，综合统计，主要分布在交互层面…这让我更加觉得过去根据功能套用自认为最佳或者常见的交互不够专业，因为自以为满意，用户也可能觉得完全不好用。
趁着可贵的挫败感，这周针对这些问题看了一些交互设计知识，也有一些自己的思考，今天主要说说信息架构部分。
信息架构是个复杂而庞大的体系，但在产品设计中不管是基于场景还是任务目标，最重要的是建立有效的沟通结构。如何建立有效的沟通结构？
1、让用户在合适的场景看到必要的信息
用户在什么情况下需要知道哪些信息？是消费内容信息？决策支撑信息？异常反馈信息？这是产品设计中核心的部分。充分、符合场景及习惯化的信息组织是体验设计的重要环节，也会影响整个流程的效率和进展。
例如这次接收的需求中有一个是开方特殊剂量换算常规剂量需求，原产品设计初衷是为了让用户开方输入数量时能看到对应总常规剂量，但却忽略了用户在知道单规格的换算数值之后才知道怎样输入数量…若先录入数量知道换算比再调整真实剂量数，则增加了决策流程和操作步骤，损伤了单个任务的流畅度与体验。
做到在合适的场景看到必要的信息并不容易：
①这需要对用户故事、场景精细化的探索与思考，能站在用户的角度感知完成任务的思路与所需信息。
②所需信息可能是庞杂的信息中的一两条，但若不知庞杂的整体又很难甄选当前场景所需。
③大概率用户并不能完整清晰描述自己的需求，部分需求需要我们更加细致、深入的挖掘。
这些都回归了需求问题，我们可以选用当前可行的方式比如深入场景调研观察、用户访谈、行业学习、用户职业整体了解、心理学、竞品解决方案…去获取和挖掘业务和用户信息，作为方案决策的有力支持。
做产品的时间、思考力、经济成本最该投入在需求研究上，这是一个产品的根，清晰可靠、细节丰富的产品故事可以顺理成章、逻辑自洽的发散为一棵健康茁壮的树木。自己也暗暗定下打算突破自己的沟通阻力，选择几家合适的客户展开详细的调研，争取更多的进入用户场景和深入交流获取信息的机会，哪怕很多调研结果最终没能影响方案的决定。
2、信息层次清晰
就像我们的研发工程师喜欢123,1-1、1-2、1-3…这样的文档备注序号；我们读文章喜欢标题大、内容小、重点加粗一样，在软件内也需要信息清晰的可读性，唯一不同是软件组织了整个业务流中需要的所有信息分别部署在必要的步骤上。
最近在对诊室的改版方案中明显感到了关于大量信息组织的压力，从患者信息、历史病历、处方模板、中药西药治疗模板、医嘱、用法…需要有机的组织在一个页面内，信息的层次就更加的重要，是否能快捷、清晰的呈现和识别信息，不违背他们原有认知和习惯的组织方式将直接决定医生的开方效率。
在思考信息的层次和组织时需要充分理解他们在真实场景中的关系，在业务层面有深刻的认知，然后依据关系安排信息级别、从属、重要性等。
3、良好的扩展性
良好的扩展性是基于信息层次清晰的高阶要求，产品对信息不清晰的理解可能直接导致抽象出错误的关系，影响整个数据结构，在未来花多倍的精力去修改和迁移数据。自己就见证过多个失败的产品源于此，新项目没经历几个迭代就选择重构，因为有时候修改比重构成本更高。
这一点对于产品的要求更多在规划能力，除了当前业务信息要清晰组织外，最好能向前再想几步，这个功能未来会怎么演变？需要怎样的数据结构兼容？这一点我也不算擅长所以我爱用解耦的方式让系统的每个部分尽可能的模块化，以后可以以较小成本改造扩展。当然这些起码要求对当前业务信息能清楚的组织，这样其实未来不太会留很大的坑。
很多产品信息、功能看似都有，但交互体验就是不好，好的体验需要庞大的决策依据信息和全局化、精细化的方案决策而不是机械的拼凑。有时候那种大费周折最后还是回到最初方案的感觉令人有白费力气的错觉，但在对需求和解决方案的反复思考中理解更加深刻，产品轮廓更加清晰，更能看到自己的不足。
好的产品经理能在不同的产品打磨中提炼出产品元能力，明确业务就能从0到1自主架构一套适配业务、稳步拓展并且用户体验佳的产品，这个目标还有一段上下求索的过程，继续走吧，少年。
