`
fang9159
  • 浏览: 47086 次
  • 性别: Icon_minigender_1
  • 来自: 湖北
社区版块
存档分类
最新评论

设计中碰到难题!怎样取舍开发效率和软件易用性?

阅读更多

现在正在设计一个投票管理的模块。本来很简单的一个功能,但为了良好的易用性和交互性,我将页面的那一块设计得很复杂,比如要写大量的javascript代码才能实现的一些效果,比如新增一个分类和一个主题在一个页面里面进行,这样做投票的人不用去两个页面去做维护等等。还有树型上的处理,而且可以多笔输入,比如一个人设计投票时可以一次性的做一个调查问卷再保存。虽然这样做投票的人和去投票的人都很易用,但是这无疑使开发人员比较麻烦,增加了他们许多工作量,

所以我很矛盾。,用比较大的工作量来换取软件的易用性和交互性 值得吗??? 

刚刚从事设计不久,遇到这样的问题希望大家指教指教

分享到:
评论
15 楼 fang9159 2007-04-18  
呵呵,基本上设计完成,但是设计出的页面有点复杂,使得整个模块不能很好的分工。只能自己设计自己实现了!:)
14 楼 dovecat 2007-04-12  
gigix 写道
dovecat 写道
我不也就那么一说,难道客户就真的懂得他需要什么?那还要需求分析师干啥子啊

客户必须明白每个方案的取舍是什么,客户必须做决策。
对,我非常同意,只是说经常性的,客户并不能很明确的定义出需求,还需要我们去帮他挖掘出一些潜在的需求.当然最后还要客户方确定.
13 楼 fang9159 2007-04-12  
没想到刚写了一个帖子就有这么多的回应。小弟不甚感激!!
因为小弟参与设计不久,而且是偏重技术方面的设计,也就是在在通用性和良好的维护性方面做研究,但是小弟认为传统的bs设计都不是太重视界面上的设计,比如像我说的怎样可以让你做的功能又易用而且程序员开发效率又跟得上去。由于小弟做设计之前比较擅长前台页面的开发,所以在做页面方面小弟有很多想法,想通过javascript来弥补
bs在界面上的不足!!!
不知道这样小弟是不是走偏设计方向?
12 楼 gigix 2007-04-12  
dovecat 写道
我不也就那么一说,难道客户就真的懂得他需要什么?那还要需求分析师干啥子啊

客户必须明白每个方案的取舍是什么,客户必须做决策。
11 楼 ray_linn 2007-04-12  
要我就问老板~~~项目值钱多做点,项目不值钱就少做点,客户不一定是正确的,但老板一定是。。。
10 楼 dovecat 2007-04-12  
抛出异常的爱 写道
zhangzhaofeng 写道
dovecat 写道
不清楚具体需求,但是,将一个页面设计的过于复杂,不觉得会存在良好的易用性和交互性.客户是上帝,他喜欢啥样的就啥样,只要他懂.


同意
两个没作过需求的人。。。。。
客户以为我们是魔法师。。。。
念个咒什么都能作出来。。。。

我不也就那么一说,难道客户就真的懂得他需要什么?那还要需求分析师干啥子啊
9 楼 BirdGu 2007-04-12  
gigix 写道
问客户
譬如比较好用的方案需要多花3天时间,你应该问客户是否愿意等这3天,而不是自己在这瞎琢磨。


理论上是可以这样。不过实际中还要看项目在成本和时间进度方面有多大的弹性和协商的余地。

可能用户觉得多花3天没关系,可是如果有很多这样的功能,这个要多3天,那个要多2天,楼主的老板可要跳脚了。
8 楼 抛出异常的爱 2007-04-12  
johnyq 写道
gigix 写道
问客户
譬如比较好用的方案需要多花3天时间,你应该问客户是否愿意等这3天,而不是自己在这瞎琢磨。

正解!
我碰到过这样的客户,他基本上不提需求,只是指个大方向,等你做完了功能给他演示需求就来了(ZF领导),有时候我们就尽量在界面和操作上做的精细点,以换取在功能上的妥协(天知道他会什么提些匪夷所思的功能?)
XP啊XP就是给这些人用的。。。

需求之花如芝麻开花一样节节高。
7 楼 johnyq 2007-04-12  
gigix 写道
问客户
譬如比较好用的方案需要多花3天时间,你应该问客户是否愿意等这3天,而不是自己在这瞎琢磨。

正解!
我碰到过这样的客户,他基本上不提需求,只是指个大方向,等你做完了功能给他演示需求就来了(ZF领导),有时候我们就尽量在界面和操作上做的精细点,以换取在功能上的妥协(天知道他会提些什么匪夷所思的功能?)
6 楼 抛出异常的爱 2007-04-12  
zhangzhaofeng 写道
dovecat 写道
不清楚具体需求,但是,将一个页面设计的过于复杂,不觉得会存在良好的易用性和交互性.客户是上帝,他喜欢啥样的就啥样,只要他懂.


同意
两个没作过需求的人。。。。。
客户以为我们是魔法师。。。。
念个咒什么都能作出来。。。。

gigix 写道
抛出异常的爱 写道
看给多少钱
给的多就多干,给少就少干

还要看关系,关系差就不要作太复杂的东西,说多错多。
关系好可以多作一点。

做得多不一定就更有价值。很多时候,做得多,错得多。
所以说到底还是,问客户。
另外个人认为,关系差就提供比较差的服务,这是很缺脑子的主意。关系好的客户或许能容忍你一次两次杀熟,关系差的客户才需要你最认真对待。


关系差就要把东西作的越简单越好,由于出BUG的成本太高了。。。
关系好可以把出BUG的成本降低。。。
小公司。。测试不是很完善。
5 楼 gigix 2007-04-12  
抛出异常的爱 写道
看给多少钱
给的多就多干,给少就少干

还要看关系,关系差就不要作太复杂的东西,说多错多。
关系好可以多作一点。

做得多不一定就更有价值。很多时候,做得多,错得多。
所以说到底还是,问客户。
另外个人认为,关系差就提供比较差的服务,这是很缺脑子的主意。关系好的客户或许能容忍你一次两次杀熟,关系差的客户才需要你最认真对待。
4 楼 zhangzhaofeng 2007-04-12  
dovecat 写道
不清楚具体需求,但是,将一个页面设计的过于复杂,不觉得会存在良好的易用性和交互性.客户是上帝,他喜欢啥样的就啥样,只要他懂.


同意
3 楼 抛出异常的爱 2007-04-12  
看给多少钱
给的多就多干,给少就少干

还要看关系,关系差就不要作太复杂的东西,说多错多。
关系好可以多作一点。
2 楼 dovecat 2007-04-12  
不清楚具体需求,但是,将一个页面设计的过于复杂,不觉得会存在良好的易用性和交互性.客户是上帝,他喜欢啥样的就啥样,只要他懂.
1 楼 gigix 2007-04-12  
问客户
譬如比较好用的方案需要多花3天时间,你应该问客户是否愿意等这3天,而不是自己在这瞎琢磨。

相关推荐

    QCon 2009 beijing全球企业开发大会ppt:12.Hadoop取舍之间--高性能、高流量和多数据中心互联网应用架构设计

    在此过程中总结了一系列的经验和教训,并应用于FreeWheel的研发中,从设计的第一天起就以高效、高流量、高稳定性为目标,有计划按步骤地预先实施具体解决方案,避免问题的发生。 本主题由于FreeWheel创始人Diane Yu...

    概要设计说明书模板

    并且需要指出在概要设计中的功能模块编号与《软件需求规格说明书》中的业务需求编号及性能需求编号之间的对应关系。 功能层次图 【说明】指明在输入信息转变为输出信息的过程中,为了满足用户的业务需求,应用软件...

    设计与开发管理程序APQP.doc

    " "1.1为确保在设计初期能使各项质量规划完善与周详,达到缩短开发期,减少 " "制程难度,进而提升产品质量及达到产品的可靠度和信赖性规范。 " "1.2为预防初期设计错误而造成尔后变更损失而订定之。 " "2.范围: " ...

    锋采图书租售管理软件

    针对这些中小型书店的实际需求和计算机软硬件条件,在功能上和易用性上做了适当的取舍和优化,以期能够在较低配置的计算机上能够流畅运行,方便读者\图书\商品信息多方面管理。  【特别提示】:本软件从6.0版开始...

    删除:大数据取舍之道

    《删除:大数据取舍之道》讲述了遗忘的美德,为读者展现了大数据时代的取舍之道。《删除:大数据取舍之道》洞见了“被遗忘的权利”,回溯了人类追寻记忆的过程。如今,数字技术与全球网络正在瓦解我们天生的遗忘能力...

    设计模式解析(第二版)

    本书以作者多年来为软件开发人员(包括面向对象技术老兵和新手)讲授模式的经验为基础撰写而成,首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性。随后,使用易懂的示例代码阐明了许多...

    设计模式解析(第二版).part2

    首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性,随后使用易懂的示例代码阐明了12个最常用的模式,包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷,使读者能够理解...

    大数据取舍之道

    维克托·迈尔-舍恩伯的《删除:大数据取舍之道》英文原版和网络上公开的一部份中文内容

    定时播音软件

    使用于网吧播音,支持自定义修改播音时间,播音内容。

    实现平衡:软件开发的新关键点

    合理权衡软件开发中的各种因素绝不是新问题,多年来企业已经在应对复杂的软件开发过程中意识到了“取舍”问题。但企业究竟应如何寻求平衡;开发小组应围绕哪些关键点来寻求平衡

    设计模式解析(第二版).中文版.PDF格式 (2/2)

    本书以作者多年来为软件开发人员(包括面向对象技术老兵和新手)讲授模式的经验为基础撰写而成,首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性。随后,使用易懂的示例代码阐明了许多...

    《设计模式解析(第二版)》中文part3

    首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性,随后使用易懂的示例代码阐明了12个最常用的模式,包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷,使读者能够理解...

    《设计模式解析(第二版)》中文part2

    首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性,随后使用易懂的示例代码阐明了12个最常用的模式,包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷,使读者能够理解...

    《设计模式解析(第二版)》中文part4

    首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性,随后使用易懂的示例代码阐明了12个最常用的模式,包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷,使读者能够理解...

    Swift语言的设计取舍及跨语言调用.pdf

    Swift语言的设计取舍及跨语言调用.pdf

    关于分子公司区别、税务筹划和如何设立取舍详细讲解.doc

    关于分子公司区别、税务筹划和如何设立取舍详细讲解.doc

    uml设计模式解析(第二版)

    首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性,随后使用易懂的示例代码阐明了12个最常用的模式,包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷,使读者能够理解...

    Discuz! 插件开发手册

    插件接口能够实现哪些功能、不能实现哪些功能,插件为此而需要做的优化、改造和取舍。 编写相应程序代码和模板语句,实现所需的功能并进行代码测试、兼容性测试和代码改进。 如果需要公开您的插件,可以用插件导出的...

    设计模式解析(第二版).part1

    首先概述了模式的基础知识,以及面向对象分析和设计在当代软件开发中的重要性,随后使用易懂的示例代码阐明了12个最常用的模式,包括它们的基础概念、优点、权衡取舍、实现技术以及需要避免的缺陷,使读者能够理解...

Global site tag (gtag.js) - Google Analytics