IBM Design Thinking: Self-Assessment
我们的客户是一家大型医院领导，请求我们运用大数据和技术手段来让医生和其它支持角色能更高效地为病患进行服务。你和你的调研团队必须利用IBM Design Thinking来理解用户，并输出更好的体验。
好了，那么第一个问题是：
我们的用户是谁？
第一个，医生，你选对了吗？病患确实有可能是我们的用户之一，但我们这里需要聚焦在医生身上。
我这边有一份医生的Persona，你觉得是否能借此对我们的用户有一个足够深入的理解了呢？
答案当然是否定的，一个Persona并不意味着已经完全了解用户了，我们需要更多的调研。
下面你安排的调研人员给你递过来一张纸，上面要待会要去电话访问用户的五个问题，让你来先审阅一下。
那么下面两个问题中，哪个能帮助你更好地理解你的用户呢？
a 你是否同意要花很多的时间在管理流程上？
b 你典型的一天工作是怎样的？
你选对了吗？是b，因为这是一个开放式问题，而类似『你是否同意』这样的都算是引导性问题。继续：
a 对于你来说每天阻碍你完成工作的事情是什么？
b 你有多讨厌那些文书工作？
应该选a哦，因为它使用了自然语言，避免了一些带有决断性的文字，比如『讨厌』，因为这很可能会影响到用户对于问题的判断和选择。
a 你能当我是病患，然后演示一下一个比较常见的预约流程吗？
b 你能告诉我一个比较常见的就预约程是怎么样的吗？
毫无疑问是选a，如果有可能，请让用户能向你展示他们怎么做，而非只是去说。
a 如果我们在病患访问你之前就把他们的一些有关数据提前发送给你，你会喜欢吗？
b 你是怎么准备一场预约的？
选b哦，因为这是一个开放式问题，第一个问题听起来就是在预想一个解决方案，而当前调研的目的是去尽可能地理解用户，而非是去验证一个预想的方案。
a 如果我们去利用大数据和分析手段去管理并自动生成用户数据，你会喜欢吗？
b 要想更便捷地浏览病人的数据你一般会怎么做？
选b，你一定要确保你是站在用户的角度去想问题，而非去问『如果怎么样怎么样你是否怎么样怎么样』，而且和他们分享那些潜在的特性往往会局限掉那些创新性的解决方案。
好了，接下来你将会通过实例更好地理解之前我们提到的循环是什么。
观察：通过沉浸在用户的世界中帮助你更好地理解他们、揭示需求、共享愿景、验证想法。
问：
谁是我们的用户？
他们的需求是什么？
他们有什么样的反馈？
拜访Sponsor User然后拍些照片，这里有很多需要注意和值得挖掘的东西。比如你可以通过厚厚的一沓纸判断出用户每天可能要做大量的打印工作，而那些储物柜是否能塞得下所有病患的记录呢？那台传真机是不是把每位病人的信息传真给那些医生的呢？还有电话、显示器，甚至挂在椅背后面的夹克。
反映：通过会晤交流来构建针对当前问题的一致性观点，揭示洞察、同步想法、绘制计划。
问：
目前我们学到了什么？
我们是否有洞察了？
我们是否同步？
下面请试着选一下以下三个As-Is Scenario Map哪一个更接近医生在电话访谈里所描述的？不过鉴于译者懒得逐字翻译之前的电话访谈内容，所以我就直接把正确的那个贴出来吧：
之前访谈的用户针对以下哪几步表现出了最大的痛点？
而根据之前我们对其的了解，Empathy Map也可以完成了，当然你可以补充更多的信息：
创造：让之前抽象的想法落地，交流故事、把可能性原型化，产出真实的结果。
问：
可能性是什么？
我们的概念是什么？
我们的故事什么？
根据之前对访谈用户的了解，这边可以有一些既定的方案来解决那些问题，可以设定一分钟的时间来构想，有哪些加速问诊流程的方法？
译者太懒，所以三个框空着。
IBM的设计团队现在已经很明确地知道我们的用户需求了，那么我们可以为他们带来些什么呢？团队成员们现在应该考虑做什么？
a 写下细致的功能需求，这样大团队能稳妥地进行构架，而不需要去理解用户或者解决方案背后的动机；
b 写下我们的Hills，这样大团队能够始终保持同步；
c 让Sponsor Uer与开发团队进行一次非常详尽的沟通；
答案显然是b，之前译者已经把Hills的作用以及要注意的点都告诉过你们了，这边再温习一下，Hills主要由三大件组成：who/what/wow.
Who: 谁是你的用户？同样的，谁不是你的用户？
What: 他们要达成的需求是什么？把用户需求转化为项目目标。
Wow: 你是怎么与竞品区分开来的？你又是如何衡量成功与否的？
直接举例吧：
Hill 1: 一位专科医生，第一次接见一位被引见得病人，能够在五分钟之内就获取到所有关于这位病人病史的数据，并且能根据时间节点从中快速筛选，从而获知该病人的问题症结所在。
Hill 2: 一位内科医生，当面对那些对当前疗法毫不见效且需要决定如何进一步被关照的病患时，能够在一分钟之内就了解所有之前就该问题的治疗方案和诊断信息。
Hill 3: 一位内科医生，当面对患者的病历时，能够在撇除大量无关信息的情况下快速定位与该病患相关的有用信息。
当Hills有了之后，也就是说我们团队成员的想法都趋同了，接下来要做什么呢？
a 写下用户的故事，这只需花费0元，而且一天之内就可以完成；
b 创建一个可工作的原型，这需要花费10000元，还要四周的时间来完成；
c 创建一个低保真原型，大概5元就可以了，12分钟就可以完成；
是的，选c；我们需要输出低保真原型来进行快速验证。
IBM 设计团队决定在一周之后和客户进行一次会晤，那么他们届时应该做些什么呢？
a 就和客户谈谈自己的想法，因为好的原型往往需要花超过一周的时间来准备；
b 把会晤往后延一些，直到团队的想法被开发到已经能拿出手的程度；
c 只是简单地把想法可视化一些，向客户展示基这些想法而实现的低保真原型，可以是纸质的，也可以是线框图；
d 跳过这次会晤，这么早就和客户见面很容易让他们失望；
选c哦。
你已经和设计团队有了默契的合作，接下来你将进入再次反映这一环。
再次反映：通过会晤交流来构建针对当前问题的一致性观点，揭示洞察、同步想法、绘制计划。
问：
目前我们学到了什么？
我们是否有洞察了？
我们是否同步？
鉴于这是再一次的反映，我们要安排一下相关人员的会面，那么该邀请哪些人来呢？
答案是除了整个开发团队之外的上述所有四个角色。在这一次，并不仅仅是设计师团队了，而需要让所有相关的利益相关者参与其中，比如business leader，delivery lead, sponsor user和project sponsor，而此时不要牵涉到开发人员
那么在这次会晤中我们需要安排哪些议程呢？
a 介绍、用户情境、 商业需求矩阵、工作计划。因为一开始的时候我们是要去想着怎么能帮助到用户，但只有做到这几步才能让一切城镇。要知道高级的利益相关者并不想听你有多么绚烂的想法，他们想要的只是你的解决方案是怎么构成的，以及它们要花掉多少钱。
b 介绍、项目背景的精简报告、用户（医生）的As-Is Jouney Map、洞察、To-Be Journey Map、原型、反馈。因为我们都要聚焦在用户的故事上，然后还要反映出想法背后的思考过程。
这个我想不算难回答吧，应该选b。
不需要几个小时，整个设计团队就已经经历了一次循环，且参与了一次playback。
你已经完成了一次基本的流程，但相信这对于你来说只是一次开始，相信你已经准备好了。
记住了，循环永不终止。
译自：
IBM Design Thinking University
这是这个Publication中关于IBM Design Thinking的最后一课啦，请关注我更多的其它文章，谢谢。
