首先，介绍一下这个博客的作者背景：英国GDS设计组的用户研究团队，在博客中分享的内容包括用户研究的案例、方法论、研究思考和计划等等内容。这些研究的主要对象是英国的政府网站（GOV.UK），同样也包括如铁路信息系统、民众的投票流程等一切你能想到用户体验适用的领域。
博客链接：https://userresearch.blog.gov.uk/
本文内容概要：
本文介绍了对GOV.UK中早期教育（early years,0-12岁）模块的信息架构（导航、标签等）的用户研究案例。内容涉及到案例相关的研究方法、对象、结果及经验总结。
原文链接（无需翻墙）： Practice makes perfect: evolving our user research for GOV.UK
研究目的：
A.GOV.UK中教育相关内容的用户；
B.GOV.UK解决了用户的什么需求；
C.用户使用了多少GOV.UK中教育相关的内容
参与用户：
A.保姆、幼儿教师、班主任、学校管理者；
B.学校及学术机构的高级领导层；
C.特殊的专业人群，如教育咨询从业者、就业咨询师和数据分析师等；
D.不在教育行业当工作内容中需要获得相关信息的群体，如在儿童托管机构、本地政府和新闻记者等。
研究规划（第一轮）：
A.现场研究（在家）：首次13名加第二次15名用户进行现场访谈，了解用户的工作及生活方式、工作中会需要的信息、用户当前获取信息的渠道和方法；
B.卡片分类：包括70名用户；
C.树形图测试：包括65名用户；
D.现场研究（在学校）：24名用户，包括老师、管理层及就业导师；
研究发现:
本部分内容，包括之前对参与用户的描述，发表在另一篇博客中:The finding and the things.
用户需求：
A.及时了解政府政策的相关变化；
B.了解政策变化的真正含义；
C.了解如何在实践中落实新的政策要求；
GOV.UK的不足：
A.很难判断网站上重要文件的多个版本中哪一个才是最新的版本；
B.用户当前订阅的GOV.UK及其它渠道并总是能够给出及时可靠的新政策信息；
C.很难在冗长的新文件中找到政策的细节变化；
D.政策文件通常使用许多术语或复杂的语法，不易于阅读、理解和执行；
第一轮研究的经验和教训：
A.研究流程之间的时间太短，使调整研究内容变得很困难 --- 尤其是在第一次访谈（13人）中，用户帮助研究人员确定了新的用户群体；
B.在研究的最后进行数据分析意味着必须等到研究的最后阶段才能开始产出有价值的研究结果/灵感；
C.不同用户群体开始给出重复的答案 --- 意味着应该改变研究方法或研究目的了；
基于以上的原因，他们又设计了第二轮研究：
研究规划（第二轮）：
A.用户招募公司招募第一批用户（2周）；
B.对第一批用户进行访谈的同时开始第二批用户的招募（1周），访谈过程中包括树形图测试；
C.研究人员对第一批访谈的结果进行群组分析（1~2周）；
D.对第二批用户进行访谈的同时开始第三批用户的招募，直至访谈完全部用户群体。
本文内容到此结束了，再安利一个相关的链接：
GOV.UK上关于用户研究的主页：https://www.gov.uk/service-manual/user-research
内容包括3大模块：1.理解用户研究是什么；2.如何准备一场用研；3.分析和分享研究结果。
学习心得：
这个案例充分体现了用研与敏捷开发的冲突... 呃... 这么一波黑自己的理想职业会不会不太好...
认真地讲：
1.很难确定任何研究计划都是完美甚至有效的，包括学术研究中不管事前想的控制有多严格，现实总会冲出来啪啪的打脸...(毕业论文实验改了N次的痛...)；
2.你的用户不仅仅是你以为的你的用户；
PS.优化导航确实是应该做的... 用过的人才知道GOV.UK的信息架构做的多糟心... 虽然政府工程涉及的相关内容确实是很多...
