关于产品整体设计的问题

最近在设计一个庞大的产品体系,在设计的时候跟领导和其他同事交流的过程中发生了很多思维碰撞,在此记录:

1.关于风险问题

  对整个产品的前期来说,风险识别是不是重要的工作。目前有两个意见:

   1)应该尽可能的识别各个级别的风险(尤其是根据以前经验积累的风险),考虑风险应对措施,减少项目失败风险。

      问题:

         初期容易陷入细节讨论,前怕狼,后怕虎,不利于整体规划。

         细节性的风险可能不在领导的管理范围内,你不能让领导去关心一个很细小的技术问题如何实现。因此容易造成领导的反感。

   2)不应该考虑过细的问题,只需要考虑大的风险即可。等遇到风险时,在根据实际情况解决风险。

      问题:

       容易忽略一些极其重要的风险,一方面不利于架构设计,造成设计的缺陷高。另外一方面后期在进行风险规避的成本会极高。容易拖延项目工期,造成项目失败。

  个人意见:

还是应该考虑各个方面的风险,不一定在初期专门来进行风险的评估。初期的风险主要来自于以前项目的经验。单是对以前项目中遇到的风险要有足够的重视。避免出现以前出现的问题在后期还会出现的问题。

2.关于用人的问题

    在前期规划时,碰到一个问题,对于组内UI设计师的岗位职责的问题,如果进行人员安排的问题。

   从目前的实际情况看,国内小企业中的UI(UE)设计师实际上在干一些平面设计的工作,界面布局,用户体验一般是开发经理或者产品经理说了算,而架构师也从实现角度给予意见,因此UI设计师的限制很多。

    从目前的规划中,我们期望对UI设计师的职责有两个方面的声音:

    1.按照现有的工作来进行规划;

         优点:风险小,但是开发经理,架构师需要负责更多的工作。

    2.让UI设计师独立完成产品的UI设计工作,包括了解用户需求,设计出良好的用户体验,又能方便系统进行开发实现。

         优点:让UI设计师有更充分的设计空间。

         缺点:风险高,有很大的风险造成项目延期。

个人意见:

       采用第一种方案,当然在真正实施的时候,可以给予UI设计师充分的讨论空间。但是一定不能交给UI设计师之后,其他人员就不在参与。

 

3.关于初期设计颗粒度的问题

   关于小系统的设计,一般来说都是在初期将所有的情况考虑好,之后再进行各种文件的编写和设计。因此一般不会出现大的设计偏差。

   但是在大的系统设计过程中,如果继续采用这种方式,容易造成对需求理解不清,无法工作的问题。

   自下而上的设计:

       初期工作量巨大,不容易理清思路,但是一旦理清,后续工作容易开展,而且不会出现大的偏差。

       在这个过程将能想到的所有问题,一个个进行确认,知道所有问题确认完成。

   自上而下的设计:

       初期工作容易开展,领导层容易接受,但是后期在具体的设计和实现时容易出现变动,甚至项目失败。

 

个人意见:

        个人还是习惯采用自上而下的设计理念。

时间: 2024-10-13 08:55:16

关于产品整体设计的问题的相关文章

用产品思维设计API(一)——RESTful就是个骗局

用产品思维设计API(一)--RESTful就是个骗局 前言 最近公司内部在重构项目代码,包括API方向的重构,期间遇到了很多的问题,不由得让我重新思考了下. - 一个优雅的API该如何设计? - 前后端分离之后,API真的解耦分离了吗? - 不断的版本迭代,API的兼容性该如何做? 年前,我司内部的接口已经进入了一个完全的重构阶段,参考了市面上各大平台的API和文档,自己也总结出了很多的心得.这里向大家分享一下,接下来一个月,我们向从下面几个方面向大家介绍一个优雅的API(至少我认为挺优雅)该

六大步骤分解产品原型设计过程

本教程将从整体和局部实例两个部分来讲解原型设计的步骤.产品的原型设计一般是基于文档的形式所表达出来的形象设计,想要把产品原型设计做好其实并不容易,想把原型做得比文档好更不容易,这里会结合一些产品原型设计的方法以及技巧来介绍原型设计的步骤,希望可以帮到有需要的朋友. 设计原型也是讲究方法步骤的,一是要提升原型设计的合理性,避免出现头重脚轻的保真程度不一致的情况:二是要减少原型设计所占用的时间,大家各自的工作时间都是很宝贵的,不可能在原型设计上投入过多的时间,因此掌握一些原型设计的方法和技巧相当必要

平台型产品的设计思路[转]

http://www.woshipm.com/category/pd 简单的说,自己不干,而是提供一个平台,让别人去干的产品.比 如淘宝就是一个平台,它自己不卖东西,而是让买家和卖家在这里交易,它提供帮助.服务和监管的作用.很多人可能觉得淘宝.天猫的设计逻辑并不复杂,但其实 你看到的只是产品的一小部分,即面向买家C(Customer)的部分.面向卖家B(Business)的部分则要复杂的多,当然还有面向开发者 D(Developer)的(比如淘宝开放平台).CBD都生长在淘宝平台上,都是平台的一

用产品思维设计API(三)——版本控制,没有你想的这么简单

用产品思维设计API(三)--版本控制,没有你想的这么简单 前言 最近公司内部在重构项目代码,包括API方向的重构,期间遇到了很多的问题,不由得让我重新思考了下. - 一个优雅的API该如何设计? - 前后端分离之后,API真的解耦分离了吗? - 不断的版本迭代,API的兼容性该如何做? ps.这里所说的API仅为Web API,提供APP\WEB开发使用. 年前,我司内部的接口已经进入了一个完全的重构阶段,参考了市面上各大平台的API和文档,自己也总结出了很多的心得.这里向大家分享一下,接下来

15款优秀移动APP产品原型设计工具

一款优秀的移动APP产品原型设计工具应该具备: ①.支持移动端演示(随时随地演示给BOSS,厕所&食堂&电梯-以体现我是那么的敬业--长点工资必备) ②.组件库(高效复用,谁用谁知道) ③.可以快速生成全局流程(程序猿看不懂拆解的,给丫的看这个) ④.在线协作(多个PM狗一起用) ⑤.手势操作.转场动画.交互特效-(这些都不需要,留给专业的交互.视觉,搞那么虚的不如多想想产品流程逻辑做做减法.写写xxRD啥的) 这些年,产品狗们折腾过的原型工具: 1. POP(Prototyping on

用产品思维设计API(二)——数据解耦,才是前后分离的本质

用产品思维设计API(二)--数据解耦,才是前后分离的本质 前言 最近公司内部在重构项目代码,包括API方向的重构,期间遇到了很多的问题,不由得让我重新思考了下. - 一个优雅的API该如何设计? - 前后端分离之后,API真的解耦分离了吗? - 不断的版本迭代,API的兼容性该如何做? ps.这里所说的API仅为Web API,提供APP\WEB开发使用. 年前,我司内部的接口已经进入了一个完全的重构阶段,参考了市面上各大平台的API和文档,自己也总结出了很多的心得.这里向大家分享一下,接下来

你是否是团队里面最默默付出的那个coder,却发现滔滔不绝的产品和设计是团队里的开心果(转)

程序员,你是否是团队里面最默默付出的那个coder,却发现滔滔不绝的产品和设计是团队里的开心果? 你是否自命不凡,精通Java.C++.Python……却发现得到的只是做不完的工作? 你是否觉得自己是贡献最多的那个,却因为找不出自己在工作中取得的成效而无法加薪? 你也许需要知道自己的性格是什么. 这两天身边许多朋友都在测一个叫做MBTI的测试,这个测试从动力.信息收集.决策方式.生活方式四个方面评价一个人. 我发现原来在日常的交往中的差异和冲突不是没理由的,也不是别人故意要为难你,而是因为不懂得

Mockups --产品原型设计软件

今天认识了一个叫Mockups的东东..以我的了解..他是一款用于产品最初设计的软件!能根据客户的需要设计出最节省成本的初稿.赞! 界面也萌萌哒..回家之后就迫不及待的自己练习了下! 下面是自己做的山寨淘宝的样子 哈哈

用thinkphp进行微信开发的整体设计思考

用thinkphp进行微信开发的整体设计思考 http://www.2cto.com/weixin/201504/388423.html 2015-04-09      0个评论       作者:明之暗夜 收藏    我要投稿 因为项目中很多地方都涉及到微信接口的调用 比如很多前台模块需要用到 后台模块也有少许调用 其他模块也可能会需要调用  为了让他们都能很方便的直接调用 我把他们独立成为一个模块 这个模块包含了基础的微信接口和微信jssdk 具体的设计请参考下面  当然如果有更好的建议可以