手册架构评审不只关注设计的规范性，更应关注手册的实用性，需要有效组织内部用户和专家进行意见反馈和风险评估。
评审团构成
评审时间太长怎么办？
评审会以业务领域专家为主，不讨论规范性问题。根据手册类型选择相关部门的业务代表，不必每次都包含所有领域。
评审流程
准备阶段：
评审责任人协调资源，发送邮件，准备评审记录用的质量控制表格。
信息架构师准备演示手册大纲，进行业务场景澄清，陈述设计逻辑。
评审中：
评审责任人启动评审会议
评审负责人解释评审程序，提醒业务专家用质量控制表进行记录和评分；
信息架构师陈述大纲设计的价值和逻辑
先介绍本次手册大纲改进的目标用户群体，最好以用户画像的方法呈现，介绍目标用户的所属组织、岗位、技能和任务；
介绍本手册与其他手册的配合关系；
介绍本次手册改进的核心价值点，从问题解决视角出发，不讨论在规范性方面的优化点，只关注业务层面的价值点。
介绍大纲的设计逻辑，解释标题含义，说明每个层级标题与用户场景的关联关系。
业务领域专家对大纲设计进行意见反馈
用集体讨论的方式提问和解答，由业务领域专家依据用户场景及任务，对内容是否完整、顺序和视角是否合理，提出反馈意见；
架构专家不向架构师提问，可以引导业务领域专家进行价值确认，例如询问服务领域的代表，本手册的目标用户选择是否恰当，价值点是否突出；
架构师进行问题回答，架构专家辅助解答，并终止一些架构相关性低的问题的讨论。
按照质量控制表格的分类和打分规则，在表格中对问题的重要性和紧急程度进行打分。
评审责任人组织风险点表决
业务场景分析的风险最高，问题优先级最高；
设计逻辑的问题较易修正，排序也靠前；
不能立即修正的风险点，是否同意带风险进入内容开发。
评审后：
信息架构师在评审结束后进行架构修订，完成后在评审报告中进行反馈，并将评审报告提交给评审负责人。
评审责任人将评审反馈结果转发给评审组，闭环问题和收集新的意见。
架构专家是否提评审意见？
架构专家进行规范性和技术性评审，提出改进意见，与业务领域反馈的问题合并列表，同时进入评审报告进行跟踪闭环。
