状态值 and 记录值，抽刀断水水更流

不知不觉已经更新到第11篇，延续前作，依然是『列表设计』当中显现的一些交互本质。设计列表界面，通常第一步就是区分『状态值』与『记录值』，这关乎到列表的扩展性。

注意，这已经不是普通的交互设计问题，而是一些产品设计思路。

现役与前任，纠缠不清

任何『值』都是状态，基于此认知，加上时间维度，就会出现：『当前的状态』和『历史的状态』。于是，从哲学角度，有个绕口令：『状态是某一时刻的记录，记录是某一时刻的状态』。

当然，状态和记录还是有区别的：

状态只是某一个记录

记录是一系列状态其中之一

当前状态可以改变，历史记录不容篡改

每一个状态背后都隐藏着一系列记录，无论它是否愿意。假设『甲』和『乙』都是VIP用户，在列表中仿佛他们是一样的，但是如果加上时间维度，就大不相同：

设计师往往会忽略一个简单道理：只要允许，每个维度都可以加上时间的魔法，形成单独的『记录列表』；并且，这个记录列表可以通过『五帽架』原则露出在任何其他列表当中；甚至，可以实现多个列表相互连接，形成有趣的关系。

以『三好学生』为例，『学生列表』可以有如下的设计：

记录值是隐藏的宝藏

虽然用户的任何操作在服务器日志中都能找到，但是这些并非结构化数据，很难进行对比和追踪。实际运营工作中，决策不仅仅依靠『当前状态』，更多的是依靠『历史数据』的支撑；所以在产品设计中，只要允许，就尽可能多的保存『记录列表』；任何删除、丢弃、覆盖数据的行为都是一种浪费。

例如，在审核流程当中，修改被驳回的申请，并非是真正的『修改』，而是基于原始申请，复制了一个副本进行修改提交，这样每一个历史版本才有案可查。

如上图，一个流程图可以不断的加入实体，然后抽象出新的列表；也可以合并列表之后，再进行抽象，虚虚实实的衍进。

在找回密码过程中，通过旧密码辅助验证身份；在修改密码过程中，不允许使用旧密码作为新密码……诸如此类，都是重视『记录值』带来的额外优势。

因为记录值是不允许篡改的，所以实现『记录列表』本身的开发代价很低。

理解『模板规则』

设计师们总是习惯使用直观的『当前状态』，但是，在解决某些『规则』问题时，往往会捉襟见肘，因为：『当前状态』需要依赖非常强的实时同步，而当数据量激增的时候，通常是技术瓶颈。

所谓『模板规则』是这样一种存在：在某时某刻，当规则变更时，不对之前的数据产生影响，只对今后的数据产生影响。

使用当前模板改变以往产生的数据，是另外一件事，因此允许有延迟同步的现象。

多版本存储

如火如荼的【区块链】技术，其实和普通人没有太直接的关系；但是，的确给产品设计提供了一些便利：通过分布式加密永久的保存历史数据，安全实现多版本存储。

即使没有区块链，也可以开展多版本存储；如果设计师已经掌握此类技巧，那么区块链就能带来更大的价值。

以SaaS系统为例，某些数据通常会分为至少两个层级：SaaS全局数据和应用内的私有数据。为了保证功能扩展和数据保全，通常会采用下面的同步方式：

对于每一个应用，都有自己的私有数据，每个私有数据的变化是要保留历史版本的。

同时，当某个私有数据改变时，会向全局数据发起一个增量更新；SaaS系统只记录那些改变的项目，生成一个全局的历史版本。

这样做的好处显而易见：

全局数据对某个应用是受权限控制的，不可以随意调用；

私有数据又不断为SaaS系统提供刷新数据；

某个应用只关心自己的私有数据，应用之间互不干扰；

小结

善用『记录值』，可以提升产品的运营潜力和扩展性；在关注『状态值』的之余，要加以区分的设计『记录值』，灵活运用『模板规则』和『多版本存储』。

以上内容和观点，仅代表一家之言，欢迎各界朋友本着『互敬互爱、就事论事』原则切磋，各种站在鄙视链顶端俯视他人的『大牛大神』请绕行。写出来，给大家提供别样思路；百花齐放，这个行业才有生命力。

如果觉得本文还不错，请动动手指，分享给身边的设计师朋友！交互水深系列文章将继续更新，敬请关注。

你的分享，Hozin的动力！

欢迎留言或向作者提问