产品需求分析：从用户到需求文档的历练（2）
确定产品定位之后，然后通过不同的方式来收集大量的需求，然后根据这些需求的有效性和真实性、产品定位和项目资源情况进行筛选和匹配，提炼出产品需求，定义出优先级。从产品定位到需求优先级，整个过程不仅涉及对用户的分析和理解，还包括了对产品定位、项目资源的考虑。
需求来源可以大致分为以下几种，其中竞品分析、产品数据、用研是从产品层提出，老板敏锐的眼光则是&人为&思考的结果。
通过五花八门的渠道收集到一堆需求之后，不可能全部都能做，需要按照一定规则和流程，筛选出来最有价值的需求，将有限的投入产出最大化。
其中有一个较重要的环节，也是考验PM能力的地方，透过现象看本质，挖掘用户的真实需求（有个经典的故事：汽车之父亨利&福特曾有一个经典的句子：&如果我问客户他们想要什么，他们总是说想要更快的马。
这里谨记两条：
倾听用户不等于听从用户
用户想要什么不等于真实需求
经历完需求筛选和优先级定义之后，通常可以得到需求列表，负责各个功能的产品经理就可以领任务去写PRD了（对于一般更新迭代的需求，可能筛选完之后只有一两条需求，优先级都不需要定义，就可以直接开写了）。
下面是标准需求文档的内容示例：
① 文档备案：包括文档日期、版本号、修改人、修改内容和审核人等信息，一般以表格形式位于文档开头。
② 目录：方便阅读
③ 背景描述：为什么要做这个产品/模块，市场行情，业务目标，产品定位等
④ 用户类型：简单地描述目标用户的情况
⑤ 项目时间安排：启动、结束等时间节点
⑥ 信息结构：简单理解为内容和页面的层级
⑦ 业务流程说明：以流程图形式说明业务各个状态间的切换逻辑（例如：游戏服务器满人时候需要切换到排队登录状态）
⑧ 需求详细说明：每一条需求的详细说明（包括：使用场景、UI描述、功能描述、优先级、输入/输出条件、处理流程、补充说明等）
⑨ 涉及关联业务部门的支持，还需要特别备忘。
如同设计稿，代码一样，需求文档很难一次成型，需要不断修改，在评审中发现问题是很正常的。
需求分析广义上看包括了需求获取和分析筛选两个方面。产品定位是确定产品需求的根本依据，而目标用户则是产品定位的标尺。要想得到正确的需求，PM需要全程参与，充分准备，深入到各个关节中，并且充分听取不同成员的意见。
上述方法论是标准化流程，实战运用，不同公司不同项目会有更接地气的一套过程，本文谨对新人作分享和启发之用。需求文档的撰写同理，引用在京东实习时候，曾经就PRD模版和导师有关一些讨论，最后导师给出的意见是：根据需求和进度来灵活变通，切勿迷恋所谓模版。尤其移动互联网时代。仅以此话与诸君分享。
文章内容提炼于刘津老师和李月老师的《用户体验设计师的成长之路》，力荐阅读原作，之后会出系列读书笔记，围绕用户体验设计相关话题而谈。
看过本文的人还看过
最新图文推荐
最新专栏文章
大家感兴趣的内容
网友热评的文章如果让你把下面这套技术体系串联起来，从零开始构建一个技术平台，你如何做需求分析呢？要点就是顺着 场景——&故事——&信息架构——&业务流程——&版本以及版本包含的功能点捋。
郑昀 创建于 最后更新于
关键词：技术预研课题，平台设计，应用场景，故事，信息架构，业务流程，数据流程
本文档适用人员：全体研发
如何从零开始搭建一个技术平台？
应用场景其实就是我们的愿景
从应用场景推导出故事
从故事推导出信息架构和业务流程
一，如何从零开始？
如果让你把下面这套技术体系串联起来，从零开始构建一个技术平台，你如何做需求分析呢，在没有产品经理帮助你梳理的情况下？
下面这些系统涵盖了我们研发测试运维日常工作的方方面面：
idCenter：它定义用户、用户组、权限。研发测试都有了唯一的身份和权限集合，贯穿所有系统。
iDB：数据库自动化运维系统能把数据库建帐号、授予权限、建表、改表结构、刷库这些日常操作都变成流程，DBA审核通过后就可以自动执行，以及自动回滚。
Touchstone：容器私有云的管理控制台，管理镜像库、应用、容器、主机等。日常发布就在这里做。
JobCenter：定时任务调度和管理。
Summoner：大型计算任务的调度和管理。云纵佣金计算就是在这上面跑的。
Notify：异步消息可靠推送。所有的异步消息都走这个中间件。
Discache：管理memcached和redis。
OAP：运维自动化系统。主要是资产管理、资源管理和发布。
Secret：天机和鹰眼。数据库、Java、PHP、业务指标，监控报警都做进来了。
你就是一个说故事的人，为了保证大家对故事的理解没有偏差，所以大家『都希望你说得具体点儿（User Story），把故事落实在产品的需求点（Product Backlog），然后在这些需求点里面排出优先级（Sprint Backlog），然后排出版本（Version），这样兄弟们做开发和不断燃烧（Burn Up）』。[注1]
先有场景， \
再有故事， \
通过故事拆解出信息架构，即菜单结构和功能点， \
最后归入某个版本， \
在所有的故事、功能点和版本都确定之后，我们就进入不断的排序优先级和循环的过程。
二，何谓应用场景？
大家也许会注意到，当我发起技术预研课题时，我通常都会给出我想象中的、心目中这个课题的愿景，以一个目标用户是如何使用这个平台的应用场景的方式。
本地生活服务商户“魔镜”计划
为公司分销、共创和运营的决策提供门店数据支撑，提供（自助）可视化数据和自助数据查询能力
应用场景举例：
开站决策支持：哪些城市值得开站，哪些不值得？
背后的数据支撑：
开展过互联网营销服务并且经营得尚可的门店清单以及销售情况
餐饮和美业品类下，优先向哪些商户推纵横客？
背后的数据支撑：
门店的地址电话，用户活跃度，门店星级，团购和外卖商品数，折扣领取次数等
这就是愿景和场景。
我们对于上游业务部门流转过来的需求，也必须熟练运用下面这种逆推能力：
先构造出合乎逻辑的多种应用场景，然后回头审视自己的概念设计、功能设计、信息架构设计是否正确。如果你的表结构等设计不符合这些应用场景，必定是你的设计不对。
不合逻辑，必有问题。
再举一个应用场景例子：
预研课题：CloudEngine
场景CE-main-004：服务器申请
服务器申请的步骤有：
选择虚拟化技术（注：即容器还是虚拟机）
填写节点数
修改应用配置（注：可选）
分配服务器
服务器初始化
添加监控等各种运维基础设施
checkservice等自检
收集监控数据
服务器申请成功提示
使用者：研发经理，配管，SA
目的：既能在环境初始化时解决 stable 环境的发布，也能在环境就绪之后新建临时应用时的服务器申请和发布。
有了应用场景，就可以针对不同的用户设计故事。
三，从应用场景推导出故事
顺着场景展开，就可以得到一个又一个的故事。
譬如说，对于上面的场景，我们可以针对用户“研发经理小丁”来设计 User Story，我们看到了什么，操作了什么，又得到了什么结果：
对应的场景：场景CE-main-001，登记和维护应用
用户：研发经理小丁
故事CE-main-001-story-01：
登录CE，从左侧菜单“应用管理”，选择“应用列表”
展示登记备案的应用清单。
列表展示，字段有：
应用中文名
应用codename
创建人，创建时间
最后一次维护人，最后一次维护时间
本列表页可以按应用类型筛选。
”更多操作“区域里有以下操作入口：
点击列表页上的“新增应用”按钮
应用元数据字段有：
应用中文名
应用codename
应用配置信息
默认访问端口
状态：启用/禁用
点击新增应用页上的“保存”按钮
生成新应用，提示保存成功，一段时间后跳转回列表页
越细越好，越有助于研发同学设计页面，理解系统需要提供哪些接口和数据。
四，从故事推导出信息架构和业务流程
顺着故事，我们可以假想出人们是怎么抵达这些故事的。与此同时，即使是同一个应用场景，也会有多种进入途径。
譬如说，小丁同学既可以在首页的工作台上进入应用维护功能，也可以在二级菜单上找到对应的入口。如下图所示：
通过上图，我们可以整理出信息架构：
首页（工作台）：应用快捷入口，环境快捷入口，……
应用管理-应用列表（创建应用、编辑应用）
环境管理-环境列表（公共配置查看、公共配置编辑）
故事越写越多，进入途径梳理清楚之后，我们就能总结出需要哪些 Dashboard、一级菜单、二级菜单，进一步还能整理出业务流转流程。
以上这种思考问题和推演方法，有助于我们从零开始，一点点切入平台，而不是像下面这样“拍脑袋”地逆向设计：
先构想一级菜单和二级菜单
再构想菜单点击之后需要实现的功能点
最后在做页面组织
我们的技术预研课题一般都围绕着这四个核心概念：
开始构建一个体系。
我们顺着 场景——&故事——&信息架构——&业务流程——&版本以及版本包含的功能点，就可以把我们所掌握的资源（虚拟机集群、Docker集群、物理机、……），外界采集的数据（组织架构、员工信息、有效门店、交易……），业务流转的流程，各个部门的操作，顺利地结合起来。
这段『User Story-Product Backlog-Sprint Backlog-Version-Burn Up』的文字出自于《产品的视角：从热闹到门道》（百度产品架构师鲁克著）。
延伸阅读：
技术平台方案集：
用云栖社区APP，舒服~
【云栖快讯】如何应聘互联网公司，拿到高薪Offer？职场菜鸟如何快速成长？阿里学长为你支招，在线直播，足不出户看秘诀，IT新兵快来吧！&&
充分利用阿里云现有资源管理和服务体系，引入中间件成熟的整套分布式计算框架，以应用为中心，帮助企业级客户轻松构建并...
云数据库HybridDB（ApsaraDB HybridDB）是一种在线MPP大规模并行处理数据仓库服务。云数据...
基于全网公开发布数据、传播路径和受众群体画像，利用语义分析、情感算法和机器学习，分析公众对品牌形象、热点事件和公...
为您提供简单高效、处理能力可弹性伸缩的计算服务，帮助您快速构建更稳定、安全的应用，提升运维效率，降低 IT 成本...
Loading...如何从零开始做产品规划
非同凡想认为产品规划是营销当中最复杂、最困难、最考验能力的部分。营销的根基与起点往往是产品，而非营销概念，当然也有人会说“产品与概念本来就是鸡生蛋蛋生鸡”，无所谓哪个是起点。但在实际当中，往往产品是概念的充分非必要条件。换句话，天马行空的概念不一定有产品支撑；有产品支撑的概念才是真概念，否则，一切皆忽悠。
没有合理的产品规划，如同一个将军手上没有靠谱的军队一样，后果严重，会造成市场和资源的各种错位——新产品水土不服，与消费者需求、与既有渠道、与母品牌的形象与价格体系、与财务利润要求都不匹配；利润产品得不到支持、滞销产品无法退出、产品线之间互相排挤、主打产品错位、促销产品又太随机……最终结果就是——消费者迷茫，市场部累死，公司不赚钱。
对企业而言，产品规划比营销推广更需要时间和耐心——这是一个复杂、纠结、充满辩论和取舍的过程，需要全员介入。
一、什么是产品规划？
科学策划指出：产品规划至少包括两部分——产品结构Portfolio（产品线）和具体产品Product的规划。
产品结构规划的第1步是要划分产品类别。划分标准其实非常多：功能、价格、外观、成分、形态。实际工作中，划分标准往往是多维度的——以功能和价格为主要标准划分产品线，以外观、成分、形态为次要标准进一步细化。比如护肤品，每一个价格区间内都可以划分出抗老、美白、补水、解决特殊肌肤问题四大功能的产品线，在每一条线内，又可以根据外观、成分、形态再次细分。如此一层层细分，就会形成复杂的多维度产品线。
为什么要以功能和价格为主要划分标准？功能是从消费者出发的基本指标，价格则是最能反映竞争态势的指标。消费者首先是根据功能和价格在脑海中定位一个品牌，其次才是外观、成分、形态上的区分。当然在成熟行业当中，后者的区分更明显，比如当前日本护肤行业，产品在功能和价格上几乎无法区分，只能在外观、成分、形态上进行细致区分。
产品结构规划的第2步是设计产品线。到底一个品牌内应该有几条产品线？产品线之间有没有冲突？能不能连带？每条产品线上应该有多少种产品？是否有冲突？能否连带？每种产品又有多少不同类型的单品?
产品结构规划的第3步是设计具体产品的职能。学术上，一般把产品职能划分四类——形象产品、利润产品、主销产品、促销产品。
首先，形象产品是用来确定品牌形象的产品。生产这种产品的目的主要是为了摆谱——表明自己拥有高科技、或者独特价值。这种产品通常成本昂贵利润不高，销量很小。比如限量版产品，又比如康师傅的天价牛肉面。
其次，利润产品是用来提升利润的产品，但这种产品可能因为售价比一般产品价格高而销量并不多。
第三，主销产品是用来铺货和扩大市场份额的产品。销量大，但可能利润率并不高，即通常意义上的“通货”。
最后，促销产品是用来促销和扩大市场份额的产品。利润率非常低，但企业必须大量生产，配合主销产品和利润产品搭配销售，通常为了狙击竞争对手。
实际工作当中，人们对产品的职能可能认识不统一，矛盾重重。
最后，要规划产品的营销推广与生命周期。每一个产品的营销推广涉及到包装、价格、附加物、服务、概念（以及由概念引申的推广宣传）。同时还要考虑产品的生命周期，即产品的更新换代速度，滞销产品要有退出机制。
二、为什么要做产品规划？
巧妇难为无米之炊。
有些品牌有产品，但没有规划，市场上火什么就生产什么，或者自己生产线能造什么就什么，无法持续发展，基本赚一笔就撤。有些品牌有产品，但规划很乱，也会有很多问题：
首先，产品线过多，超过消费者的脑容量，甚至市场部自己也搞不清楚到底多少产品线，要花大部分精力清理产品线。
其次，产品线之间可能互相冲突，争抢资源（线上媒体和终端货架资源），尤其是当每一条产品线都有一个品牌经理时，更容易打架。
再次，产品线上不同产品之间也会冲突。到底应该主要支持利润产品，还是主销产品？促销产品和形象产品应该如何配合？销售部希望更多钱投入到主销产品上、并且多生产促销产品；财务部希望能多支持利润产品、少生产不挣钱的促销产品；市场部可能还想支持一把形象产品提升品牌形象，各部门的世界观不同，就会打架。
第四，产品生命周期过短或过长。更新换代速度过快与过慢一样，都会产生灾难性后果——过快则市场无法接受（客户可能不愿意下单，消费者可能在货架上找不到产品），过慢则青黄不接（客户抱怨没有新品，消费者觉得品牌太小气）。尤其是进口产品，还要考虑注册因素，中国政府一年一变的注册政策让进口品牌苦不堪言，经常会被迫青黄不接。
最后，产品规划还要考虑财务。
并非每个市场部都会看重利润，但每个公司长远还是以利润为导向。设计产品线和具体产品定位时，尽量要考虑成本和利润空间，但也不能被当前的利润要求绑架，错失了市场先机。
三、如何做产品规划？
如何从零开始做产品规划？
这一点当然是真正创过业的人更了解。从零开始，有很多种契机。有人是因为占有某种独特的技术/成分，进而从技术/成分出发设计产品线；有人是
因为先发现某种消费者需求，进而根据需求设定某种产品，然后寻找技术/产品支持，等到发展到一定阶段再延伸产品线；有人是围绕渠道出发设计产品线；还有人纯粹因为个人兴趣爱好。这么多契机，是很难统一而论某种规律的。但无论从哪一种契机出发，最终还是要综合考虑各个指标——是不真的有市场需求？技术能否支持？能不能卖进合适的渠道？有多少利润可赚？
从技术/成分出发，具有得天独厚的生产优势。但是在设计产品线时会容易发散，这个想做那个也能做。无论最终想做多少产品线，一定要规划好分阶段目标，防止品牌形象过于宽泛。
从市场需求出发，可以先一步把握市场先机。但是在设计产品线时会容易局限，或者另一个极端（太过分散）。要综合考虑自身的生产条件和竞争环境，以及长远市场需求，可以把市场需求也分阶段规划。
从渠道出发，具有销售通路的优势。但是差异化的渠道不一定对应差异化的消费者，所以在设计产品线时得非常小心，不能过于辖制自己。
如何引入新产品线和更新老产品？
产品线延伸是最基本的生意扩张方法——至少短期内可以提升一部分销量，但不保证利润和长远销售。很多成功品牌都会迫不及待的跑马圈地、扩张地盘，恨不得一个品牌可以满足消费者所有的需求。但经济学的基本假设是——理性消费者的消费需求是多样化的。完全竞争市场上是不可能有一家独大的，消费者欢迎更多的品牌选择。
引入新产品线的契机也有很多——为了填补市场空白；为了提高利润；为了满足特定渠道；为了扭转母品牌形象。无论哪种契机，一定要综合考虑母品牌与其他产品线，尽量在品牌形象、价格、渠道、媒体资源上不要有冲突。人们倾向于在保存现有产品线的基础上引入新的产品线，但一旦冲突，就不得不取舍——当然不是每一个品牌都有魄力和胆识进行取舍、进行更新换代。
更新换代，一般是为了提高利润、扩大市场份额。其前提假设是新产品比老产品更有优势，但这就非常考验“优势”的定义标准——是对比自己的老产品？还是对比竞争对手？是在地区市场上有优势吗？
再次啰嗦，更新换代的节奏频率很关键，要考虑消费者和客户是否能接受，也要考虑母品牌和其他产品线。
如何进行产品推广？
新品推广是市场部的基本工作。首先从新品的概念出发，设计360度整合营销方案。所谓整合，并非仅仅是多媒体平台投入，而是要从产品本身（包装、特性、价格）、到媒体（电视和非电视）、到线下渠道（促销小姐培训；促销机制；店内陈列装饰）、到售后服务，整个价值链的整合推广。
容易出现的问题有：忽略对老产品的支持；新产品的线上媒体与线下渠道配合不及时。尤其是对于新品上市节奏快的行业，很容易忽略对老产品的支持。现在有很多品牌在尝试产品上市前的提前推广，效果也很好，这取决于产品是否足够独特，能够让消费者在还没见到实物之前就关注。当然，对于像房地产这种长期供小于求、政策涵义严重的行业，一般都是提前推广。
在实际工作中，完美的产品战略不一定会有完美的执行效果。有时候会因为技术无法支持、渠道无法控制、媒体无法预测、竞争对手的狙击、或者工作人员流动，导致执行效果打折扣。怎么说呢，打折扣往往是不可避免的，所以尽量有两手准备，同时尽量从源头开始就设计一个相对合理的产品线，让打折的基数变高一点。
已投稿到：
以上网友发言只代表其个人观点，不代表新浪网的观点或立场。谈谈产品的需求分析和设计 - 推酷
谈谈产品的需求分析和设计
理顺产品的功能
形成产品的交互简图
理顺和完善需求文档
让UI设计师、交互设计小组参与进来
通过和大家将近一个月的工作，1.0版本的APP产品需求分析设计基本上全部完成了，这次的产品是一个音频+社交的互联网移动产品。
至于产品的具体描述，不在本文当中介绍，接下来要谈的是如何进行产品的需求分析和设计，以及要注意的问题。
理顺产品的功能
一个从零开始的产品基本上始于一个核心的想法，初期要做的就是完善和理顺产品的功能。首先，你需要问问自己，是否能够清楚的
描述一下你的产品的功能，多描述几次，看看每次的描述是否一致。通过这个过程，你会发现很多的问题都是不清晰的，都没有确定下来，
你需要不断的和大家进行讨论和交流，同时认真的分析同类产品的功能（我参照了7个同类应用）。绝对不要忽视和大家的讨论以及反复
的交流过程，这会帮助你越来越清楚产品的定位，产品的功能也会越来完善和明确。经过一番讨论和交流之后，你会发现，不论再让你描
述多少次，你关于产品各方面功能的说法基本上都一模一样，没有什么大的变动，而产品的各方面人员对此也都基本上达成了共识。
产品的各方面的功能都清楚之后，接下来需要对这些功能进行仔细的分析和理顺，哪些功能需要拆分，哪些需要合并，哪些是一类的，
哪些是核心、主要的，哪些是辅助的........认真的写一写文字、画一画导图、勾画一下框架。文档这种东西从来不是一开始就知道怎么写的
，况且也没有任何人限制你如何去写，只要能够清楚的描述出产品的各个方面，文档就是成功的。你只有不断的写一写、画一画，才能够
逐渐使自己更加清楚，自己清楚了之后，你才知道怎样让他人也清楚。
经过上面的分析和文档层面的碎片化的梳理，产品的功能文档基本上就有一个大体上的框架了，再反复的确定一些细节方面的东西、
重构一下文档的结构和顺序，确定一下大模块的划分（顶级导航模块的划分），现在文档的初期版本就形成了。
形成产品的交互简图
经过上面的工作，产品的各个方面都已经非常的清楚了，初期的文档也能够起到一定的指导作用了。接下来，非常重要的工作就是进行
产品的交互简图的设计和绘制。虽然，公司可能有专业的交互设计师，但是上面的文档是没有办法指导他们进行专业的交互设计的，作为产
品经理这个阶段的目标实际是更加深入的确定产品功能的各个细节，形成的交互简图并不是直接交给UI和技术部门直接进行开发，而是帮助
自己确定产品的细节。
单凭想，是不可能将思维触及到产品功能的每一个细节的，只有一个界面一个界面的去绘制和设计，才不会留下死角，并且你会对各个
界面和功能之间的联系和逻辑有个非常清晰的认识，会帮助你确定几乎所有细节方面的东西。不过你是不是一个具有交互设计知识的产品经
理，都要尽你所知道的任何交互知识，再结合产品的其他方面去认真的思考和绘制每一个界面原型，就好像你会的交互简图，会交给UI设计
和技术开人员直接进行设计和开发一样，不能够给他们留下任何的黑洞。而实际上往往就是这样，因为很多的公司没有专门的交互设计师，
这部分的工作只能够由产品经理兼任。
需要多提一下的是，由于UI小组不能够全面的把握事件驱动的点击跳转原型，所以最好是使用流程原型线框图，确保将所有的页面都
涉及到，并且清楚的展现各个界面之间的跳转关系和逻辑关系，使得UI小组能够清楚的知道每个界面的逻辑位置，从而准确的把握交互简图
的设计意图，也方便大家交流和讨论。至于工具，我个人非常推荐大家使用Mockups，相比于Axure的高保真图，Mockups不仅能够清楚
形象的表述清楚各个界面，而且又不会限制UI小组的设计思维。
理顺和完善需求文档
实际上在上面的交互简图的设计过程中，会不断发现问题，解决问题，不断的优化信息架构，也会知道使用什么方式（导图、流程图、
用例图）才能够将自己所想的描述清楚。一边画简图，一边写文字和描述，一边画流程图和导图。所以经过交互简图的设计，产品文档需
要的各方面的内容基本上都已经有了，现在要做的是，从头到尾的梳理一边，将文档重构一下，条理一下，这样最终的需求文档和交互简
图就都完成了。这个过程是交叉的，没有任何人强制你先做什么，后做什么，你的目标只有一个：尽最大的努力，让UI和开发人员清楚的
知道产品的各个方面和细节，这就够了，至于你的文档到底是什么形式，都没有问题。不要去找任何的模板，那一点用都没有。
让UI小组、交互设计小组参与进来
一般UI和交互小组和产品组里的都非常的近，大家有什么问题，随时交流，千万不要埋头一个人傻了吧唧的做需求分析、写文档。交
流是非常重要的一个环节，交流的目的有两个：
一是启发思路，获得灵感和解决问题的方法
更重要的一个方面是，让所有人员都知道产品的各个方面，因为你的文档和简图最终要交给他们，让他们及时的知道你的设计原则和
思路会使整个过程流畅起来，大家都心照不宣。
尤其是在文档和简图完成之后，如果UI和交互小组的人数不是非常的多（我们的产品团队之后5个人），可以把大家凑到一起，看着
文档一段一段的给大家读和分析，一个简图一个简图的给大家展示个讲解。并和大家讨论，记下所有的问题。有了这样的一个交流过程之
后，不仅能够发现更多的问题，继续完善文档，而且大家也都对产品的各个方面有了一个非常清楚的认识，结下来的工作将会非常顺利 。
经过上面的工作，产品需求分析和设计工作，基本上能够顺利的完成。
已发表评论数()
请填写推刊名
描述不能大于100个字符!
权限设置： 公开
仅自己可见
正文不准确
标题不准确
排版有问题
主题不准确
没有分页内容
图片无法显示
视频无法显示
与原文不一致扫码下载官方App
学习过该课程的人还学习过：
其他联系方式
所属系列课程
网易公司()旗下实用技能学习平台。与优秀讲师、专业机构、院校合作，为您提供海量优质课程，以及创新的在线学习体验，帮助您获得全新的个人发展和能力提升。
关注我们：
& 网易公司 版权所有
从零开始做交互（图文版）,IT与互联网,产品设计,IT与互联网,移动开发,阿西UED,目前本课程已经出版了图书：《交互设计那些事儿》欢迎大家阅读，在京东、当当、天猫可以搜索到。这个链接可以了解更多/15780
那么说了那么多，怎么才能成为一个交互师尼? 需要掌握哪些知识体系，需要有什么职业经验背景？或者我是非设计专业的人能学这个吗？还有些同学问纯自学能不能成为靠谱的交互师 ，我们会一一解答新手的疑惑。
目录如下：
第一章：什么是交互设计师
第二章：交互师的沟通必备技能
第三章：如何根据需求文档进行顶层设计
第四章：如何根据顶层设计方案进行流程和功能设计
第五章：如何根据流程和功能设计开展原型设计
第六章：需不需要高保真线框？如需要怎么进行设计呢？
第七章：测试交互原型
第八章：大招！怎么出一份各方都满意的DRD
第九章：组织交互设计评审会
第十章：交付研发与视觉部门
适用人群：交互设计师
用户体验设计师
流程设计 产品设计师
IT互联网产品设计 原型设计师}