软件工程之美
宝玉
Groupon 资深工程师,微软最有价值专家
44272 人已学习
新⼈⾸单¥59
登录后,你可以任选4讲全文学习
课程目录
已完结/共 55 讲
软件工程之美
15
15
1.0x
00:00/00:00
登录|注册

18 | 原型设计:如何用最小的代价完成产品特性?

对原型设计的看法
在项目中使用原型设计工具的情况
设计iPad原型的想法
推广应用原型设计的建议
做好原型设计的方法
原型设计工具的选择
原型设计的演变历史
成本
功能
保真度
面向的平台
验证阶段
实施阶段
设计阶段
分析阶段
低保真、中等保真、高保真原型设计
快速原型模型的提出
早期的原型设计
原型设计作为需求确认和产品设计的沟通工具
需求不明确、需求变更的问题
课后思考
总结
如何选择合适的原型设计工具
如何做好原型设计
原型设计的发展历史
原型设计的重要性
原型设计

该思维导图由 AI 生成,仅供参考

你好,我是宝玉,我今天想与你分享的主题是“原型设计”。
我们都知道,软件项目中很多问题都和需求相关,比如说需求不明确,需求变更。这些问题轻则导致返工造成浪费,重则导致项目失败带来巨大损失。所以在软件工程中,搞明白需求是一件至关重要的事。
上一篇我带你学习了如何分析需求的方法,而分析需求,同样也离不开工具的支持。所以这一篇,我将带你学习需求分析中原型设计的用法,借助原型设计,用最小的代价完成产品特性。

什么是原型设计?

对于原型设计,很多程序员可能比较陌生,但是对于产品经理来说,原型设计却是日常工作中最常用的技能之一。因为原型设计,是产品经理确认需求、设计产品最重要的沟通工具。
其实最早的原型设计,并不是作为一个需求沟通工具存在的。

原型设计的发展历史

早在上世纪 70 年代,在瀑布模型提出后,很大程度上改进了软件项目的开发。但是需求不明确、需求多变的问题从那时候开始就是一大难题。
《人月神话》的作者弗雷德里克·布鲁克斯(Frederick P. Brooks, Jr.)在《没有银弹 - 软件工程中的根本和次要问题》中第一次提出了:“在获取和制订软件需求时,将快速原型开发作为迭代计划的一部分”。
后来快速原型就逐步发展成为一个开发模型,叫快速原型模型,我在《04 | 瀑布模型之外,还有哪些开发模型?》这一篇里也有介绍。这种模型的特点就是快速开发,快速修改。目的是为了解决客户的需求不明确和需求多变的问题。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

原型设计在软件工程中扮演着至关重要的角色,它是产品经理确认需求、设计产品最重要的沟通工具。本文从原型设计的发展历史出发,介绍了低保真、中等保真和高保真原型设计的特点和应用场景。随着移动端的快速发展,对于原型的保真度要求也越来越高。文章提到了如何做好原型设计,借鉴工程方法,将原型设计过程分成四个部分:分析、设计、实施和验证。最后,以极客时间App为例,说明了如何在实际项目中进行原型设计。整体而言,本文通过详细的发展历史和实际案例,全面介绍了原型设计的重要性和实践方法。文章还介绍了如何选择合适的原型设计工具,并提供了几款主要的原型设计工具供读者参考。通过分析、设计、实施和验证这四个阶段,再反复的修改和确认几遍,基本上就可以做出不错的原型设计。文章以技术特点为主线,深入浅出地介绍了原型设计的重要性和实践方法,对读者快速了解原型设计提供了有益的指导。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《软件工程之美》
新⼈⾸单¥59
立即购买
登录 后留言

全部留言(14)

  • 最新
  • 精选
  • hua168
    老师,问一个很low的问题, 1.什么是模块呀?😢 经常看到书中或开发说,自己感觉懂好像又不懂😂, 一个类也是模块,但不懂为什么就是模块😓 2.模块有哪些分类?一般说的模块是业务模块? 3.模块间“高内聚低耦合”,像口诀那样,会背,但毫无概念,只知道模块尽量独立,那如果模块之间要进行通讯是不是用接口实现?如果有依赖关系越多的话的话那不是独立性越差?要实现“高内聚低耦合”,如果复杂一点的项目有难度吧?

    作者回复: 你说的这个话题其实属于架构下面的。 在技术里面,模块其实是对某一种类型需求的抽象。举个例子来说,一个博客系统,博客的帖子是一个模块,评论是一个模块,用户是一个模块,帖子和评论又可以进一步抽象成内容模块。 模块的分类看你是从架构层面看还是从业务层面看。比如说从架构层面看,一个普通的博客网站可以看成三层:UI层、业务逻辑层和数据访问层。其中UI层包含帖子列表模块和博客文章阅读模块;业务逻辑层则是帖子业务模块、用户业务模块。 如果从业务层面看,包含博客阅读模块和后台模块,更偏向功能的分类。 高内聚低耦合是架构里面的概念。因为架构设计,需要把大的系统拆分成小的模块,拆分后,还要通过约定的协议通信。典型的有前后端分离然后通过REST API通信,还有像类库之间直接通过公开的方法调用。 低耦合意思是项目没有什么依赖,改动互相不受影响。比如说前端和后端之间通过API通信,只要API不变,无论你后端用什么语言,跟前端都没关系。 高内聚指的是一个模块都是关系很紧密的代码,比如用户模块,所有用户操作的功能都在用户模块里面,关系紧密,也不需要依赖于其他模块。

    2019-04-08
    19
  • 打工皇帝
    老师,我遇到一个变态领导,经常原型啥的确认了,视觉稿也确认了,开发出来后,他自己电脑看哪里不舒服又改,看到别人家哪里好看又要求改,需求一直变更,这种鸟不拉屎的人怎么处理,实在无奈。

    作者回复: 视觉这种东西主观性太强,每个人都觉得懂一点,所以一般领导都喜欢发表意见。所以遇到喜欢发表意见的领导,不妨让领导有机会参与设计,对设计稿多确认,从粗到细,先确认大风格,再确认配色风格,再到局部细节。这样最后提出设计修改的可能要小一点。 但要注意在确认的方法上,多让领导做选择题,而不是问答题。因为当你问的开放式的问题,那么你就可能得到不确定的答案,但是如果是在几种方案之间的选择,那么对于结果会更容易可控一些。比如说,你问领导:“这套设计方案怎么样?”他可能会提出一些不太可控的意见。如果你准备两三套设计方案,问领导:“你觉得这几套方案哪一套更好”,那么可能问题就集中在选择哪一套设计方案上。 对于需求变更的问题可以参考 《20 | 如何应对让人头疼的需求变更问题?》里面的描述,核心是是要让领导意识到变更带来的成本,以及想办法提升领导变更的成本。 当然如果你确定不是你自己的问题,确实是领导的问题,也无法改善,你也可以考虑换一个项目组换一个部门甚至换一个公司。

    2019-10-16
    9
  • javaadu
    写代码这么多年,最欠缺的就是自己从零到一完成一个项目的经验。现在发现如果让这种情况持续下去会影响自己将来的发展前景。 最近遇到一个问题:业务方的接入效率不高,我们组一直需要提供一个开发去支持,人效态太低。为了解决这个问题,我准备出一套自助接入系统,想了下主要的步骤:业务问题分析,对于接入来说就是总结固定的接入;出解决方案(这里需要自己去画原型);项目排期和需要的资源估计。 如果可以解决这个问题,相信可以锻炼自己身体整体素质。

    作者回复: 这种和业务接口的事很锻炼人的,能帮助开发人员换位思考,多了解业务需求、使用场景。 一开始不着急出接入系统,可以先人工做一段,然后在总结归纳,把能自动化的部分逐步用自动化解决。 另外这类事情,一定要配合Ticket跟踪系统,所有提的需求、反馈的bug,都应该基于Ticket跟踪起来。

    2019-04-06
    6
  • 易林林
    宝玉老师,文章太有用了,感谢! 每一期的专栏,要么能加深自己对某一方面的认识,要么能补充自己某一方面的新知识。 一直以来,潜意识里产品设计都是产品部门的活儿,我一研发部门的怎么能插得上手,手太长也不太好看。在产品没有明确设计完成、设计周期比较长的时候,等待是惬意的(不忙,不加班),也是焦虑的(暴风雨在后头),只能干瞪眼。 原型设计我也曾经玩过,不过玩得太浅,没玩到精髓,草草开始,草草结束,不太重视。今天看到宝玉老师对原型设计的讲解,补充了我所不了解的原型设计的优势:最小代价、最快速度,如果能保证高质量当然也是乐见其成的。 另外,我想请教宝玉老师,在敏捷开发中产品部门怎样参与产品设计会更好,或者以什么方式参与会更好?

    作者回复: 首先你问的是产品部门参与产品设计,还是开发部门? 首先从技术角度,好的产品设计要让产品设计在技术上实现不要成本太高,所以在一些技术难度高的设计上两边要多沟通确认,共同制定出技术难度适中,又满足好产品需求的设计。 然后从产品角度,开发必须充分理解产品设计才能设计出符合产品需求的架构,才能开发出满足需求和好的用户体验的产品。所以开发需要多和产品设计反复沟通需求,然后将确认后结果体现在文档上。 至于参与方式,主要还是看什么形式比较好。 比如可以安排需求评审,关键节点让主要开发人员参与确认技术可行性和成本以及建议。 比如有分批次的需求讲解会议想开发讲解产品设计,回答理解不清楚的问题。 每个Sprint产品经理都要参与其中,及时和开发沟通确认需求不明确的问题!

    2019-04-08
    3
  • alva_xu
    我的理解,实际上原型设计是一个完整的工作环,所以是遵循PDCA过程的。采用Axure Pro进行原型设计,据说可以在正式进行产品开发的时候可以重用代码。 我的一个问题是,在目前前后端分离、Restful 风格的应用架构下,是否更容易实现原型设计时的代码的重用率,以提高开发速度?具体是怎么做的?

    作者回复: 以前在讨论开发模型的时候有介绍,快速原型开发模型有两种模式,一种是抛弃型的,就是用工具开发的这种;一种是演化型原型,就是类似于MVP,先做简单核心功能,然后不断演化,变成最终产品。 如果你要提升代码的重复率和开发速度,这种前后端分离的呀,我给你的建议是你用一些第三方API云服务: https://www.apollographql.com/ https://firebase.google.com/products/firestore/ 这样你就完全不用考虑后端开发了,直接用它们定制就好了。等到产品开发出来,你再考虑后端迁移。

    2019-04-10
    2
  • tcny
    流程图是不是可以用原型设计工具代替,比如可以在墨刀里实现页面跳转功能。不过墨刀没有版本管理,不知道是不是必要的。我感觉很难说服其他人去画流程图。

    作者回复: 流程图是辅助的,可以被原型设计代替,但是有了会更清晰。 这就像你的代码,看代码也能看懂 ,有个模块关系图,别人看会清晰很多

    2019-06-21
    1
  • tcny
    老师,在“产品信息结构图”那一块,您说极客时间App的“专栏”、“视频课程”、“每日一课”和“微课”点进去都是一样的,是指结构一样吗?在实现的时候,其实是划分到统一的“课程模块”,“专栏”、“视频课程”等是作为一个分类存在的,在数据库中就是一个字段。我从研发的角度是这样想,产品经理也要考虑这些吗?

    作者回复: 产品经理也会考虑信息架构,但是和开发的纬度不一样,开发是站在用户使用功能的角度,做信息架构时需要考虑哪些功能是不同模块共用的。而开发是站在实现的角度,看怎么实现可以重用代码。 只是有时候正好两个不同维度的结果可能是重叠的。

    2019-06-21
    1
  • williamcai
    开发人员接到需求后,先设计低保真产品原型可以加深业务的理解,这个是很有必要的,产品站的角度要要比开发高。

    作者回复: 我觉得对于开发人员来说,设计原型是帮助理解需求的手段,并不是必要手段。只要能理解清楚需求,通过和产品经理多沟通,达到理解需求的目的即可。 但对于产品经理来说,产品原型是很有必要的,因为这是最简单有效的确认需求的方式,最简单有效的让其他人理解产品设计的方式。

    2019-04-13
    1
  • hua168
    老师,能否问一下: 1. 什么是模块? 2. 有多少分类呀? 3. 要实现“高内聚低耦合”,模块之间的通讯要注意哪些?

    作者回复: 已经在另一篇留言回复

    2019-04-09
    1
  • 一路向北
    原型设计也是属于磨刀不误砍柴工。 记得早期我们团队做第一个项目的时候,一个同事用这个原型设计的方式做了一个原型,和客户沟通后,稍作修改就成了最终做出的样子,大大提高了效率。客户也很容易就能够想象出产品最终的样子,甚至还能时不时的提一些建议。

    作者回复: 👍是的,原型设计对于产品设计阶段的作用蛮重要的。

    2019-04-10
收起评论
显示
设置
留言
14
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部