产品设计的实现思路与技术思考

在设计原型和UI时我们经常会有开发抱怨实现困难，效果与设想相差巨大等等，那么如何避免这些开发中会遇到的坑，以及如何与开发更好的沟通，下面结合下自己工作中的几个案例说一下。

案例一：手机H5的加载动效

实现效果如下

业务背景：这是一个涉及到业务办理的加载动画，需要调取多个外部api，所以加载的时长在10s左右。因为是金融类APP所以需要一个生动但不是特别活泼的加载动画。

后台逻辑：后台需要访问外部所有api结束后才能返回结果，但后台可以每隔2-3秒告诉前端仍在进行中或者后台失败。

设计思路：
1.这是个长加载的效果，用户需要等待很久且行业特性需要显得比较严谨。因而为了消磨用户等待中的耐心，需要有一定的进度上的反馈，但后台无法反馈真实的进度值，所以需要前端做一定的处理去模拟加载的进度。

2.那么如何去模拟这个进度反馈呢？因为加载的时间在10s左右，所以将进度条分成三段。第一段为0%-80%，这一段时长为8s，在这段时间内动画会做匀速运动，如果后台在这段时间内返回成功则运动加速直接到100%然后跳转成功页面，如果返回失败则直接跳转失败页面。第一段动画结束后台仍未返回值则进入第二段动画，第二段进度条为80%-90%，时长为2s，此时也为匀速动画但速度较为缓慢，用户以及已经等待了一段时间此时速度变慢但仍然会继续等下去。正常情况下后台在此时就会返回成功或者失败，如果此时仍未成功则进入第三段，第三段动画为减速运动，最终会在99%处停止，当然现实中几乎不会有这种情况，在运动停止之前就会返回值或者服务器报错。

3.只有一个进度条略显无聊所以在动画中又加入了一个不断刷新页面的电脑屏幕的效果，使得动画变的更为生动。

案例二：首页配置与活动配置后台设计

业务背景：APP上线需要首页模块均可配置，这样方便运营根据不同的推广方向去设计不同的首页。根据业务的需要设计出，SKU模块、图片模块、商户模块、

后台逻辑：后台会根据配置的内容加载出不同的模块，后台需要获取的数据有：
1.配置的模块类型；2.配置的内容；3.模块间排列的顺序；4.模块list一次刷新加载的数量；5.模块加载时栏位的宽高。
其中134是根据配置后台可以获取到的，2和5需根据模块的不同做不一样的处理，有些模块如商品模块可以直接调取后台中商品的图片和链接。有些模块如图片模块需要后台先读取图片的宽高然后返回比例给前端计算出占位栏的高度。

设计与前端实现：
1.因为模块是自由组合的，所以在做UI时一定要统一好各个模块之间的间距并给出设计规范，使不同的模块在不同顺序下显示出统一的UI效果。（PS：设计UI使需将各个模块考虑成一个盒子的模型，具体可以参考下css的盒式模型）

CSS盒式模型

2.加载状态显示，页面进入加载状态时计算出占位栏的框高，传统网页体验较差的有一点就是因为传统网页加载图片时，图片栏位的宽高会有所变化导致页面会有抖动。因而在设计list加载时给出了加载的占位栏，这个占位栏的宽高也应当与加载完成后栏位的宽高一致。

3.标题模块的设计，标题模块中有主标题和副标题，其中主标题不填写则不显示，填写主标题则可以填写副标题。UI需要明确模块中标题元素与上线元素之间的间距，当标题不现实时UI的显示，只显示主标题时的显示和主副标题都显示时的情况都需要考虑。

UI标注信息

案例三：长图片加载效果

业务背景：商品详情页的详情图片加载速度较慢，需要优化。往两个方向入手1.压缩图片的尺寸2.设计加载的状态缓解优化等待时间

后台逻辑：1.后台需将图片做压缩处理，目前已经有很多现成的压缩图片的工具，可以参考这些工具的代码实现逻辑；2.加载过程中想做出从模糊到清晰的效果，需要后台生成一个原图片缩小到极小尺寸的图片。

设计与前端实现：进入页面后页面开始加载图片，前端先从后台获取图片的宽高渲染出占位栏的大小；之后载入后台生成的极小尺寸图片，图片覆盖在占位栏上之后给图片加上毛玻璃的模糊效果；此时后台一直在读取大图的数据，大图片先隐藏加载完成后将占位栏的小图片图换成大图并去掉模糊的滤镜。这样就实现了大图加载的从清晰到模糊的加载样式。

参考medium加载的样式

案例四：商品库存处理

业务背景：电商平台SKU的简单库存处理

实现逻辑：1.确定库存的状态为可销售库存、锁定库存、已销售库存、活动库存；2.确定在不同状态下对库存的操作，操作有增加库存、锁定库存、解锁库存、扣减库存、返还库存。当用户下单时应当锁定库存，如果用户取消则解锁库存，用户支付成功扣件库存，用户退款则返还库存。同时做活动时也应当拥有活动库存，活动库存应当小与相关联的商品库存。

库存状态的简单流程

当然在实现中会有许多细节性的问题，比如：1.我们平台有优惠券的功能，那么如果优惠券金额大于商品金额则订单价格为0元，因此这种情况下提交订单即为支付成功，此时应为扣件库存的流程；2.平台刚上线时用户不多，做一些活动时需要在页面需要营造出用户大量购买的情况，因此需要在后台可配置商品的虚拟购买量而虚拟购买是不扣库存的；3.打包商品的库存处理，当多个商品打包成一个权益时，权益的库存于商品库存的关系，权益库存默认应当小于所有商品中库存最少的那个，但如果权益的库存超出其中某些商品的数量则对应的商品不发放，但在设计页面时应当明白的告诉用户限额领取的规则。

总结

当你作为一个产品设计师在一个开发资源不是那么丰富团队中，你需要权衡下实现的成本，这样就需要多和开发沟通了解下实现的细节和原理，从而将自己手中的牌打出最优解