交互设计那些小纠结

交互设计是门学问，稍微了解多一点就会听说各种各样的原则和定理。它的理论比较泛，不一而足，我就不掉书袋了。这里就分享一下我在项目实践中遇到的问题和所学所得。
项目链接——可看UI和最初的交互设计

其实，一个按钮一句提示，都可能包含了设计师的很多考量。

交互设计是什么

一言蔽之，给出需求的解决方案。需求已经是实际生活里的问题的解决方案了，现在怎么需求又需要解决方案了？呐，举个例子，把大象装进冰箱这个需求，需求文档或者用例文档上会写：1.打开冰箱；2.把大象放进去；3.关上冰箱。那么交互设计就是：冰箱是双开门还是带把手或者干脆推拉式冷柜？大象是叫用户横着塞还是竖着塞，头先还是屁股先？大象太大怎么跟用户说装不下呢？
鸡零狗碎……(大雾)
当然啦，真正的设计不会有这么多天马行空的想象，一般都会有一些形成定式的解决方案可以遵循，作为设计基础（突破定式是需要革命性的优秀设计的）。例如你所见的点餐界面，无一例外都是左边一列分类，右边一列餐品，可以上下滚动——这叫符合用户习惯。
交互设计是什么再给个个人的理解就是，低保真原型。最终的UI成稿基本可以分成两个部分，交互设计和视觉设计。低保真原型就是那种灰灰的但是跳转啊提示框什么的都具备了的设计稿，它已经可以表达出解决方案。然后才是考虑背景、图标、边距，配色啊效果啊这些东西，是为视觉设计。

交互设计的流程

首先业界是一个什么标准？应当交付什么制品？我查了一些资料，标准流程是有人提的，但真正实施起来还是要看情况做取舍。核心是：理解需求，了解用户群体理解用户行为，给出设计方案，反复验证和改善。制品上面有提到了，主要就是原型了，也有故事板。
这个流程是站在纯粹的设计师角度提出的，而我自己呢首先是做需求的，当然没有第一步。并且由于点餐产品比较常见，需求也是很好理解，我们交付的也是类似故事板的说明文档，再加上沟通和讨论。

做完的反思

从另外一位设计师小姐姐那里学到很多。了解了一些常见的设计元素，比如tab、全局搜索框，这些东西用在什么地方是合适的；哪里用hover设计、变色效果；用户提示信息的设计都有哪些。
前面也说到尽量遵循用户习惯的原则，所以学习和借鉴很重要，见得多了自然比较有底。客户端的点餐程序就不用说了，竞品有很多，日常就在使用。不过商端就没有直接的竞品可以参考了，因为我们没有资本去假装商家购买和体验商端产品。好在后台管理类的都长得差不多，模式可以互用，无非是一个侧边栏展示分级的功能菜单，一般进来先是一个主页这样。

下面就会放上我遇到的一些设计问题，说明我们是如何确定最终方案的。当时扣这些细节一度被队友嫌弃，争论得很心累却看起来没什么价值，很浪费时间。但我认这些是值得的。一是为了尽可能追求最好的用户体验，二是不管怎么样都要拿出一个解决方案，弄清楚不同方案的利弊再做决定总比随便定一个要好。

小纠结

！！！多图预警

1.小程序端扫码提示页

小程序如果上线了，会有两个入口进入程序，一个是扫商家的二维码直接开始点餐，一个是直接启动小程序（微信顶部下拉点小程序图标）。后者的话，还没获取到商家信息，那点进来的界面应该长啥样？

• 单独再做一个页面，上面给出两个入口，一个我要点餐指引用户扫码，一个历史订单？
• 不用单独啦，原本设计的顶部tab就有这个效果，直接让点餐页信息都清空就好了。
• 在菜单页面显示“暂无附近店家”这样的错误信息？
• 分析到这种操作的主要场景是查看历史订单。这种方式进来的也不算错误操作，那报错就不太好。
• 那提示，如需点餐请扫描店内二维码，吧。
• 哦对了，从外面戳进来的时候可以优先跳到历史订单页。

这设计挺简单的，我画了个草图（如左图），交给开发的队友自由发挥（如右图）。

其他队友说感觉好空，他就找东西填充了一下。
——失了智的操作……
（师姐评价“空说明那一页结构是没有问题的，就是图标如果可以点击的话，做的稍微小一点更好，弄这么大看起来不可点击。”）
我们参考了一下其他的类似界面设计，比如唯品会优惠券为空的设计，还有其他app订单为空的设计，基本是一张图一句提示然后一个按钮，所以看起来不空。最后我们也是这样的，还是师姐亲自画好了给发过来。

最后再分享一个很好玩的提示语，来自支付宝。

2.商端订单管理的功能划分

最初我的设计是：把订单管理分成待处理的订单和所有订单，前者需要处理订单状态，后者只能查询历史，二者作为营业的两个子项列在侧边栏。但师姐的看法，如果历史订单包含待处理，那它就应当比待处理订单高一层级。

• 一种设计是，采用一级页面和二级页面的形式。
• 不好，这样跟其他几个菜单项不太协调，其他几个没有一级页面。
• 功能架构上没有包含吧，只是内容上的包含。如果我做查询操作，会希望我要找的都在这里。如果分开，可能发生我以为在A结果在B，我以为在B结果在A的情况。
• 这个问题其实可以用页面最上方的全局搜索框解决。
• 但历史订单包含待处理全部就有信息冗余的感觉。何况，更容易被查询的往往是进行中的订单，查询完了之后又很可能要操作。比如说客人说40分钟没收到餐要退款离开，商家搜一下然后发现没接单或者取消订单。
• 所以查询和处理完全分开不合适。
• 那么合用一个页面吧，然后在上方加一个tab做区分，在这里显示“待处理”、“已处理订单”和“全部订单”。这个页面既能搜索又能操作，对已完成的订单的操作只能查看。
  

3.菜品规格管理的问题

大部分规格是跟价格有关系的，例如大小份和配菜，例如奶茶加珍珠。规格还会组合，那商家要如何设置一个餐品的价格？

• 原先的设计是一个规格对应一个价格，这样好像没办法做组合。
• 采用基础价格+差价的模式，规格的每个选项指定差价，不需要定价的规格所有选项对应差价都可以置零。展示出来的价格可以是一个范围，只是这样的操作界面应当如何？
• 关键是让规格跟基础定价分开，并且是可选操作。
  
  

4.菜品排序需求

排序是我们在需求分析过程中漏掉的点。商端对菜品的展示是与小程序保持一致的，都是卡片，只是电脑屏宽，所以放了两列卡片。问题在于，两列的话容易困惑顺序是行优先还是列优先。

• 操作上允许拖动卡片进行排序。并且在卡片左上角标上序号。
• 还是不够明显。
• 支持一个快速编辑，采用列表的形式展现菜品，这样顺序就是自然的了。同时还可以把常用的几个编辑项放到这里，快速批量修改菜品信息。
• 菜品要不要像订单那样分页啊？
• 不分页的信息流更好～