今天做了啥/收获：

设计好数据列表：

1.固定数据表头

固定数据表第一行，让用户在上下混动表格时，看到必要的列表信息

2.水平滚动

水平滚动必不可少，尤其在大量数据展示的表格中。这个时候，把个体标识如姓名编号放在第一列（纵）。该扩展功能，在个体标识固定后，让用户更好的对比其他各项信息。

3.斑马纹（Zebra Stripes），线条分割（Line Divisions）、自由表格（Free Form）

不同的行样式帮助用户更好浏览数据。如果表格的数据量较小，移除分割线或斑马纹可以帮助减少视觉干扰。当数据量庞大的情况下，用户容易失去视觉焦点，这时候，分割线帮助用户固定视觉焦点。交替变化的行样式（斑马纹）帮助用户在一长串水平数据表中固定视觉焦点。但是这并不适用于小数据量的表格，原因是斑马纹会让用户误以为是高亮数据

4.分页，值在一个视图里显示指定数量信息（指定数量的行，同时能导航到其他位置的一种扩展功能）

5.行内编辑允许用户直接在主视图中修改信息，不需要跳转至（或弹出）一个与主体分离的详情页。

6.可展开/收起的行

可展开的行，可以啊让用户自原有的信息视图上，直接浏览附加信息，还可以减少页面嵌套。

7.可排序的列

        比如按时间/字母/大小等排序

8.基础过滤

选择性地在表格中展示信息。

9.可搜索

搜索指定信息

来自 <http://www.pmcaff.com/article/index/778345702030464?from=search>

还有师兄说的可扩展性：

我们在产品设计的时候，通常会经历需求由小到大再到小的过程。

比如最初的时候，我们的问题是——过河。最简单的解决的方法就是造一艘小木船，这艘船需要有载人的空间，需要具备船的基本属性（如可漂浮，不漏水，有船桨）。但是这个时候产品经理通常脑洞已经大开，继续顺着这条思路向下想。

- 下雨天怎么办？于是给船加装了棚子。

- 乘客越来越多了怎么办？于是扩建了船的规模。

- 船工人手不够怎么办？于是在镇子上张贴了大量的招工启事。

- 乘客多了买票难怎么办？有黄牛怎么办？于是托12306的亲戚搞了点验证码过来，招了个开发团队搭了个能承载千万并发的“我要买船票”网站

…

…

文思泉涌，感觉自己要站在海上运输的巅峰，成为行业霸主。

然后隔壁王小二造了搜小木船，红红火火的开张了。

你还在改网站Bug的时候，王小二已经对船体进行了第一次升级。由于基础结构好，造船方式灵活，并且需求来自乘船用户，王小二的生意更红火了。

你的“我要买船票”终于上线了，王小二已经用上微信小程序了，体验流畅，还不用输变态验证码。

不死心的你雇了一票地推人员，手捧二维码，潜伏到王小二的船上挖用户，提供了“首单免费，包月5折”的优惠，却发现早期流量已经全被王小二截胡，在这么个小地方人传人的，就让他搞成垄断了。

拿不准的时候，还是先解决问题，需求来源于用户，千万别拍脑门。

来自 <http://www.pmcaff.com/discuss/index/611702523694144?from=search>

分阶段看：

产品初创阶段，应当重点满足核心用户的主要需求，此时可以暂时忽视可扩展性，也就是我们常用的MVP的思路，尽快验证需求和市场才是最重要的。

你根本无法在产品设计之初就预见到所有的功能，在真实用户开始使用之后，你当初所设想的“载人”、“载货”、“载药”的功能会有一部分会被证明不必要的。重构几乎是必然要发生的事情。

等积累了一定量的种子用户之后，此时就要开始为重构最好准备了。但是矛盾点在于，重构会使你的产品体验产生质的飞跃，但是所花费的时间太多，在这个期间，你的产品很有可能毫无变化，导致用户流失到竞争对手那里去。

这个矛盾，《启示录》里面提出了一种解决方案：

在产品开发阶段，预留20%的技术能力，供开发人员自由支配，来进行代码优化和重构。

这意味着在产品开发时留出余量，通过牺牲一些新功能的开发速度和拉长重构的周期来将重构任务安排在整个产品生命周期之中。这样不仅可以让用户在代码重构期间也能感受到产品的变化，也可以保证产品的可扩展性。

这个方法基本可以完美解决这个矛盾，不过有几点需要注意的地方：

• 将代码重构的任务拆解成几个模块，分步进行，这需要开发总监的配合。
• 要为开发人员留好充足的时间和计划表，因为重构过程中发生的意外是无法预估的，最终重构所需的时间很有可能远远超出预期。
• 要做好需求优先级的排列，因为实现新需求的资源有限，所以必须要尽量保证所实现的需求都是非常重要和有效的。

来自 <http://www.pmcaff.com/discuss/index/611702523694144?from=search>

 明天做啥：完善任务4