在一些产品团队的眼里，“设置”或许是一件非常简单的事情，因为大多设置模块的使用频次低，无关核心业务。所以当内容看似非常简单明确时，“的设置怎样”甚至会不经设计，由开发直接上手就干。
信息量冗杂带来的考验还有那些零散的、彼此关联不强的设置项。对他们的架构安排，很容易因为不知道怎么组织，便一股脑地塞进诸如“通用”、“高级”等的模糊分类中，这可谓是十足的懒人设计。
结合“设置”的自身的特简单点：这是一个对产品进行方案底层配置（相对其他模块而言）的控制模块，对用户的认知与学习能力有怎样着不低的门槛要求。也就是说，设置的内容对于用户是有一定难度的。我们需要更多考虑内容的帮助说明是否充足，不要想当然觉得用户能够理解。模板
那么，哪一种方式更好？我继续尝试从业务需求和用户习惯两个方面入手：
“设置”模块的操作往往牵一发而动全身，试错成本其实是非常大的。之前听产品经理说过一个银行客户因为修改了某个小小配置项，而造成了巨大实际损失的例子。所以，在这样一个控制中枢写般地位的模块中，即时生效的选用必须谨慎评估操作风险，减少用户轻易出错的机会。
同时，由于即时生效和表单提交这两种交互方式都非常常见，用户天然存在一种认知压力，也方案就是上面提到的“保存了吗”的不确定。所以，我们需要通过设计，让用户快速且准确地知道当前页面采用的的是何种保存交互。
从调研和自身经验得出，以下几点写都是比较好的思模板路：
- 实时的操作反馈可以帮助用户判断是否生一份效；
- 尽量控制设置内容在一屏以内，这样无论是否设计统一提交的按钮（或者更改后出现），用户都可以轻易感知；
- 将统一提交的按钮以悬浮方式明显地驻于页面底部，减轻内容一份超出一屏时的认知压力；
- 慎重处理如开关、按钮、滑块等带有很强“即时生效”隐喻的控件。
四、简单也不简单的“设置”
对于很多产品产品而言，“设置”是点击率不高的辅助模块。由开发人员直接上手，设置项很容易就变成机简单器语言的直译、迭代顺序下的铺陈，而用户是否可以接受这种简单粗暴的处理，就成了阿甘手中的那盒巧克力。
从关于“设置”的论述以小见大，哪怕是看似简单的角落，也存在着不简单的设计逻辑。如果说，设计对于商业的价值在于推动沟通，那么理想状态下，我们应当保证产品与用户的对话“时刻”流畅。所以，不要草率处置那些不起眼的边缘模块或简单功能的设计。
