设计的理解
当说到设计的时候，应该会有好多人都会关注好看或不好看，比例是否协调、颜色搭配是否够好、动效是否够酷炫…… 还认为这对整个产品的作用很大，因为设计是否好看直接会影响到用户和客户对产品的第一印象，印象差的就会没有然后了。
所以做设计就是要做出很新颖有趣、标新立异、能更多地在外观上令人愉悦甚至可以捕获人心的东西，还可以尽情地想像和表达……设计的关注点都在“形式”上，决策都以美观为标准，只要好看的都行，美观胜于一切。
然而……现实打了我们的脸，这种理解只会把设计本身局限在一个很受限的范围！
设计上追求的美，不应该是天马行空无具无束的形式艺术，应该是基于问题和美学之间的平衡，很多时候设计上的美可能背后还隐藏着一些对问题的精妙解决方案，而不是基于形式创造的。
设计的作用
It all depends
事实是，曾经很多设计做得超级棒的产品，比如在线音乐流媒体服务**[Rdio][https://en.wikipedia.org/wiki/Rdio]**，在拟物设计还盛行的时候竟然超前的使用了极简的设计风格，细节打磨得精致、微交互做得让人每用一次就多爱一点，放到现在来看依然是精品，但最终还是因无法实现盈利被收购。
因为在互联网行业，设计得再好看、再漂亮、动效再酷炫，还只是外观层面的，这种停留在外观的设计之于整个产品来说是不会影响到产品的发展甚至存亡，在这些问题面前，设计渺小到甚至可以忽略。不过，要把东西做得好看、体验做得好，其实也很不容易。
但并不是说我们做得设计不重要，我们现在做的都是基于屏幕的设计，设计形式和内容有别于以往所看到的印在纸张上的、或者一件件实体的产品、或者汽车、建筑，但它们的底层思维都是一样。比如建筑一座房子，需要考虑采光、空间的使用，也需要考虑周围环境的影响；我们基于屏幕的设计也需要考虑产品的使用设备和所处环境等因素，针对这些提供适配和最优化的设计，最终要考虑的问题大部分都回归到人将怎么样使用设计。
设计大部分时候应该是要考虑把东西做得更好，美观是之后再考虑的问题。
设计的界限
除了把东西做得更漂亮、更精致和让人愉悦外，在分工明确的岗位上怎样可以让设计有更多的价值？很多行业的设计都是一件跨领域的工作，在互联网行业也一样，既要了解产品，也要了解技术才得做得更加游刃有余。
了解产品
虽然在很多公司，职位划分得很明确，产品做需求、交互，设计负责视觉，程序员负责开发，设计与其它岗位有明显的界限划分。
但实际工作产出时，大家可能会重合度较高的部分。有时产品和开发会“吐槽”设计做得不合理，有时设计也会“吐槽”产品需求有问题，当“吐槽”开始的时候，岗位之间的界限已经变得模糊了，意味着在工作内容已经跟产品或者开发关联上，这时候正是设计可以发挥其它价值的时候。
以大掌柜项目为例，在产品出完需求文档，设计需要通遍查阅理解产品原型，先去查找可能存在的流程问题、交互问题、实现问题，以及存在疑问的地方。
如果单纯照样画葫芦地按着需求文档做，设计会做得不顺，最终的产品也会有问题，所以在设计阶段也做了一些需求和交互优化的部分。
例如下面的几点：
- 会员卡、套餐礼包，一是从UI层面拆分成两个功能模块，二是加上非会员模式，满足使用这两个功能时的实际需要和提升体验；
- 在挂单列表中的服务步骤计时监督优化成只显示最新的一项步骤，既满足了产品功能，又平衡了设计和前端实现开发上的问题；
- 产品原型上有部分事件操作沿用的PC的交互模式，不适合触控屏上操作，比如时间选择控件、员工筛选、服务商品筛选等等，在设计阶段进行了大部分改进；
- 会员标签的增删改交互的修改，在提出改进方案的基础上，再与产品、前端多次沟通确认出新方案；
- … …
打破职位所设置的界限，在不影响和干扰到其它他人工作的前提下，这种重合度较高的流程上有时可以适当多了解一下产品和多思考一点，为什么？因为这些看似与设计无关、又容易被忽略的工作，实际上对后续的设计和开发都有非常重要的作用：
- 减少设计过程中的反复沟通，有自主意识去做改进，提升设计的效率；
- 减少把问题传导到后面的开发和测试的可能，尽量避免让后续的开发阶段积累过多问题和多次重复修改。问题发现得越早，后面的沟通和开发成本就越少；
- 对于产品没考虑完整的地方，可以加以补充完善，平衡产品和设计甚至技术实现上的一些问题；
- 对产品功能进一步模块和结构化。要知道，基于屏幕的设计已经不仅仅是一个个独立的静态的页面，而是一系列页面关系和状态。
了解技术
有些时候，会有这样的声音：这个设计，程序员做不出来。
这很大可能不是程序员故意捣蛋，大多数原因可能是设计师的想法太超前没办法落地，这是设计与技术之间存在的gap。试想，如果老是因为不了解技术，设计出来的东西无法做出来，这将是很打击信心。要想填补这中间的gap，设计师有很大的必要去了解技术。
设计要懂一些技术，不用像程序员一样了解得那么深入，也不用真的像程序员一样去学习代码（也没有这种能力🥺）。像盒子模型、响应式、简单的一些数据关系等等，了解一些技术其实可以避免在设计的时候做一样不合理不必要的过渡设计，还能发现原来做的竟然是这么too navie。
登录认证的大概过程：
判断账号和密码输入框是否已经有内容输入，如果没有保持禁用状态，如果已经都输入了，按钮变为可点击状态。
点击登录按钮后，客户端将账号密码传输到服务器进行鉴权。
服务器将用户信息取出、解密，将他们与数据库进行比对验证，判断账号密码是否匹配正确。
服务器将结果返回给用户，如果正确就可以直接登录，如果不正确则提示用户账号或密码错误。
登录成功后，还要给服务器返回登录状态，并授权客户端的用户相对应的功能权限（有的可能要先选择某个范围内的权限，比如多设备管理）
登录信息过期后，要求重新登录
上面步骤还得要考虑上网络问题的影响，比如数据发送不出去，数据传输不进来。
这只是几个简单的步骤描述，因为实际上不同的登录需求复杂度不一样，都基本要好几个步骤协作才能完成整个过程。
不过，在对整个登录认证有了一些基本了解后，相比起界面上的两个输入框和按钮，可以让我们看到背后隐藏着更多在界面上看不到的过程，设计的可能只是冰山一角。
那么，了解这些对设计有什么用嘛？不还得要依旧画线框、调整比例、填充颜色吗？
Yep！！从某中意义上来说，这并不影响设计的美观性，但如果了解了，知道为什么会有密码提示错误，提示什么内容，知道还有网络问题还要处理，用什么方式处理。我们经常说交互交互，人与机器之间的交互，还是要先了解背后如何运作的，才能设计好作为中间介质的界面交互，更可以保证设计的合理性和工程化。
所有这些，不管是过程还是结果，设计师本身的受益可能比项目本身还大，因为在踩着坑学习，认知和体会是不一样的。