Think Tech About Rss

我是怎么做产品设计的

2018-10-06 Think

设计流程

  • 需求分析
  • 现有解决方案(商业和环境)
  • 信息架构( information architecture)
  • 功能拆解
  • 用户流程(user flow)
  • 产品化
  • 文档书写

需求分析

这一步需要长期的经验积累
抓住核心,往往这个核心就只有一条,确定下来并和用户确认,那么后面纠结的时候就很好选择了

确定产品核心目标

用南京项目(机场旅客服务)举例,虽然标书看起来复杂繁复,但这其实仅是为了标书的制式性,这种制式避免了信息的遗漏,但同时也使得阅读和理解变得困难,那么我们就只看他的项目目标,带着这个线索去寻找标书中的阐述是怎样满足这个目标的,同样的做需求调研的同事应该在产品或者项目目标里尽量简单明确的阐述清楚项目目标,以方便产品设计人员找到这个目标。

为什么目标这么重要?

举个例子,阿里巴巴的slogan是“让天下没有难做的生意”,这是马云向社会传达的一种阿里巴巴精神,这有什么好处呢,比如当阿里的战略方向难以抉择的的时候,slogan或者说这种信仰就起作用了,哪个战略方向更符合信仰那就选择哪个,这就是信仰或者说目标使得我们的选择变得简单,也避免了盲目扩张,在产品设计上就避免了我们的功能冗余、脱离实际和目标。
实际的对于南京项目我们就可以很简单的得出一个结论:给旅客更实用和优质的服务、给机场带来更多收益。可能还会想到对悦泰要有更多帮助和发展,这个是我们后面会讲到产品化的内容,跟核心没有关系,一定要注意避免产品核心冗余,一个产品能做到解决好一个核心问题已经很不容易了。

现有解决方案(商业和环境)

了解本次设计条件。
分析现有解决方案的利弊,做到知己知彼。
借鉴好的,丢弃坏的。

在产品设计的开始前一定了解清楚本次设计的商业和环境,这包括设计依赖、政策、设计对象、现有技术条件等,比如当我们面临一个雇佣关系复杂的设计对象时那我们一定要做好产品设计未来在体制内推广的考量,作为产品设计师,应该具备现场解答百人提问的职业素养,这当然是建立在对业务理解和设计目标的绝对清晰以及对产品设计的绝对自信,以专业知识打动用户,很多时候我们不可能做到比客户更懂业务和现状,但往往我们比实际使用人所处的视野更广泛。

了解行业现有解决方案(竞品分析),参考好的(这里什么是好的什么是坏的?参考需求分析),摒弃坏的,拒绝繁杂冗余。

信息架构( information architecture)

把你确定下来的信息进行堆砌,然后归类,再做头脑风暴

微信截图_20190609190653
通过需求分析和现有市场环境的了解我们大体上会有一些想法,大可通过这个步骤对其进行分类,找一些相关人员做一下头脑风暴,大胆的去想,不要过于考虑实现,最后详细整理一下,做出一个行之有效的信息架构图,这里千万注意把信息架构图和功能拆解图分开。
南京项目的简单信息架构分析图,是用思维导图方式。

功能拆解

根据信息架构确定产品功能,并在功能后面写上版本,可以往后设计3~5年,以确保产品的先进性、可扩展性和市场优势。

根据上面的信息架构我们就可以对具体的想法实现分解到具体的功能,比如我们要实现组织机构这个功能,那它所包含的功能就有“新增部门、修改部门、删除部门、新增用户、删除用户、修改用户…”,我们还可以得出新增部门的时候必须要选择该部门的上级部门,新增用户的时候需要选择用户所在部门,渐渐的你会发现我们的设计正在趋向计算机的逻辑化,对的,产品设计(这里特指软件产品设计)就是将用户的想法利用计算机优势进行更好的实现。
另外还记的我在信息架构里面提到的“头脑风暴、不考虑实现”这一点,就是为功能拆解做铺垫的,上一步头脑风暴的东西有些常规功能我们一下子就可以进行拆解,但有些我们实现起来有些费劲但有用的功能,就可以作为版本迭代的东西往后放,使得产品具备可持续发展的基础能力

用户流程(user flow)

不同用户在不同场景下的使用流程,画出来,这对后面的交互设计很有帮助。

前面两步都有点发挥,可能思路已经都稍微脱离了实际,用什么来检验呢?就通过用户流程来检验,将本期产品的所有软件能力进行罗列然后使用功能组合来实现,例如南京项目,要实现用户购票功能,那我们就通过:
购票:打开app/小程序/微信公众号 > 登录 > 巴士车票预订 > 选择乘客 > 提交订单 > 付款 > 完成;
相应的检票功能的使用流程:
乘客 打开订单二维码 > 检票员 打开检票员APP > 检票 > 通过 > 订单完成并存档。
这样的用户使流程来表现并验证上面的设计是否正确或者冗余。

产品通用性

  • 可复制
  • 通用性
  • 可集成
  • 高度自动化
  • 可扩展

产品化这里分了五个大类,通用性和可复制性其实很类似,即就是产品的功能在一个领域具有适用能力,如南京项目的产品应该放到白云机场也可以用只是需要通过微小的适用性调整;

  • 可复制性就是产品的开发、部署是可以通过简单的复制进行新场景下的快速满足,并通过许可证对其进行控制;
  • 产品在使用中往往会遇到新老产品对接问题,那我们在设计过程中就应该考虑老数据迁移、老系统在新系统内的集成、新系统在老系统里的嵌套,这就是产品的可集成性。产品优越的可集成性也是产品的一大亮点;
  • 产品化的一个标志就是其高度的自动化和功能模块的高度松散耦合,具体体现在自动化部署、系统错误收集、自动化运维以及补丁升级等,这些功能是将研发人员和实施人员分开的关键步骤;
  • 可扩展,例如南京项目我们是要打造一个平台级产品,那么在设计上我们是否可以考虑插件模式(应用盒子),对不同机场我们的产品体系架构是不变的只是新增一些符合实际环境的应用,而开发这些应用应该很容易,那就需要提供非常强大的接口功能并配备详细的接口文档,相应的就应该具备接口的管理和监控能力。

    满足这些才能保证产品的持续性和先进性。

文档书写

  • 确立本次开发的版本功能
  • 仔细描述功能以及业务逻辑
  • 文档面向对象
  • 开篇就应该阐述清楚产品的目标
  • 能用图就用图
  • 不要出现“等”、“其他”的不确定性文字
  • 描述产品设计前提条件
  • 描述用户使用故事,图文结合

上面已经写的很清楚了,但实际上很多公司和团队都有具体的产品设计模板,但切记有些模板就像开头讲的仅仅是为了避免信息遗漏而设计的很复杂,也和不利于阅读对象的阅读,所以我们一定切记文档是给谁都得,就得满足此类人的阅读习惯和思维定式。比如CMMI的需求规格说明文档,我们其实是可以加以修改的,使其更加清晰,甚至我们可以以多种形式展示我们的设计意图,例如用户使用故事板,以连环画的形式展示用户使用的流程和场景,还有使用markdown的方式展示代码类的文字。
软件研发的最大成本就是沟通,我们的每一个环节其实就是在降低沟通成本,在产品设计层面按照以上这些实际的具体的方法去分析和书写,一定事半功倍。

Pre Next