《iOS应用软件设计之道》—— 1.3 厘清头绪

1.3 厘清头绪

好了,是该勾勒你的应用软件的外形了。在项目的最开始,从头脑中梳理出你想到的所有功能、挑战、想法和问题很有价值。你把它们都写到一张清单中,随后将其组织成层次结构,或一开始就按层次结构排列。重要的是要列出想到的所有东西。清单中的某一条目可能会带出其他条目等,快得令你跟不上思绪的步伐。或许,你可以静坐片刻,让大脑休息一会儿,从而想出更多的东西。
在你考虑项目时,下面这些建议可供你拓宽对某些问题的想法:
一般性需求:应用软件是干什么用的?哪些人是受众群体?
需求忌讳:应用软件一定不要干什么用?哪些人不是受众群体?
初始设置。
数据类型。
观察数据。
添加、编辑和删除数据。
分类与层次化。
特别迅速或容易做到的任务有哪些?
可能要支持但对于主要目的只起补充作用的任务有哪些?
导入、导出及共享。
与其他应用软件或服务的兼容性。
偏好。
最终,你可能会有张或长或短的清单,其中表达了按你目前的理解要解决的所有初始的设计问题。也许日后证明有些条目是多余的,大部分会证明还包含许多子问题,还会牵扯出新的问题。但毕竟这份初始清单给你指明了起点。

时间: 2024-10-25 04:39:30

《iOS应用软件设计之道》—— 1.3 厘清头绪的相关文章

《iOS应用软件设计之道》—— 导读

前言 你好 这个世界终究注意到了设计,尽管花了些时日,但设计的确很关键. 有关设计力量的完美故事可以追溯到2007年4月关于微软首席执行官史蒂夫·巴尔默的一番笑谈.那是在1月份,苹果公司的史蒂夫·乔布斯刚刚宣布了iPhone的诞生,所有人都在思量这个发布,考虑如何应对它.面对群雄割据的智能手机市场,巴尔默在"USA Today"的访谈中这样评论iPhone在市场中的机会:"iPhone不会有机会获得任何可观的市场份额.没有机会." 我可不是幸灾乐祸,但这个预言的失误

《iOS应用软件设计之道》—— 1.4 列出提纲时的更多输入

1.4 列出提纲时的更多输入 除了厘清头绪外,要列出提纲还有许多输入源.你可以通过开会来推敲出某项功能的细节.提纲是个随你所想,跟踪所有话题.子话题.问题和决策的极好方式. 如果你能直接与现有用户沟通(因为你正工作于已有产品上),或者与目标受众中的成员沟通,就可以获取海量的深层次信息.毕竟,你不能一个人想到所有东西,与用户沟通(来自支持邮件.评价等)能够让你关注自己的不足,而不是对其需求表现出全面.均衡的表达. 可供你收集那些应用软件的用户的看法的办法很多,下面是最常用的一些. 会面:这既可以是

《iOS应用软件设计之道》—— 1.13 小结

1.13 小结 缩进而分层的清单并非将思路理清的唯一方法.但它们是很好的方法.你可以采用各种组织良好的书面材料来跟踪项目.但要尝试记录需要包含到设计的每一项内容.列出所有形状尺寸的提纲,有利于在设计应用软件的任何阶段,对复杂课题分门别类.从厘清头绪开始,把所有的想法都写到纸上.构思最早的需求提纲,会让你直面项目的所有设计挑战.精简问题.概括问题有助于强化需求提纲.

《iOS应用软件设计之道》—— 3.1 流向:从一个画面到另一个画面

3.1 流向:从一个画面到另一个画面 简单地说,线框图的主要困难在于指出如何将功能清单以一系列的二维画面表达出来.困难的一部分是提供画面间的流向,让用户感到合理.易于使用.下面看一些构建聪明的流向方案,可供采用. 3.1.1 导航控制器 导航控制器是iOS上最常见的画面切换方法(参看图3.1示例).位于画面顶端的流向条指示出当前位置,并包含一个回退按钮.内容区的右向箭头提供沿层次结构向下的方法.这种组织方式使任意数目的分支路径成为可能,而且回到顶层的方法也是统一的.用户在这种流向方案中,可以垂直

《iOS应用软件设计之道》—— 3.2 对标准组件的建议

3.2 对标准组件的建议 组件可以构成画面中的各块内容,这些块包括视图.控件.警示等.在画线框图时,你只需要找出合适的组件,将其安排到合适的画面中.当然,这么说就像写一本畅销小说,只是把合适的词语按合适的顺序摆放而已.对于杰出的应用软件,你需要大量的智慧来组织设计,但要这么做,你得确保自己熟悉要用到的这些模块. 应当优先选取操作系统提供的标准组件,而不是构建自己的组件来组织设计,这是规则.对于几乎所有需求,都有标准控件把工作可靠.可预见地实现.标准控件有用户熟悉的好处,用户理所当然会花多数时间到

《iOS应用软件设计之道》—— 1.10 减少问题

1.10 减少问题 列提纲时还要顺便解答一个关键的设计问题:这些条目会不会是同一件事物呢?设计的相当大一部分工作就是找出产品到底要做成什么样子,它的每个组件如何组装到一起?两个需求能否通过一个功能满足?某个功能是否做的事太多,若分解成多个功能,会不会更顺畅些?作为设计人员,你的个人风格很大程度上就是你在合并.拆分应用软件的组件时的力度,所以要准备花大量的时间来考虑这个问题.例如,在SnackLog设计中,你正考虑是否要包含标记和多用户支持.在组织提纲时,你发现它们似乎均可以放到"分类化"

《iOS应用软件设计之道》—— 2.2 谈话中论设计

2.2 谈话中论设计 你在开会.会议已经开了半个小时.每个人都在谈论你关于Framistan应用软件设计的提议.他们都自认为清楚你提案的概念和分歧.有些人赞成你的想法,有些人则反对.最后,为了阐明其中一些细节的要点,你把Framistan画到白板上.突然,房间里有一半人站了起来:"我没想到这里有个'取消'按钮!","噢,这只是个消息框,而不是全屏窗口?","啊,但如果你旋转了iPad,结果会怎么样呢?",等等.这说明每个人对Framistan都是

《iOS应用软件设计之道》—— 2.5 何时画草图

2.5 何时画草图 在若干情况下,画草图是很有必要的. 描述架构提纲.最初,你要仔细检查整个架构提纲,画出每一幅画面的内容.每个功能都要能看到,每步流向都要明确,架构提纲里的每个条目都要以某种形式在草图中体现出来.一时间,你的各个想法和注解组成了可供检查和发展的基础.这些草图和提纲一起呈现出了对应用软件应该如何表现的高层次理解. 直接画架构草图.倘若应用软件规模较小,其功能可以通过所提供的画面显示来定义,就可以跳过架构提纲,直接从架构草图开始.对小不点型的应用软件(如内置的Stocks或Note

《iOS应用软件设计之道》—— 2.8 绘制界面草图

2.8 绘制界面草图 最直接的草图就是字面上的界面:你实际在画大致iPad或iPhone尺寸的矩形,并填充以屏幕控件的大致形式.这有助于你看到每个屏幕的大体关系.每张草图都要解答一个问题.一张草图要能回答下列问题中的某些,但可能不会马上解答所有问题: 多少内容可以恰当地放到你拥有的空间里. 应该用什么样的标准元素:顶部工具栏.底部工具栏.页签栏等. 你想构建什么样的定制控件. 控件如何分组. 画面角落和边缘应该布置哪些控件到主要位置. 你有多少空间可用. 但草图不能解答下面这类问题: 实际的颜色