蜗牛派主次原则
主次原则很好理解，就是重要的和不重要的要区分开，分清主次，就像你去参加一个宴席，要分宾主落座，不能喧宾夺主。在产品设计上主要是利用颜色、文字来进行区分，后端系统是面向业务的，界面也更加丰富，有展示数据指标的、有录入表单的，这时就要从下到下，从左到右，按照浏览习惯进行布局，重要图表或字段要通过颜色进行标识或加粗。
次要信息可以收缩，由用户选择展开，关键指标的明细通过链接方式以弹出页面或新页签方式浏览，重要信息尽量在一页显示，在信息过多时采用左右或上页划动时，重要部分要锁定。
直接原则
所谓直接原则就是，在产品设计时要简单直接，能一步操作的别分成两步，能在一个界面完成的工作不要用弹窗或浮层。在相关操作的文案术语上也要简短直接。
用尽量少的信息让用户以极少的成本就能完成操作，别把用户绕迷糊了。
统一原则
这个更容易理解，在画原型图时，都会使用统一的组件库，PRD都有标准的模板，在系统编码时都有统一的编码规则，源码都统一管理，接口都采用标准协议等等。
在后端系统设计时，我们可能会更注重于业务逻辑的的实现，对于界面都不太关注，在同一系统中可能是多个人开发的，元件大小、排列、命名等都不统一。
界面是给用户的第一感觉，专业与否也能体现出来，所以要统一相关标准，沟通时使用统一的术语，设计使用统一的模板，统一的样式。保持统一，降低用户的认知难度，避免出现几种不同样式，增加用户操作成本。
少做原则
少即是多，互联网业务变化太快，虽然后端系统相对稳定，但是也会伴随着业务调整持续开发，否则大家996都在忙什么呢？
快速迭代，快速上线，AB测试，目的是降低试错成本，最大限度的满足业务需求，所以产品设计时要遵循MVP原则，产品和研发都应该学习如何把握用户的心理预期，揣摩用户的心智模型，进而实现用户的心理预期。
项目管理中有一个镀金，说白了就是画蛇添足，尽量用最少的时间，最少的资源实现最大的价值，这才是目标。
在以前接触的很多项目需求，业务这也要那也要，产品也难以取舍，研发就照着PRD设计，最终做了很多工作，却没有达到用户预期，这是普遍存在的问题。
做多，做复杂容易，做少，做简单难!
反馈原则
前端系统的操作时的提示、反馈给用户的信息非常得要，这是用户体验的关键。
后端系统在查询时虽然借助于分页、缓存等技术速度有所提升，有时还会有大量的结果返回，用户还要等待；在单据保存、审核等操作时，后端处理逻辑比较复杂，有时成功有时失败。对于这些都需要实现功能与用户的交互反馈。
所以在设计时要尽量对每个操作能做到人机交互反馈，让用户清楚知道目前在做什么，处理什么样的状态，减少疑问。
反馈的文案一定要通俗易懂，千万不要将代码错误返回，这样会大大降低用户体验，不是问题也是问题了；技术查错要依赖于系统日志，而不是前端的界面错误提示；当然可以定义一些标准错误代码便于解决问题。可以学习Oracle，它们的错误代码ORA-XXXXXX，知道错误代码，就可以基本定位问题，这个在系统开发时值得借鉴。
对称原则
人是对称的，中国的很多建筑也是讲究对称的。关于对称，我的理解是在产品设计时有时要从整体上考虑，有时要从局部考虑。
像一些常用的展开与收缩也是一种对称，它们有依存关系；所以对称不单指元件的布局，操作上有时也是对称的。
单一原则
这个是面像对像设计时非常重要的原则，在产品设计上也同样适用。系统功能模块设计时不能眉毛胡子一把抓，不要期望在一个功能功界面上满足用户的所有需求，要根据业务原则、操作场景进行切分，每一步操作可以与下一步关联，引导用户操作。
总结
在产品与系统设计时可以尽量考虑这些原则，当然代码编码时有很多标准、原则，UML建模、设计模式……
在实际工作中是否真的可以做到，能做到多少，这些也是值得深思的，复杂问题简单化、简单问题复杂化属于二律背反规律，还是要寻找一个平衡点。
