Wiki source code of ITIL 4 客户旅程:从理解用户到构建真实体验的设计思维五步法
                  Last modified by superadmin on 2025/05/24, 10:51
              
      Show last authors
| author | version | line-number | content | 
|---|---|---|---|
| 1 | == **一、什么是设计思维?为什么它是ITIL 4服务设计的核心能力?** == | ||
| 2 | |||
| 3 | **“以用户为中心”不是口号,是方法** | ||
| 4 | |||
| 5 | 在ITIL 4 DSV课程中,服务设计已经不再局限于流程或工具的组合,而是更强调如何在**真实场景中理解用户需求、引导价值共创、持续迭代优化服务体验**。这正是设计思维所能提供的系统性方法论。 | ||
| 6 | |||
| 7 | 设计思维的独特价值在于,它不是要解决一个抽象的问题,而是要在一个具体的、真实的用户环境中,找到最贴近实际、最可行的解决方案。 | ||
| 8 | |||
| 9 | 我们不再假设“用户说的就是他们需要的”,而是借助设计思维的方法,通过共情、访谈、行为观察等方式,深入理解用户背后的动机、痛点与期望。ITIL 4本身就强调服务体验是以感知为基础的价值,因此,设计思维恰好提供了这条通向真实感知的路径。 | ||
| 10 | |||
| 11 | |||
| 12 | [[image:1748055072695-993.png]] | ||
| 13 | |||
| 14 | ---- | ||
| 15 | |||
| 16 | == **二、设计思维的五步模型详解:每一步都为真实体验服务** == | ||
| 17 | |||
| 18 | **1.共情(Empathize)** | ||
| 19 | |||
| 20 | 这是整个设计思维流程的起点。我们必须抛开自己的角色假设,用“用户的视角”重新审视服务中的每一个触点。这不仅仅是做调研,更是带着真实的问题去聆听、去体察、去体验。 | ||
| 21 | |||
| 22 | 比如你要优化某政务服务窗口的用户体验,不是问“你满意吗”,而是坐在大厅看用户的排队、问询、填写表格、等待反馈等整个流程,从而找出那些“说不出口的不满”。 | ||
| 23 | |||
| 24 | **2.定义问题(Define)** | ||
| 25 | |||
| 26 | 有了对用户情境的理解,我们接下来要提炼问题。不是“系统不好用”,而是“用户不知道该选哪个入口”、“服务流程之间缺乏提醒机制”这些具体可操作的设计目标。 | ||
| 27 | |||
| 28 | 这一步是连接感知与行动的桥梁,把模糊的困扰变成清晰的命题,是ITIL 4强调“价值定义协商”理念的直接落地。 | ||
| 29 | |||
| 30 | **3.创意发散(Ideate)** | ||
| 31 | |||
| 32 | 我们在这个阶段要突破既有框架,进行广泛头脑风暴,鼓励不设限地构思各种可能的方案。关键不是一开始就对方案做判断,而是尽可能放大探索的边界。 | ||
| 33 | |||
| 34 | 很多时候,最有价值的想法不是第一个出现的,而是第五个、第十个,甚至是别人观点的组合变形。 | ||
| 35 | |||
| 36 | **4.构建原型(Prototype)** | ||
| 37 | |||
| 38 | 这个阶段把构想变成“看得见、摸得着”的形态,哪怕它只是一个简单的界面草图、一个流程卡片、一个互动演示。重点在于快速可视化,让用户参与感知并反馈。 | ||
| 39 | |||
| 40 | 在授课中,我讲解过一个具体案例:某公司计划改版官网,为了验证栏目设置是否合理,设计团队先搭建了几个静态网页原型,分别代表不同的信息架构方案,然后邀请不同用户进行导航操作测试。结果显示,原设计中逻辑最自洽的一版却最难用,最终他们采纳了另一套看似不完美但“用户走得通”的结构方案。 | ||
| 41 | |||
| 42 | **5.用户测试与评估(Test)** | ||
| 43 | |||
| 44 | 原型并不是“预交付物”,而是检验方案可行性的实验工具。测试阶段通过真实用户的操作行为、语音反馈、情绪识别等手段,进一步收集优化建议,进入下一轮迭代。 | ||
| 45 | |||
| 46 | 整个设计思维的过程,是一个螺旋上升的动态优化路径,与ITIL 4强调的“持续改进”和“价值共创”高度一致。 | ||
| 47 | |||
| 48 | |||
| 49 | ---- | ||
| 50 | |||
| 51 | == **三、设计思维与敏捷的关系:做什么 vs 怎么做** == | ||
| 52 | |||
| 53 | **1.设计思维回答“做什么是对的”,敏捷则解决“怎么高效做到”** | ||
| 54 | |||
| 55 | 很多组织在服务改进中引入了敏捷机制,比如Scrum、Kanban等交付节奏控制方法,但常常出现一个问题:**做得很快,但方向始终偏了**。 | ||
| 56 | |||
| 57 | 这就是缺少设计思维引导的问题。设计思维是在项目开始前,甚至在需求成形前,就通过系统性方法寻找问题本质、识别真正价值点。而敏捷更多是在“知道做什么”之后,高效推动完成。 | ||
| 58 | |||
| 59 | 所以,这两者并不是替代关系,而是高度互补:**设计思维主导服务构想与方案探索,敏捷主导落地实现与迭代优化**。 | ||
| 60 | |||
| 61 | **2.服务设计前期必须“慢一点”** | ||
| 62 | |||
| 63 | 我们常说“慢就是快”,尤其是在服务体验类项目中尤为重要。没有设计思维,很多组织的快速上线、短周期迭代,可能只是不断打补丁,无法跳出旧有逻辑。用设计思维先打下用户理解与问题定位的基础,再用敏捷驱动实现,才是ITIL 4所倡导的现代服务交付路径。 | ||
| 64 | |||
| 65 | |||
| 66 | ---- | ||
| 67 | |||
| 68 | == **四、原型与MVP的差异:不能混为一谈** == | ||
| 69 | |||
| 70 | **1.原型是“用来试”,MVP是“能用的真产品”** | ||
| 71 | |||
| 72 | 虽然两者都强调“快速验证”,但原型是为了探索,是未完工的设计呈现;而MVP是最小可用版本,是功能可以落地并运行的初始产品。 | ||
| 73 | |||
| 74 | 在设计思维中,原型更多是低成本、低风险的“设计实验”,用于快速观察用户反应;而MVP是在确认方案方向后,用以进入市场、真实运营的“价值测试工具”。 | ||
| 75 | |||
| 76 | 区分这两者非常重要,因为它决定了我们如何安排资源、如何设定用户期待、如何衡量反馈价值。 | ||
| 77 | |||
| 78 | **2.原型阶段要舍得“废掉”,MVP阶段要考虑“可扩展”** | ||
| 79 | |||
| 80 | 不要恋战设计过程中的任何一个中间成果,该放就放,该删就删。原型失败不是失败,而是找到更优解的必经之路。 | ||
| 81 | |||
| 82 | |||
| 83 | ---- | ||
| 84 | |||
| 85 | == **五、设计思维为何成为IT服务转型的关键抓手?** == | ||
| 86 | |||
| 87 | **1.从“满足需求”到“感知体验”的转变** | ||
| 88 | |||
| 89 | 过去我们的服务设计往往是被动响应式:客户说要什么,我们就做什么。但ITIL 4推动我们从“服务提供者”变成“价值共创者”,而这就需要更深的洞察、更精细的感知。 | ||
| 90 | |||
| 91 | 设计思维让我们有能力从“业务逻辑”切换到“用户视角”,从而设计出真正被用户感知、接受并喜欢的服务。 | ||
| 92 | |||
| 93 | **2.打通组织内外,构建真正的“服务旅程”** | ||
| 94 | |||
| 95 | 设计思维的过程并不只是一个项目团队的事情,它天然需要跨部门协作、跨角色共创。它把客户、业务、IT、支持团队拉到一张画布上,围绕用户旅程构建出完整的服务交付路径。 | ||
| 96 | |||
| 97 | 这种跨界思维、共创机制,本身就是ITIL 4希望我们在服务价值流中实现的治理协同模型。 | ||
| 98 | |||
| 99 | |||
| 100 | **ITIL 4大师级课程官方授权讲师长河老师原创,末经许可,不得转载** | 

 ITIL 4官方核心著作
  ITIL 4官方核心著作 
   
   
   
   
  

 Copy
 Copy Export
 Export Print preview
 Print preview View Source
 View Source Children
 Children Content
 Content Comments
 Comments Attachments (1)
 Attachments (1) History
 History Information
 Information

