app设计报告总结（APP设计报告）

一个软件的设计总结报告一般加些什么参考资料

分析一下需求的具体内容：·业务需求——反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明。·用户需求——描述了用户使用产品必须要完成的任务，这在使用实例或方案脚本中予以说明。·功能需求——定义了开发人员必须实现的软件功能，使用户利用系统能够完成他们的任务，从而满足了业务需求。·非功能性的需求——描述了系统展现给用户的行为和执行的操作等，它包括产品必须遵从的标准、规范和约束，操作界面的具体细节和构造上的限制。·需求分析报告——报告所说明的功能需求充分描述了软件系统所应具有的外部行为。“需求分析报告”在开发、测试、质量保证、项目管理以及相关项目功能中起着重要作用。在实际需求分析过程中，以上两种客户可能都觉得没有时间与需求分析人员讨论，有时客户还希望分析人员无须讨论和编写需求说明就能说出用户的需求。除非遇到的需求极为简单；否则不能这样做。如果您的组织希望软件成功，那么必须要花上数天时间来消除需求中模糊不清的地方和一些使开发者感到困惑的方面。优秀的软件产品建立在优秀的需求基础之上，而优秀的需求源于客户与开发人员之间有效的交流和合作。只有双方参与者都明白自己需要什么、成功的合作需要什么时，才能建立起一种良好的合作关系客户的需求观客户与开发人员交流需要好的方法。下面建议20条法则，客户和开发人员可以通过评审以下内容并达成共识。如果遇到分歧，将通过协商达成对各自义务的相互理解，以便减少以后的磨擦（如一方要求而另一方不愿意或不能够满足要求）。1、分析人员要使用符合客户语言习惯的表达需求讨论集中于业务需求和任务，因此要使用术语。客户应将有关术语（例如：采价、印花商品等采购术语）教给分析人员，而客户不一定要懂得计算机行业的术语。2、分析人员要了解客户的业务及目标只有分析人员更好地了解客户的业务，才能使产品更好地满足需要。这将有助于开发人员设计出真正满足客户需要并达到期望的优秀软件。为帮助开发和分析人员，客户可以考虑邀请他们观察自己的工作流程。如果是切换新系统，那么开发和分析人员应使用一下目前的旧系统，有利于他们明白目前系统是怎样工作的，其流程情况以及可供改进之处。3、分析人员必须编写软件需求报告分析人员应将从客户那里获得的所有信息进行整理，以区分业务需求及规范、功能需求、质量目标、解决方法和其他信息。通过这些分析，客户就能得到一份“需求分析报告”，此份报告使开发人员和客户之间针对要开发的产品内容达成协议。报告应以一种客户认为易于翻阅和理解的方式组织编写。客户要评审此报告，以确保报告内容准确完整地表达其需求。一份高质量的“需求分析报告”有助于开发人员开发出真正需要的产品。4、要求得到需求工作结果的解释说明分析人员可能采用了多种图表作为文字性“需求分析报告”的补充说明，因为工作图表能很清晰地描述出系统行为的某些方面，所以报告中各种图表有着极高的价值；虽然它们不太难于理解，但是客户可能对此并不熟悉，因此客户可以要求分析人员解释说明每个图表的作用、符号的意义和需求开发工作的结果，以及怎样检查图表有无错误及不一致等。5、开发人员要尊重客户的意见如果用户与开发人员之间不能相互理解，那关于需求的讨论将会有障碍。共同合作能使大家“兼听则明”。参与需求开发过程的客户有权要求开发人员尊重他们并珍惜他们为项目成功所付出的时间，同样，客户也应对开发人员为项目成功这一共同目标所做出的努力表示尊重。6、开发人员要对需求及产品实施提出建议和解决方案通常客户所说的“需求”已经是一种实际可行的实施方案，分析人员应尽力从这些解决方法中了解真正的业务需求，同时还应找出已有系统与当前业务不符之处，以确保产品不会无效或低效；在彻底弄清业务领域内的事情后，分析人员就能提出相当好的改进方法，有经验且有创造力的分析人员还能提出增加一些用户没有发现的很有价值的系统特性。7、描述产品使用特性客户可以要求分析人员在实现功能需求的同时还注意软件的易用性，因为这些易用特性或质量属性能使客户更准确、高效地完成任务。例如：客户有时要求产品要“界面友好”或“健壮”或“高效率”，但对于开发人员来讲，太主观了并无实用价值。正确的做法是，分析人员通过询问和调查了解客户所要的“友好、健壮、高效所包含的具体特性，具体分析哪些特性对哪些特性有负面影响，在性能代价和所提出解决方案的预期利益之间做出权衡，以确保做出合理的取舍。8、允许重用已有的软件组件需求通常有一定灵活性，分析人员可能发现已有的某个软件组件与客户描述的需求很相符，在这种情况下，分析人员应提供一些修改需求的选择以便开发人员能够降低新系统的开发成本和节省时间，而不必严格按原有的需求说明开发。所以说，如果想在产品中使用一些已有的商业常用组件，而它们并不完全适合您所需的特性，这时一定程度上的需求灵活性就显得极为重要了。9、要求对变更的代价提供真实可靠的评估有时，人们面临更好、也更昂贵的方案时，会做出不同的选择。而这时，对需求变更的影响进行评估从而对业务决策提供帮助，是十分必要的。所以，客户有权利要求开发人员通过分析给出一个真实可信的评估，包括影响、成本和得失等。开发人员不能由于不想实施变更而随意夸大评估成本。10、获得满足客户功能和质量要求的系统每个人都希望项目成功，但这不仅要求客户要清晰地告知开发人员关于系统“做什么”所需的所有信息，而且还要求开发人员能通过交流了解清楚取舍与限制，一定要明确说明您的假设和潜在的期望，否则，开发人员开发出的产品很可能无法让您满意。11、给分析人员讲解您的业务分析人员要依靠客户讲解业务概念及术语，但客户不能指望分析人员会成为该领域的专家，而只能让他们明白您的问题和目标；不要期望分析人员能把握客户业务的细微潜在之处，他们可能不知道那些对于客户来说理所当然的“常识”。12、抽出时间清楚地说明并完善需求客户很忙，但无论如何客户有必要抽出时间参与“头脑高峰会议”的讨论，接受采访或其他获取需求的活动。有些分析人员可能先明白了您的观点，而过后发现还需要您的讲解，这时请耐心对待一些需求和需求的精化工作过程中的反复，因为它是人们交流中很自然的现象，何况这对软件产品的成功极为重要。13、准确而详细地说明需求编写一份清晰、准确的需求文档是很困难的。由于处理细节问题不但烦人而且耗时，因此很容易留下模糊不清的需求。但是在开发过程中，必须解决这种模糊性和不准确性，而客户恰恰是为解决这些问题作出决定的最佳人选，否则，就只好靠开发人员去正确猜测了。在需求分析中暂时加上“待定”标志是个方法。用该标志可指明哪些是需要进一步讨论、分析或增加信息的地方，有时也可能因为某个特殊需求难以解决或没有人愿意处理它而标注上“待定”。客户要尽量将每项需求的内容都阐述清楚，以便分析人员能准确地将它们写进“软件需求报告”中去。如果客户一时不能准确表达，通常就要求用原型技术，通过原型开发，客户可以同开发人员一起反复修改，不断完善需求定义。14、及时作出决定分析人员会要求客户作出一些选择和决定，这些决定包括来自多个用户提出的处理方法或在质量特性冲突和信息准确度中选择折衷方案等。有权作出决定的客户必须积极地对待这一切，尽快做处理，做决定，因为开发人员通常只有等客户做出决定才能行动，而这种等待会延误项目的进展。15、尊重开发人员的需求可行性及成本评估所有的软件功能都有其成本。客户所希望的某些产品特性可能在技术上行不通，或者实现它要付出极高的代价，而某些需求试图达到在操作环境中不可能达到的性能，或试图得到一些根本得不到的数据。开发人员会对此作出负面的评价，客户应该尊重他们的意见。16、划分需求的优先级绝大多数项目没有足够的时间或资源实现功能性的每个细节。决定哪些特性是必要的，哪些是重要的，是需求开发的主要部分，这只能由客户负责设定需求优先级，因为开发者不可能按照客户的观点决定需求优先级；开发人员将为您确定优先级提供有关每个需求的花费和风险的信息。在时间和资源限制下，关于所需特性能否完成或完成多少应尊重开发人员的意见。尽管没有人愿意看到自己所希望的需求在项目中未被实现，但毕竟是要面对现实，业务决策有时不得不依据优先级来缩小项目范围或延长工期，或增加资源，或在质量上寻找折衷。17、评审需求文档和原型客户评审需求文档，是给分析人员带来反馈信息的一个机会。如果客户认为编写的“需求分析报告”不够准确，就有必要尽早告知分析人员并为改进提供建议。更好的法是先为产品开发一个原型。这样客户就能提供更有价值的反馈信息给开发人员，使他们更好地理解您的需求；原型并非是一个实际应用产品，但开发人员能将其转化、扩充成功能齐全的系统。18、需求变更要立即联系不断的需求变更，会给在预定计划内完成的质量产品带来严重的不利影响。变更是不可避免的，但在开发周期中，变更越在晚期出现，其影响越大；变更不仅会导致代价极高的返工，而且工期将被延误，特别是在大体结构已完成后又需要增加新特性时。所以，一旦客户发现需要变更需求时，请立即通知分析人员。19、遵照开发小组处理需求变更的过程为将变更带来的负面影响减少到最低限度，所有参与者必须遵照项目变更控制过程。这要求不放弃所有提出的变更，对每项要求的变更进行分析、综合考虑，最后做出合适的决策，以确定应将哪些变更引入项目中。20、尊重开发人员采用的需求分析过程软件开发中最具挑战性的莫过于收集需求并确定其正确性，分析人员采用的方法有其合理性。也许客户认为收集需求的过程不太划算，但请相信花在需求开发上的时间是非常有价值的；如果您理解并支持分析人员为收集、编写需求文档和确保其质量所采用的技术，那么整个过程将会更为顺利。“需求确认”意味着什么在“需求分析报告”上签字确认，通常被认为是客户同意需求分析的标志行为，然而实际操作中，客户往往把“签字”看作是毫无意义的事情。“他们要我在需求文档的最后一行下面签名，于是我就签了，否则这些开发人员不开始编码。”这种态度将带来麻烦，譬如客户想更改需求或对产品不满时就会说：“不错，我是在需求分析报告上签了字，但我并没有时间去读完所有的内容，我是相信你们的，是你们非让我签字的。”同样问题也会发生在仅把“签字确认”看作是完成任务的分析人员身上，一旦有需求变更出现，他便指着“需求分析报告”说：“您已经在需求上签字了，所以这些就是我们所开发的，如果您想要别的什么，您应早些告诉我们。”这两种态度都是不对的。因为不可能在项目的早期就了解所有的需求，而且毫无疑问地需求将会出现变更，在“需求分析报告”上签字确认是终止需求分析过程的正确方法，所以我们必须明白签字意味着什么。对“需求分析报告”的签名是建立在一个需求协议的基线上，因此我们对签名应该这样理解：“我同意这份需求文档表述了我们对项目软件需求的了解，进一步的变更可在此基线上通过项目定义的变更过程来进行。我知道变更可能会使我们重新协商成本、资源和项目阶段任务等事宜。”对需求分析达成一定的共识会使双方易于忍受将来的摩擦，这些摩擦来源于项目的改进和需求的误差或市场和业务的新要求等。需求确认将迷雾拨散，显现需求的真面目，给初步的需求开发工作画上了双方都明确的句号，并有助于形成一个持续良好的客户与开发人员的关系，为项目的成功奠定了坚实的基础。参考资料：网络收集

APP导航设计的对比总结

纵观应用市场上的APP，导航设计的模式总是几种的组合使用。

导航设计的目的就是需要突出产品的核心，扁平化用户的任务路径。让用户能够顺利的在产品中畅行，让用户时刻清楚自己在应用中所处的位置，及如何前往目的页面。

产品的导航系统，是产品的信息结构在用户界面上的展现方式。移动端产品导航的设计没有最好之说，只有最合适，根据你的产品采取最合适的导航设计。

纵观应用市场上的APP，导航设计的模式总是几种的组合使用。下面我们来看一下常见的几种导航设计模式。

描述：

1、当产品的整个体验流中是以几个常用功能模块（一般不超过5个）贯穿的，意味着用户需要在多个标签入口之间来回切换；为了保证切换的效率，将贯穿产品整个体验的流的模块平铺在Tab Bar位置，保证了用户任务路径的扁平。

2、iOS原装App Podcast，5Tab。

优点：

1、可见性好，位置明显，易于发现，它能让用户直观了解到APP的核心功能；

2、操作性好，用户很方便就能触及到这个区域，并可在几个标签中快速切换且不会迷失方向，简单而高效；

3、符合习惯、ios原生控件，开发简单；

4、优先级较高、用户使用频繁，彼此之间相互独立。

缺点：

1、容纳个数有限，一般最多五个（不然需要结合其他方式，运用层级和收放）。

2、占据高度空间略大，一般都是文字+图标的形式。

描述：

顶部Tab是谷歌提出来的，为了区分与iOS的区别的一种导航模式，由于在顶部，手指难以触及，所以谷歌对应地提出了手势操作的解决方法：通过在屏幕左右滑动来切换标签。

实际项目中，顶部与底部配合使用的挺多。其实就是holo条。

优点：

扩展性好： 标签的个数没有上限，不过太多的话，越是后面的页面渗透率会越低；

占据空间小： 相比于底部Tab，顶部Tab一般占据的空间更小（因为不需要考虑手指点击，所以可以把区域缩小，只选用图标或者文字即可），可以把更多的空间安排给内容展示。

手势操作非常方便。

缺点：

可见性略逊：这是空间占据的区域变小之后的后果。

描述：

1、点聚式它将多个核心功能聚汇到主界面中显示，方便用户呼出使用。会搭载其他导航样式出现（如标签式）成为舵式导航。

2、与标签导航类似，就点聚工导航与标签导航的结合体，其中一个导航标签蕴含更多的操作选项，也可以理解为标签中蕴含更多二级导航标签。当页面有处于同一层级的几大部分内容，同时又需要一个非常重要且频繁操作的入口，就可以采用这种APP导航模式。

优点：

1、把类似生产内容的主功能按钮放在中间，标签更加突出醒目；

2、同时该主功能标签做了功能扩展，也因此给设计增加了一些个性化的亮点。

缺点：

1、占据高度空间略大，一般都是文字+图标的形式。

描述：

当你的应用信息足够扁平，可以尝试轮播导航；

优点：

能够最大程度的保证应用的页面简洁性，操作也是最方便；

缺点：

不能够快速的定位对应的分页内容；

描述：

1、宫格式导航被广泛应用于各平台系统的中心页面；

2、用在二级页作为内容列表的一种图形化形式呈现，或作为一系列工具入口的聚合；

3、用户频繁切换的概率是比较低；

4、在不同的文章中可能被称作：跳板（图标卡片式）、磁贴式。

优点：

1、扩展性非常好，便于组合不同的信息类型（运营位、广告位、内容块、设置等）；

2、视野范围内可以展示的功能入口多，能够让用户整体上了解APP提供的服务，从而选择自己所需要的那个服务；

3、静态、动态结合可以展示出丰富的信息，同时保持视觉统一；

4、跨平台不受平台限制。

缺点：

1、每个宫格相互独立，它们的信息间也没有任何交集，无法跳转互通；

2、当排布过多的时候，用户容易眼花缭乱，选择压力较大；

描述：

1、宫格导航的变式吧，可用来呈现实时内容，比如新闻、菜谱、文章或照片，可以采用网格布局（比如一直播和ins）或轮盘布局（比如格瓦拉电影），还可以采用幻灯片模式进行展示。

2、陈列馆式设计模式最适合呈现经常更新的、视觉效果直观、彼此独立的内容。

优点：

1、相较于列表导航、宫格式导航的不同在于，陈列馆式导航有更丰富的表现形式、更加随意的组合效果（瀑布流等）以及丰富的动态效果（轮盘、幻灯片形式）；

2、直观展现各项内容。

缺点：

1、不适合展现顶层入口框架；

2、容易形成界面内容过多，显得杂乱；

3、设计效果容易呆板。

描述：

1、抽屉式也是谷歌提出来的一种导航模式，由于虚拟按键的存在，所以在安卓上使用底部Tab会造成双底栏，视觉观感不佳；

2、一般用来放置对用户而言不太常用或者对于产品而言不太核心的功能，或者不那么需要频繁切换内容的应用，例如对设置、关于、个人信息等内容的隐藏；

3、更多的被应用于信息流产品设计中，这类产品注重核心内容的展示，用户的任务路径较为单一，几乎都是用于浏览产品的核心内容；至于其他比较低频的模块入口则会隐藏在当前界面后方，避免冗余的模块抢夺用户的眼球；

4、在不同的地方可能被称为：扩展菜单、侧边导航、汉堡导航；

5、“2/8”法则告诉我们，80%的用户只用那些20%功能，这20%功能就是信息流里面的核心功能；如果那80%不常用的功能也占用着最重要的位置，那么用户就会被打扰，产生臃肿感，甚至会放弃使用产品。

优点：

1、节省页面展示空间，让用户将更多的注意力聚焦到当前页面；

2、由于导航界面是隐藏在屏幕之外，展开之后整一页面都是导航菜单内容，所以可扩展和个性化的空间很大；

3、扩展性好，导航的个数没上限。

缺点：

1、用户不易发现，使用次功能需要二次点击，给用户在切换功能带来了操作成本；

2、可见性太差，用户还没能把汉堡菜单按钮和侧边栏联系起来，所以，侧边栏的渗透率很低；

3、不直观、不适用于主导航、如遇频繁操作的功能，用户不断开关抽屉体验不好。

描述：

1、与抽屉式导航的目的相同，都是为了突出内容。一般位于产品顶部，通过点击呼出导航菜单；

2、通常用来筛选同一信息模块下不同类别的信息，或者快速启动某些常用的功能模块，而不需要频繁的页面跳转 ；

3、Android中对应的控件为spinner控件，但该控件用于同一类别下不同视图之间的切换，而不是跳转至完全不同的视图。iOS中下拉菜单为自定义控件，可以实现不同类别之间的切换；

4、下拉导航还有一种变式，就是下来菜单中展示两级甚至多级，一般在电商产品中比较常见，因为品类和筛选条件众多。

优点：

1、菜单与界面的连贯性比抽屉式要好，容易让用户感知当前位置；

缺点：

2、位于屏幕上方，相对隐蔽且不能结合手势操作，不适合于频繁的切换功能使用；

3、考虑到导航菜单的可用面积较小，所以一般采用列表的形式展示菜单内容。

描述：

1、作为信息组织框架，是我们在产品设计中必不可少的一个信息承载模式。

2、适合用来显示较长或拥有次级文字内容的标题，每行可以融入较多信息。

3、与宫格导航类似，常用于二级页面，不会默认展示任何实质内容，所以通常app不会在首页使用它；

4、无论ios开发和android 都有现成的列表布局插件和模板。

优点：

1、由上至下查看符合习惯；

5、结构清晰，易于理解，冷静高效，能够帮助用户快速的定位去到对应的页面。

缺点：

1、条目太多或分布不合理会导致用户查找困难；

2、不适合需要频繁切换任务的情况。

如何写年终总结APP？

都很有期待的，而且写的都很好。我的年终总结APP是很简单的，下面就把网上收集的一些总结分享给大家，都很有创意。

playstation的app年终总结是一篇正经统计app报告

playstation给人的感觉就像是在看一组商务PPT，画面简洁，画风高级，内容丰富，感觉就是为直男写的统计报告，优点就是一目了然，通俗易懂。

抖音app年终总结是把短视频贯彻到底

抖音可以说把动画风、画面设计和音乐融合得非常巧妙了——一个透明的小孩子形象带着好奇心闯进了抖音这个大世界，一边奔跑一边去探索、发现，做得挺梦幻。各类数据也不是简单地堆积，比如什么“你看了6183个美食教程视频，相当于学习了99个小时的厨艺知识”。

美团的app总结就是简简单单干饭人

美团的年度报告app看上去就“朴素”不少，标志性的黄袋鼠吉祥物配上文字描述，页面设计简单明了；而且数据包括注册时间，订单数量，消费金额，最常点的美食。怎么说呢，就很朴实无华的干饭人气质哈。

网易云音乐app年终总结是没人比我更懂创意

虽然已经无从考证年度报告是哪个平台最先开发的，但在线音乐平台的报告一定最深入人心。网易云音乐创意当先，比如去年的报告里，它就让用户自己定制了一个角色形象，然后再进入一个小岛，根据设定的路线一步一步引出数据，可以说故事性很强了。

总之我感觉都很有创意，只是因为每个人审美观点不同吧，所以才会有不同的感受。不管怎样，只要自己喜欢就好了。

APP评论模块设计总结

这次设计采用主题评论式，这样有助于展开讨论，聚焦，提升优质评论。

一级评论按照时间倒序排列

二级按照时间正序排列，有助于读者理解讨论话题进展。

01、在动态页写一条评论，生成一条新评论A1、A2、A3……

02、回复A1、A2、A3……生成二级评论一条，A11、A12、A21、A31……

03、点击二级评论，跳转一级评论列表页

点一级评论，生成一条新的回复二级评论

点二级评论：@此评论发布者，生成一条

点赞、回复、复制、举报、删除、分享

另外需要跳转逻辑，以及回复的入口

01、我发布的：在“我的”/“消息中心”收到消息，点击跳转评论页面

02、回复我的：在“我的”/“消息中心”收到消息，点击跳转评论页面

03、个人主页：评论或回复的展示位置

01、评论的加精、置顶、屏蔽、删除、封禁、敏感词替换

02、被删除/屏蔽后显示逻辑

保留当前区块、显示内容为：评论已删除

01、评论字数设置长度，字数超，红字提醒超限，同时发送按钮置灰

02、点赞的动画交互，增加趣味性

03、评论点击区域细节：评论区有很多元素，需要告知开发哪些区域可点，点击跳转到哪些地方。

APP首页设计思路总结

最近我服务于某品牌CRM项目，做一个健康类APP，真的挺兴奋的。目前此APP 1.1版本已上线，从平台策略到最终测试上线，中间也是充满坎坷和痛苦，抉择与妥协呀。2.0版本已在规划中。由于功能和互动体验进一步完善，此版本增加了首页，就想写写对APP首页设计的一些思考和总结。

APP首页和网站首页一样，需要告知用户“我”(APP)是谁，“我”(APP)能为“你”(用户)提供什么服务、内容、产品...“你”(用户)能够通过“我”(APP)提供的服务、内容达到什么样的目的。不同APP类型，首页设计也是因平台而异的。比如内容资讯类的APP，多数在首页采用无限加载的形式，通过个性化的内容推荐，吸引用户深度阅读、评论互动、分享转发...总之，要增加用户停留时间；高频使用的工具类APP，首页大多就是主要功能界面或突出功能Action，简单直接，用完即走...

今天，我们从首页目的的角度，总结APP首页的设计思路。

首页是用户消费内容最主要的场景。典型的方式即在首页进行瀑布流设计，无限加载内容。比如时尚电商APP、内容类APP以及Twitter、Facebook和pinterest等依赖Feeds的社交类APP，都会选择这种设计思路。这类首页要考量产品运营的能力，若要考虑内容的个性化推送，规则算法可又是一“坑”。

导流型的首页，一般提供频道、品类、搜索等入口，将用户尽快引入二级页面。也就是说，首页不再是消费内容的主场景，而是更多起到导流作用。比如电商类产品(天猫、京东)、旅行产品(携程、去哪儿)等。

首页即功能/体验界面，用户在进入首页即进行功能操作或深度互动。第三种与第一种消费内容比较相似，但第三种类型的设计大多集中在工具型、交通类或游戏类产品。

暂时想到这么多，欢迎补充。

思来想去，我们的APP是工具及游戏类的结合，核心栏目中都有用户关心且和自己息息相关的数据，如果散落在各个栏目中，层级较深，也势必会增加用户操作成本，因此想将这些信息更扁平化的集中呈现。初步考虑，会将APP首页作为集合页，并做个性化体验设计，露出用户最为关心的数据信息，并向一级/底级页面导流，同时在页面底部做官方内容的推荐。

还是要谨记，平台产品的规划，要结合品牌商业目标、产品类型、用户需求综合考量。