惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

B
Blog RSS Feed
V2EX - 技术
V2EX - 技术
P
Privacy & Cybersecurity Law Blog
T
The Exploit Database - CXSecurity.com
美团技术团队
WordPress大学
WordPress大学
博客园 - 司徒正美
S
Securelist
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
博客园 - Franky
Attack and Defense Labs
Attack and Defense Labs
Security Latest
Security Latest
L
LINUX DO - 最新话题
NISL@THU
NISL@THU
freeCodeCamp Programming Tutorials: Python, JavaScript, Git & More
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
让小产品的独立变现更简单 - ezindie.com
让小产品的独立变现更简单 - ezindie.com
腾讯CDC
Y
Y Combinator Blog
The Hacker News
The Hacker News
Security Archives - TechRepublic
Security Archives - TechRepublic
IT之家
IT之家
T
Threatpost
Hugging Face - Blog
Hugging Face - Blog
Scott Helme
Scott Helme
S
SegmentFault 最新的问题
Cyberwarzone
Cyberwarzone
C
Cisco Blogs
阮一峰的网络日志
阮一峰的网络日志
U
Unit 42
B
Blog
Microsoft Azure Blog
Microsoft Azure Blog
P
Proofpoint News Feed
小众软件
小众软件
V
Vulnerabilities – Threatpost
J
Java Code Geeks
V
Visual Studio Blog
Cyber Security Advisories - MS-ISAC
Cyber Security Advisories - MS-ISAC
A
Arctic Wolf
博客园 - 【当耐特】
Microsoft Security Blog
Microsoft Security Blog
S
Security @ Cisco Blogs
雷峰网
雷峰网
Help Net Security
Help Net Security
The Last Watchdog
The Last Watchdog
Recent Announcements
Recent Announcements
G
Google Developers Blog
C
CERT Recently Published Vulnerability Notes
T
Troy Hunt's Blog
MyScale Blog
MyScale Blog

人人都是产品经理

为什么你的产品找不到差异化?90%的失败都卡在第一步上(下) – 人人都是产品经理, 3年从30万到1300万用户、获2200万美元融资,这个AI教育产品用“抽卡”破解了获客难题 – 人人都是产品经理, 园区招商系统怎么做才能真正帮到去化?我加了这一个功能,推广链接转发400次阅读过万 – 人人都是产品经理, AI大事件:OpenAI发完网络安全模型又搞药物研发,小鹏汽车要抓”DeepSeek时刻” – 人人都是产品经理, 电商不是卖货,是一场更残酷的产品经理实战 – 人人都是产品经理, 没想到,活动营销又回来了! – 人人都是产品经理, 为何All-in海外KOC:一场关于AI时代窗口期的豪赌 – 人人都是产品经理, 重新理解企业的内部协作 – 人人都是产品经理, 苹果的 AI 战略到底是什么? – 人人都是产品经理, 医疗智能体·第2讲——合规护城河:等保、PIPL与HIPAA的架构实战 – 人人都是产品经理, 向量知识库五步法:从“答非所问”到“精准回复” – 人人都是产品经理, 鸿蒙PC三方库构建总指挥HPKBUILD(sha)库为例 – 人人都是产品经理, 何时该用LLM?AI产品经理的LLM设计指南 – 人人都是产品经理, 医疗信息领域的需求方、决策方、准入方以及关注点(二) – 人人都是产品经理, 即梦涨价:一场被误读的「傲慢」 – 人人都是产品经理, 面试AI PM必答题:Hermes和OpenClaw的区别,如何讲清楚业务价值 – 人人都是产品经理, AI的下一张船票:世界模型——AI产品经理必须理解的技术拐点 – 人人都是产品经理, 小红书做GEO,怎么让AI信你?记住这 3 个重要信息 – 人人都是产品经理, 5 家印度 AI 初创公司,看看印度 AI 再做什么 – 人人都是产品经理, AI项目跨团队协作:产品技术业务如何不打架 – 人人都是产品经理, Agentic Workflow(智能体工作流):让AI从”答案生成器”变成”数字员工” – 人人都是产品经理, lycium_plusplus 项目全景解读:OpenHarmony 三方库构建的“大管家” – 人人都是产品经理, 从爆单救火到前置履约:两套预采策略,把生鲜大促履约效率拉满 – 人人都是产品经理, 什么时候该补货?我用一轮数据做了一个决定 – 人人都是产品经理, 从“机械兜底”到“动态分流”:AI客服重复进线治理的4大底层逻辑 – 人人都是产品经理, 抖音拼效率,红书拼洞察 – 人人都是产品经理, 全民狂欢与退潮——为什么龙虾这波热潮冷却得如此之快? – 人人都是产品经理, Stripe押注!MPP重塑全球支付 – 人人都是产品经理, 小红书GEO:AI引用你的内容,不是因为你对,而是因为你看起来可信 – 人人都是产品经理, 前百度副总裁押注办公Agent,日韩付费爆发,Manus迎来强劲对手 – 人人都是产品经理, 企事业单位数字化的业务供需本质 – 人人都是产品经理, 医疗智能体·第1讲——医疗信息化重构:从“辅助软件”到“自主智能体”的范式转移 – 人人都是产品经理, 粉丝量就是空气!!! – 人人都是产品经理, 用户说“薯片碎了”,机器回“要买吗?”:意图识别的翻车与破局 – 人人都是产品经理, RAG召回准确率从75到90 我做对了这三件事 – 人人都是产品经理, AI大事件:Anthropic改收费、OpenAI发安全版、手术机器人纳入医保、阿里发布”秒悟” – 人人都是产品经理, Chrome 推出 Skills 新功能,Agent 重塑上网方式 – 人人都是产品经理, GitHub前创始人拿了a16z的1700万美元,做Agent时代的Git – 人人都是产品经理 拷贝或克隆其他 Flutter OH 项目到本地后无法运行 – 人人都是产品经理, 优惠券设计:优惠券创建 – 人人都是产品经理, 不用死磕文档!AI 助手 1 小时搞定飞书 CLI 安装 + 配置 + 知识库 – 人人都是产品经理, 用小龙虾做竞品分析报告:从2天到20分钟,我是怎么做到的 – 人人都是产品经理 用小龙虾做市场分析报告:搞懂这3个公式,市场规模不再靠猜 – 人人都是产品经理, 你早就在做 Harness 工程,只是不知道它叫这个名字 – 人人都是产品经理, Think Long就够?你可能想多了! – 人人都是产品经理, 货代SRM实战:供应商准入怎么做,才能让资源池不是通讯录而是可交付网络? – 人人都是产品经理, 如何做好用户调研?详解基本技巧 – 人人都是产品经理, 木鸟、途家、美团对打,平台春天行动开“卷” – 人人都是产品经理, 入职才发现公司不靠谱?小红书从业者求职避坑指南 – 人人都是产品经理, 美国 AI 三巨头联手封堵,中国 AI 突围之路在何方 – 人人都是产品经理, 小红书,放在需求对面的镜子 – 人人都是产品经理, AI 会带来大规模失业吗? – 人人都是产品经理, 从出单到补货前,我第一次犹豫:该不该放大? – 人人都是产品经理, Flutter 三方库鸿蒙化适配:5 种高效检查方式,快速判断是否需要适配 – 人人都是产品经理, 从做产品进阶拿结果:医美机构产品经理转岗科室运营经理 – 人人都是产品经理, 阿里HappyHorse,一场关于“Token经济”的阳谋 – 人人都是产品经理, To B AI:客户留存落地的观察与思考 – 人人都是产品经理, AI产品的“生命线”——数据采集、标注、清洗的产品化设计 – 人人都是产品经理, 谈谈AI Agent(二):当“孩子”能自己“体验世界”时,你该学什么? – 人人都是产品经理, UI/UX设计师的3层能力进阶,前两层让你活下来,第三层…才是真正的分水岭 – 人人都是产品经理, 2分钟 → 30秒,效率提升75%:B端产品经理如何用「规则枷锁」驯服AI幻觉? – 人人都是产品经理, 还没来得及学OpenClaw,来了个更猛的:Hermes Agent – 人人都是产品经理, AI日报:宇树机器人跑出10m/s刷新世界纪录 – 人人都是产品经理, 一文说透基金互金如何用情绪价值引导用户决策做转化 – 人人都是产品经理, 当浏览器开始替你”看”网页:AI 浏览器正在亲手拆掉它脚下的那张网 – 人人都是产品经理, 0代码,一天时间我Vibe Coding了个网站 – 人人都是产品经理, Hermes 和 OpenClaw 之争,Agent 的能力应该“装上去”还是“长出来”? – 人人都是产品经理 视频生成的“桌子”,字节Seedance 2掀完,阿里快乐马掀 – 人人都是产品经理, 从听不懂到完全信任:我的 Codex 深度产品体验 – 人人都是产品经理, 当虚拟偶像有了北京户口,与真人偶像还有什么区别? – 人人都是产品经理, 会说,远远比会做更重要 —— 对 SBTI 爆火现象的五层观察 – 人人都是产品经理, AI产品经理必看:当“搭环境”比“选模型”更重要,你的认知还在2024年吗? – 人人都是产品经理, 2026年AI产品商业化核心逻辑:从功能demo到规模化营收的3个必破卡点 – 人人都是产品经理, 京东围绕供应链,卷起裤腿下场的那些事儿 – 人人都是产品经理, SBTI一夜刷屏:它赢在了“太会说人话” – 人人都是产品经理, 折扣零售的真相:不是便宜,而是价值感! – 人人都是产品经理, 和甲方吵了一架,最后加钱做了——我学到的ToB产品经理生存法则 – 人人都是产品经理, 和几位小红书操盘手聊了8小时,干货全在这 – 人人都是产品经理, 智谱GLM-5.1登场,开源模型首超Opus4.6!!! – 人人都是产品经理 Anthropic收入凭什么反超OpenAI,终于有人把这事说清楚了 – 人人都是产品经理, 史上最有故事感的技术报告——Claude最强模型Mythos 7个极其精彩的细节 – 人人都是产品经理, 模型不是壁垒,Harness 也不是 – 人人都是产品经理, 抖音本地生活业务思考21 – 人人都是产品经理, Superpowers:145k Star的AI编码框架,到底是什么来头? Superpowers:145k Star的AI编码框架,到底是什么来头? – 人人都是产品经理, OpenAI 的路走错了,Anthropic Harness 解法启示:模型需要实践专科生 – 人人都是产品经理, 画原型图的前一步:设计站点地图 – 人人都是产品经理, 给 DeepSeek 的最后一封催更信 – 人人都是产品经理, 手把手教你用 Claude Code 搭建 AI 营销团队:5 个 Agent、12 项技能,独立完成研究、写作、设计全流程 – 人人都是产品经理, 你以为大模型在学语言?不,它在重新发明语言学 – 人人都是产品经理 所谓Skill,不过是AI时代的工业垃圾 – 人人都是产品经理, 聊一聊内容传播的几个方法 – 人人都是产品经理, 当平台开始吃掉生态:从 OpenClaw 被封杀,读懂 Anthropic 的这盘棋 – 人人都是产品经理, 你装了 10 个 AI 插件,Obsidian 还是一个文件夹 – 人人都是产品经理 关于AI智能体架构演进的系统性思考:从单体试水到多体协同的重构 – 人人都是产品经理, 当“人”变成Skill,我们又该何去何从? – 人人都是产品经理 Mythos 事件:前沿 AI 治理的意外实验 – 人人都是产品经理, 货代CRM:信用与风险管理怎么做,才能把坏账风险拦在放货之前? – 人人都是产品经理, 从HR收集自拍照到员工自助录入——我见证了园区人脸识别从”不可用”到”真好用”的全过程 – 人人都是产品经理 千问闯关AI混沌期:阿里画靶,吴嘉张弓,马云射箭? – 人人都是产品经理,
双钻模型全方位解读与实战案例
南设 · 2024-08-02 · via 人人都是产品经理

我们在和设计师交流时,常会听说他们的“双钻模型”。这是一种设计师常用的设计方法论,这篇文章,我们和作者一起,跟着理论和案例的思路一起来学习一下。

一、双钻模型简介

双钻模型(Double Diamond Model)是由英国设计委员会(British Design Council)于2005年提出的。这一模型是用于描述设计过程的一种框架,它将设计过程分为四个阶段:发现(Discover)、定义(Define)、开发(Develop)和交付(Deliver)。

二、双钻模型的阶段

1)发现(Discover):

a. 目标:收集和研究大量信息,理解问题的全貌。

b. 方法:用户调研、市场分析、观察、访谈、数据收集。

c. 结果:广泛的洞察和灵感,为问题定义阶段提供基础。

2)定义(Define):

a. 目标:分析和综合发现阶段的信息,明确设计问题和机会。

b. 方法:数据分析、问题陈述、需求定义、设计准则制定。

c. 结果:一个清晰、具体的问题陈述和设计方向。

3)开发(Develop):

a. 目标:产生和发展解决方案的过程,探索各种可能的设计方案。

b. 方法:头脑风暴、概念设计、原型制作、用户测试、迭代。

c. 结果:多个初步解决方案和原型,为最终选择提供依据。

4)交付(Deliver):

a. 目标:验证和完善最终方案,准备产品的详细设计和生产。

b. 方法:详细设计、开发、测试、实施、发布。

c. 结果:一个成熟的解决方案,准备推向市场或交付给客户。

1. 发现(Discover)

在发现阶段,设计团队的主要任务是广泛收集信息,理解用户需求、市场趋势和问题领域。这一阶段注重探索和发散,旨在获取尽可能多的洞察和灵感,为后续阶段提供丰富的基础。

发现阶段需要做什么:

1)用户调研:

a. 访谈:与潜在用户进行一对一或小组访谈,了解他们的需求、期望、痛点和行为模式。

b. 问卷调查:通过结构化问卷收集大规模用户反馈,获取定量数据。

c. 观察:直接观察用户在自然环境中的行为,记录他们的操作方式和遇到的问题。

d. 用户旅程地图:绘制用户在使用产品或服务过程中的各个接触点,识别关键的用户体验。

2)市场分析:

a. 竞争分析:研究竞争对手的产品和服务,了解其优势和劣势。

b. 趋势分析:识别行业和市场中的最新趋势和技术发展,预测未来变化。

3)数据收集:

a. 文献研究:查阅相关的学术研究、行业报告和白皮书,获取背景信息和理论支持。

b. 数据挖掘:分析现有的数据资源,如用户反馈、支持请求、社交媒体评论等。

结果:

发现阶段的产出包括大量的用户洞察、问题陈述、机会识别以及设计灵感。这些信息将被用于定义阶段,以明确设计问题和机会。

案例:设计一款新的健康管理应用

背景:一家科技公司决定开发一款新的健康管理应用,旨在帮助用户更好地管理他们的健康数据和生活方式。

用户调研

(1)访谈:

a. 目标用户:20位年龄在25-45岁之间的潜在用户,涵盖不同的健康状况和生活方式。

b. 问题:了解他们目前如何管理健康数据,使用哪些工具,遇到的主要挑战是什么。

(2)问卷调查:

a. 规模:1000名目标用户,问卷内容包括健康管理习惯、对健康应用的期望、常见的使用场景等。

b. 结果:定量数据分析发现,70%的用户希望应用能提供个性化的健康建议,50%的用户认为当前的健康应用缺乏数据整合能力。

(3)观察:

a. 场景:观察用户在健身房、诊所和家中的健康管理行为,记录他们如何记录和分析健康数据。

b. 发现:大多数用户在健身房使用手动记录方式,而在家中则依赖多个设备和应用,导致数据分散和管理复杂。

市场分析

(1)竞争分析:

a. 竞品:研究当前市场上的主要健康应用,如MyFitnessPal、Fitbit、Apple Health等。

b. 分析:MyFitnessPal在饮食记录方面表现出色,但缺乏运动数据整合;Fitbit在运动数据追踪上有优势,但个性化建议不足。

(2)趋势分析:

a. 趋势:健康科技领域正朝着个性化和整合化发展,人工智能和机器学习在个性化健康建议中的应用越来越普遍。

b. 技术:可穿戴设备的数据整合和远程健康监测成为新的增长点。

数据收集

(1)文献研究:

a. 文献:查阅关于健康管理、行为改变和用户体验设计的相关研究,获取理论支持。

b. 发现:有效的健康管理应用需要兼顾用户动机和行为改变理论,提供即时反馈和鼓励。

(2)数据挖掘:

a. 来源:分析公司现有的用户反馈和支持请求,识别用户常见问题和需求。

b. 结果:用户普遍希望应用能提供更好的数据可视化和综合分析功能。

结果

通过发现阶段的调研和分析,设计团队收集了大量的用户需求和市场信息,明确了以下几个关键问题和机会:

1. 用户需要一个能够整合各种健康数据的平台。

2. 个性化健康建议是用户高度期望的功能。

3. 当前市场上的健康应用存在数据分散和管理复杂的问题。

这些洞察将指导下一阶段的定义和设计工作,确保新开发的健康管理应用能够真正满足用户需求并在市场中具有竞争力。

2. 定义(Define)

定义阶段的主要目标是将发现阶段收集的广泛信息进行分析和综合,明确设计问题、用户需求和机会。这一阶段的重点是收敛信息,以确定一个明确的设计方向,为后续的开发阶段提供指导。

定义阶段需要做什么:

1)数据分析:

a. 整理和分析发现阶段收集的信息和数据,识别关键趋势和模式。

b. 使用工具如Affinity Diagram(亲和图)、Personas(用户画像)和Customer Journey Maps(用户旅程图)进行信息整理。

2)问题陈述:

a. 将用户需求和痛点转化为具体的设计问题和挑战。

b. 使用工具如How Might We(HMW)问题框架,将发现的机会转化为设计问题。

3)需求定义:

a. 明确用户需求和功能需求,确定设计准则和约束条件。

b. 创建需求文档,列出所有必须满足的需求和优先级。

4)设计方向:

a. 确定设计策略和方向,制定设计目标和成功标准。

b. 使用工具如SWOT分析(Strengths, Weaknesses, Opportunities, Threats),评估设计策略的可行性。

结果:

定义阶段的产出包括清晰的问题陈述、用户需求、设计准则和明确的设计方向。这些成果为开发阶段的概念设计和原型制作提供了基础。

案例:设计一款新的健康管理应用

背景:一家科技公司在发现阶段通过用户调研、市场分析和数据收集,了解到用户需要一个能够整合各种健康数据的平台,并希望该平台能提供个性化的健康建议。现进入定义阶段。

数据分析

(1)整理信息:

a. 使用亲和图(Affinity Diagram)整理用户调研中的关键发现,分类和识别主题。

b. 通过用户画像(Personas)总结不同用户群体的特征和需求,如忙碌的专业人士、健身爱好者和慢性病患者。

(2)用户旅程图(Customer Journey Map):

a. 绘制用户旅程图,显示用户在健康管理过程中各个接触点的体验和痛点。

b. 识别关键的接触点,如数据记录、数据分析、个性化建议和行为反馈。

问题陈述

1. How Might We(HMW)问题框架:HMW问题:如何使用户能够轻松整合和管理他们的健康数据?如何为用户提供个性化的健康建议?

a. 这些问题将指导设计团队在开发阶段探索具体的解决方案。

需求定义

(1)用户需求:

a. 用户需要一个平台能够整合多种健康数据来源(如可穿戴设备、手动输入、医疗记录等)。

b. 用户希望平台能提供个性化的健康建议,基于他们的健康数据和目标。

(2)功能需求:

a. 数据整合功能:支持多种数据来源的同步和管理。

b. 数据分析功能:提供清晰的健康数据可视化和分析报告。

c. 个性化建议:基于用户数据和目标,提供个性化的健康建议和计划。

(3)设计准则:

a. 界面简洁易用,符合用户的认知习惯。

b. 提供及时的反馈和鼓励,帮助用户保持积极的健康管理行为。

c. 确保数据隐私和安全,建立用户信任。

设计方向

(1)设计策略:

a. 采用模块化设计,允许用户根据自己的需求自定义平台功能。

b. 使用机器学习和人工智能技术,实现个性化建议和预测分析。

(2)成功标准:

a. 用户满意度和使用率:通过用户反馈和使用数据评估平台的用户体验。

b. 健康目标达成率:衡量用户在使用平台后的健康改善情况。

c. 数据安全性:确保用户数据的安全和隐私保护。

结果

定义阶段的结果包括:

1. 清晰的问题陈述:如何使用户能够轻松整合和管理他们的健康数据?如何为用户提供个性化的健康建议?

2. 用户需求和功能需求文档,列出整合数据、数据分析和个性化建议等关键功能。

3. 设计准则和策略,确保界面简洁易用,提供及时反馈,并保障数据隐私和安全。

4. 明确的设计方向和成功标准,为开发阶段的概念设计和原型制作提供指导。

通过定义阶段的工作,设计团队可以将广泛的信息和洞察转化为具体的设计要求和策略,为后续的开发和交付阶段奠定坚实的基础。

3. 开发(Develop)

在开发阶段,设计团队的主要任务是产生和发展解决方案,探索各种可能的设计方案并进行验证和迭代。这一阶段的重点是创造性和实验性,旨在将定义阶段明确的问题转化为可行的设计解决方案。

开发阶段需要做什么:

1)头脑风暴:

a. 目标:产生大量创意和概念。

b. 方法:团队成员自由发言,记录所有想法,不进行评判和筛选。

2)概念设计:

a. 目标:将头脑风暴产生的创意转化为具体的设计方案。

b. 方法:绘制草图、创建故事板、编写用例场景。

3)原型制作:

a. 目标:创建初步的设计原型,以便进行测试和验证。

b. 方法:使用低保真和高保真原型工具,如纸质原型、Axure、Sketch、Figma等。

4)用户测试:

a. 目标:通过用户测试验证设计方案,收集用户反馈并进行迭代。

b. 方法:可用性测试、A/B测试、用户访谈等。

5)迭代改进:

a. 目标:根据用户测试反馈不断改进设计方案。

b. 方法:调整和优化原型,进行多轮测试和验证。

结果:

开发阶段的产出包括多个初步解决方案和原型,经过反复的测试和迭代,最终确定一个成熟的设计方案,为交付阶段的详细设计和实现提供基础。

案例:设计一款新的健康管理应用

背景:一家科技公司在定义阶段明确了用户需求和设计方向,现在进入开发阶段,目标是探索和验证各种设计方案,以创建一个能够整合健康数据并提供个性化建议的健康管理应用。

头脑风暴

1. 创意产生:团队成员通过头脑风暴会议,提出了多种创意,例如:用户仪表板:提供整合所有健康数据的仪表板。

i. 个性化建议模块:基于用户数据和目标提供个性化的健康建议。

ii. 社交功能:允许用户与朋友和家人分享健康进展。

概念设计

(1)草图绘制:

a. 团队成员绘制了各个功能模块的草图,包括用户仪表板、数据输入界面、建议页面等。

(2)故事板:

a. 创建了用户使用应用的故事板,展示用户从登录到获取健康建议的完整流程。

(3)用例场景:

a. 编写了多个用例场景,如用户如何记录饮食、查看每日步数、接收健康建议等。

原型制作

(1)低保真原型:

a. 使用纸质原型和Sketch创建了低保真原型,展示基本界面布局和交互流程。

(2)高保真设计稿:

a. 使用Figma创建了高保真设计稿,展示详细的界面设计和交互细节。

用户测试

(1)可用性测试:

a. 招募10位目标用户进行可用性测试,观察他们使用原型的过程,记录他们的操作和反馈。

b. 发现:部分用户在数据输入界面遇到困难,需要简化输入流程。

(2)A/B测试:

a. 创建了两个不同版本的个性化建议页面,进行A/B测试,比较用户对不同设计的偏好。

b. 结果:用户更喜欢简洁的建议页面,提供明确的行动步骤。

(3)用户访谈:

a. 进行深度用户访谈,了解用户对原型的整体体验和改进建议。

b. 反馈:用户希望增加数据导入功能,能够从其他健康应用和设备同步数据。

迭代改进

(1)调整和优化原型:

a. 根据用户测试和访谈反馈,优化数据输入界面,简化操作流程。

b. 增加数据导入功能,允许用户从其他应用和设备同步数据。

(2)多轮测试和验证:

a. 进行第二轮和第三轮可用性测试,验证改进后的原型是否满足用户需求。

b. 结果:用户体验显著提升,满意度提高,操作更加顺畅。

结果

开发阶段的结果包括:

1. 详细的概念设计和用例场景,展示用户使用应用的完整流程。

2. 低保真和高保真原型,展示各个功能模块的界面设计和交互细节。

3. 多轮用户测试和迭代改进,确保设计方案能够满足用户需求和期望。

4. 一个成熟的设计方案,为交付阶段的详细设计和实现提供基础。

通过开发阶段的工作,设计团队能够验证和优化设计方案,确保最终的健康管理应用既符合用户需求,又具有良好的用户体验。

4. 交付(Deliver)

在交付阶段,设计团队的任务是验证和完善最终方案,进行详细设计、开发和测试,并将产品推向市场或交付给客户。这一阶段的重点是实现设计方案,确保其可用性和可行性,最终满足用户需求。

交付阶段需要做什么:

(1)详细设计:

a. 目标:将高保真原型转化为详细的设计规范,包括界面设计、交互细节和视觉元素。

b. 方法:创建设计规范文档,使用工具如Sketch、Figma等。

(2)开发和实现:

a. 目标:将设计方案转化为实际的产品,进行前端和后端开发。

b. 方法:使用编程语言和框架,如HTML/CSS、JavaScript、React、Node.js等,进行代码开发和实现。

(3)测试和验证:

a. 目标:通过多轮测试确保产品的功能和用户体验,修复BUG并进行性能优化。

b. 方法:单元测试、集成测试、用户验收测试(UAT)、A/B测试等。

(4)发布和部署:

a. 目标:将产品发布到市场,进行部署和上线,确保产品能够正常运行并满足用户需求。

b. 方法:选择合适的发布平台(如App Store、Google Play),进行发布和推广。

(5)用户反馈和改进:

a. 目标:收集用户反馈,进行产品的持续改进和优化。

b. 方法:用户调查、使用数据分析、版本更新等。

结果:

交付阶段的产出包括详细的设计规范、实现的产品、测试报告、上线的产品以及用户反馈和改进计划。

案例:设计一款新的健康管理应用

背景:一家科技公司在开发阶段确定了健康管理应用的成熟设计方案,现在进入交付阶段,目标是实现设计方案并将应用推向市场。

设计详情

(1)设计规范文档:

a. 创建详细的设计规范文档,包括界面布局、色彩方案、字体选择、图标和交互细节。

b. 确保所有设计元素的一致性,提供开发团队参考。

(2)设计工具:

a. 使用Figma制作高保真的界面设计和交互细节。

b. 制作设计交互原型,确保开发团队清晰了解设计意图。

开发和实现

(1)前端开发:

a. 使用React框架进行前端开发,创建用户界面和交互逻辑。

b. 编写CSS和JavaScript代码,实现设计规范中的视觉和交互效果。

(2)后端开发:

a. 使用Node.js和Express进行后端开发,构建服务器和数据库。

b. 实现数据同步和存储功能,确保用户数据的安全和可靠。

(3)集成开发:

a. 前端和后端开发团队紧密合作,进行接口集成和功能实现。

b. 确保前后端数据通信的准确性和实时性。

测试和验证

(1)单元测试:

a. 对各个功能模块进行单元测试,确保每个功能正常运行。

b. 使用Jest或Mocha等测试框架编写和运行测试用例。

(2)集成测试:

a. 对系统整体进行集成测试,确保各个模块之间的协同工作。

b. 发现并修复集成过程中出现的BUG和问题。

(3)用户验收测试(UAT):

a. 邀请目标用户进行用户验收测试,收集用户的使用反馈。

b. 根据用户反馈进行最后的调整和优化。

(4)性能优化:

a. 进行性能测试和优化,确保应用在各种设备上的运行速度和稳定性。

b. 使用工具如Lighthouse、WebPageTest进行性能分析和优化。

发布和部署

(1)发布平台选择:

a. 选择合适的发布平台,如App Store和Google Play。

b. 准备发布所需的材料,如应用描述、截图、宣传视频等。

(2)发布和推广:

a. 将应用发布到各大平台,进行推广和宣传。

b. 通过社交媒体、广告、合作等方式吸引用户下载和使用。

(3)监控和维护:

a. 监控应用的运行情况,确保服务器和服务的稳定性。

b. 提供用户支持和问题解决,及时发布更新和修复补丁。

用户反馈和改进

(1)用户调查:

a. 通过问卷调查、用户访谈等方式收集用户反馈。

b. 了解用户的使用体验、满意度和改进建议。

(2)使用数据分析:

a. 分析用户行为数据,了解用户的使用习惯和需求变化。

b. 使用工具如Google Analytics、Mixpanel进行数据分析。

(3)版本更新:

a. 根据用户反馈和数据分析,进行持续的改进和优化。

b. 定期发布版本更新,添加新功能、修复BUG和优化性能。

4. 结果

交付阶段的结果包括:

1. 详细的设计规范:确保设计的一致性和可实现性。

2. 实现的产品:健康管理应用的完整实现,包括前端和后端功能。

3. 测试报告:详细记录测试过程、发现的问题和解决方案。

4. 上线的产品:应用在App Store和Google Play成功上线,用户可以下载和使用。

5. 用户反馈和改进计划:收集用户反馈,进行持续的改进和优化,确保产品的长期成功。

通过交付阶段的工作,设计团队能够将健康管理应用成功推向市场,满足用户需求,并通过持续的改进和优化,保持产品的竞争力和用户满意度。

三、双钻模型生活的应用

双钻模型除了可以用在设计项目中,也可以延展到生活中例如:计划一次大型家庭聚会

1. 发现阶段(Discover)

目标:了解所有家庭成员的需求和期望,收集相关信息和灵感。

1. 家庭成员访谈:

a. 进行一对一或小组访谈,了解家庭成员的期望、喜好和特殊需求。

b. 问题示例:你希望在聚会上看到哪些活动?你对聚会地点有什么建议?有没有特别的饮食要求?

2. 历史数据回顾:

a. 回顾以往家庭聚会的反馈,总结成功之处和需要改进的地方。

b. 发现:之前的聚会中,户外活动受到大家的欢迎,而餐饮服务需要改进。

3. 灵感收集:

a. 搜索网上的聚会策划案例和灵感,获取创意和新颖的活动点子。

b. 结果:找到一些有趣的游戏和活动,如家庭问答、烧烤聚餐、DIY工坊等。

结果:

获取大量的家庭成员需求、期望和灵感,为后续阶段提供基础。

2. 定义阶段(Define)

目标:分析和综合发现阶段的信息,明确聚会的具体需求和目标。

1. 数据分析:

a. 整理和分析收集到的信息,识别关键需求和共性。

b. 发现:大多数家庭成员希望有一个户外的聚会场所,有丰富的活动安排,并且有素食和非素食选项。

2. 问题陈述:

a. 将家庭成员的需求转化为具体的问题陈述。

b. 示例:如何找到一个适合户外活动的聚会地点?如何确保所有家庭成员的饮食需求得到满足?如何安排丰富多彩的活动?

3. 需求定义:

a. 明确聚会的具体需求和设计准则。

b. 示例:需要一个户外场地,有足够的空间供50人活动。餐饮需要提供素食和非素食选项。活动安排包括烧烤、游戏和DIY工坊。

结果:

一个清晰、具体的问题陈述和聚会规划方向。

3. 开发阶段(Develop)

目标:产生和发展聚会方案,探索各种可能的安排并进行验证和迭代。

1. 头脑风暴:

a. 与家人或朋友一起进行头脑风暴,提出各种创意和方案。

b. 创意示例:不同的聚会场地选择、各种活动安排、不同的餐饮方案等。

2. 概念设计:

a. 将头脑风暴产生的创意转化为具体的聚会方案。

b. 示例:选择了一个乡村农场作为聚会场地,活动安排包括烧烤、家庭问答、户外运动和DIY工坊。

3. 原型制作:

a. 创建聚会的初步计划和日程安排。

b. 示例:制定详细的时间表,包括活动开始和结束的时间、餐饮安排等。

4. 用户测试:

a. 与核心家庭成员讨论初步计划,收集反馈并进行调整。

b. 结果:大家对农场场地表示满意,但建议增加一些儿童友好活动。

5. 迭代改进:

a. 根据反馈进行调整和优化,形成最终的聚会方案。

b. 示例:增加了儿童区和适合孩子的游戏活动。

结果:

一个成熟的聚会方案,准备进行最终实施。

3. 交付阶段(Deliver)

目标:验证和完善最终方案,进行详细的准备和执行,确保聚会顺利进行。

1. 详细设计:

a. 制定详细的聚会安排和任务分配。

b. 示例:确定活动负责人,安排场地布置、餐饮准备、活动执行等具体任务。

2. 准备和执行:

a. 进行所有必要的准备工作,如预订场地、采购物品、联系餐饮服务等。

b. 示例:预订农场场地,采购烧烤食材和活动所需物品,联系餐饮供应商。

3. 测试和验证:

a. 在聚会前进行一次预演或检查,确保所有准备工作就绪。

b. 示例:核对活动安排,确保所有物品和设备齐全,检查场地布置。

4. 聚会当天执行:

a. 按照计划进行聚会活动,确保各项安排顺利进行。

b. 示例:按照时间表进行活动,引导家庭成员参与,确保餐饮服务及时到位。

5. 用户反馈和改进:

a. 在聚会结束后收集家庭成员的反馈,总结经验和改进建议。

b. 示例:通过问卷或访谈了解大家的满意度,记录成功之处和需要改进的地方。

结果:

一次成功的家庭聚会,家庭成员都享受了愉快的时光,并收集到宝贵的反馈,为未来的聚会提供参考。

四、双钻模型总结

1. 双钻模型优势

1. 结构化的流程:

a. 双钻模型通过明确的四个阶段(发现、定义、开发、交付)提供了一个结构化的流程,使设计过程更加有序和系统化。

2. 鼓励广泛探索和聚焦解决方案:

a. 通过“发散-收敛-发散-收敛”的过程,双钻模型鼓励设计团队在初始阶段广泛探索所有可能性,然后逐步聚焦和精炼解决方案,确保最终方案的高质量。

3. 用户中心设计:

a. 模型强调用户需求和问题的发现与定义,确保设计过程始终以用户为中心,最终交付满足用户需求的解决方案。

4. 迭代和改进:

a. 在开发阶段,双钻模型提倡多次迭代,通过不断的测试和用户反馈,持续改进设计方案,提高最终产品的质量和用户体验。

5. 跨团队协作:

a. 通过明确的阶段和目标,双钻模型促进跨职能团队的协作,使不同专业的团队成员能够在设计过程中的各个阶段共同工作,提高项目的整体效率。

2. 双钻模型的不足

1. 时间和资源消耗较大:

a. 双钻模型的四个阶段需要投入大量的时间和资源,特别是在发现和开发阶段,广泛的探索和反复的迭代可能会延长项目周期。

2. 复杂性管理:

a. 对于较小规模或简单的项目,双钻模型的复杂性可能显得过于繁琐,不适合资源有限或时间紧迫的情况。

3. 不确定性管理:

a. 在发现阶段的广泛探索和开发阶段的多次迭代中,可能会遇到较高的不确定性和风险,需要有效的管理策略来控制项目进度和预算。

4. 团队协调难度:

a. 由于涉及多个阶段和跨职能团队的协作,团队之间的沟通和协调可能会面临挑战,特别是在项目规模较大或团队分散的情况下。

5. 依赖用户反馈:

a. 双钻模型强调用户反馈和测试,但在某些情况下,获取真实和有效的用户反馈可能会有难度,影响设计方案的迭代和改进。

五、结论

双钻模型作为一种结构化的设计方法论,具有显著的优势,包括提供结构化流程、鼓励广泛探索和聚焦解决方案、强调用户中心设计、支持迭代和改进以及促进跨团队协作。然而,其不足也不容忽视,如时间和资源消耗较大、复杂性管理挑战、不确定性管理需求高、团队协调难度以及对用户反馈的依赖。根据项目的规模、复杂性和资源情况,设计团队需要权衡双钻模型的优势和不足,灵活应用,以实现最佳的设计效果。

专栏作家

南设,公众号:南设(ID:NANSHE18),人人都是产品经理专栏作家。专注设计,逻辑性强,注重体验。分享体验设计、人工智能开发等。

本文原创发布于人人都是产品经理,未经许可,禁止转载。

题图来自 Unsplash,基于 CC0 协议

该文观点仅代表作者本人,人人都是产品经理平台仅提供信息存储空间服务。