从开发角度聊聊如何洞悉UI设计隐性需求.docx

优选 优选 PAGE / NUMPAGES 优选 从开发角度聊聊如何洞悉UI设计隐性需求 不想捂着脸求人改需求?来看看工程师怎么说在交互设计阶段如何发现思维盲区，减少开发与视觉的返工。今天从开发角度聊聊如何在需求确立和需求评审阶段洞悉隐性需求，无论是开发人员还是产品，都能用上! 俗话说，计划赶不上变化快，无论需求文档做得如何细致，考虑得如何周全，总会有些难以预料的需求变更在每天困扰着我们。开发人员苦恼，产品运营人员更苦恼，毕竟谁也不愿意捂着脸一遍一遍地求人改需求。 虽然世界充满未知的变化，但是有一些大的方向还是可以把握的，无论是产品运营还是开发人员，都可以在需求确立以及需求评审时多多考虑一下这些方面，相信一定可以减少一些后期的变更成本。下面这些内容主要是从开发人员的视角考虑的，多数基于个人经验，难免有失偏颇，不当之处还望指正。当然，如不嫌弃，感兴趣的产品和运营人员也可以稍作参考。 1. 细节变更需求 在项目初期，如果产品人员没有想清楚需求的细节，那么细节的变更可以说是无法避免的。那么作为开发人员唯一能做的就是，在设计程序结构和逻辑的时候，尽量预留出可扩展的能力。比如模块的增删、字段的增减、页面样式的微调等，除此之外也没什么好办法了，别灰心，这都不是事儿。 2. 跨平台需求 跨平台需求有时候来的非常隐蔽，往往最初规划的时候感觉可以先在一个平台尝试一下，比如先规划了PC端，但是PC端的某些功能又会忽然很急促的想移植到移动端。 而需求人员往往会想当然的认为功能差不多，只要挪一下就可以了(平移过去/拼过去)，或者是页面长的差不多，就改成移动端的大小就可以了(缩一下)。殊不知各个平台无论在架构部署，还是操作体验上都有着天壤之别，如果不提前规划好，那必然是个大坑。 3. 扩展需求 无论是什么样的业务，随着业务量的增长以及产品运营人员欲望的膨胀，都会催生出各种扩展需求。任何固定数量的，都会增加;任何单一需要的，都会变成多个。 比如页面上设计了三个商品推荐位，就要预留出变成六个、九个，甚至分页的能力。一个接口是给某个业务专用的，某天就可能变成通用的;一个简单的静态页面，某天就可能变成附带管理后台的复杂系统。对于扩展性需求要反复确认，不必过度优化，但也要留出合理的扩展空间。 4. 异常流需求 异常流需求往往容易被忽略，或者多有疏漏。常见的异常流有图片数据加载不出、图片不存在、接口挂掉、网速慢、未登录、登录态丢失、查询出错、查询无数据、内容溢出、用户输入溢出、用户输入非法、视觉遮挡不可用等等等等。 那么对应这些异常流情况，就要有配套的前端提示给用户，引导用户进行其他操作，这些异常流往往会在设计稿和文档中遗漏掉，比如各种异常提示浮层，需要登录态的操作，结果登录态丢失等等，都需要有对应的引导。 5. 内容运营需求 所有静态的内容都可能变成运营需求，静态广告位可能变成轮播广告位，轮播广告位可能变成需要运营后台填写数据，而不是直接写死在页面里，或者某一天可能变成从另外一个自动数据源拉取数据。 关于内容运营需求，评审初期可以确认好运营频次，如果是个把月才改一次的，几乎不耗人力的，那也没必要都搞工具。但是如果每天改一次，或者感觉运营内容的时间已经影响到正常的工作，或者远远大于写个工具的时间，那还是老老实实开发个运营工具吧。 6. 内容校验需求 上面既然说到运营工具了，那么作为运营工具一定是由运营人员自己来填写。既然是非技术人员填写，操作就难免要傻瓜一点，或者说非技术一点，尽量操作简洁并且可以校验输入。如果因为运营人员多打了个空格，或者多写个英文逗号系统就挂了，那这应该算谁不尽责呢? 还有能分别运营的字段要分别运营，因为有的时候虽然内容看上去是合在一起的，但是经常会有部分修改的需求，不如分开两个字段。比如广告位和埋点tag，可能经常换，但固定位置的tag值就不会换，所以分开运营会好一些。 7. 内容复用需求 运营的工作是很辛苦的，设想一下每天一边开着Excel，一边开着你的运营系统一个字段一个字段填写的时候，就知道画面有多美了。所以，运营填写的数据一定是有复用需求的，比如H5页面上运营的数据有可能还需要给原生App使用，甚至给PC端也用一套数据。一个广告图片和，可能被插入到多个页面的顶部或底部，一起更新多多沟通复用需求，可以随手拯救一大波运营。 8. 内容历史需求 既然运营这么不容易，那么工作量KPI如何衡量呢?这么辛苦再没人知道不是太惨了?所以，运营的数据一般是要有历史的。如果就一个坑位，每次都改掉内容来更新，上一次的就没了，那么鬼知道我一天改了多少次?一周做了多少次更新?当然，这里更偏向工具类的需求了，不过我重点要说的是，有运营需求，就可能有运营的历史记录需求。 9. 排序&打标需求 排序需求其实也是内容运营需求的一种，无论是运营填写的还是自动拉取的内容，