我负责产品的前期调研、交互设计以及协调各方资源推进项目落地。
向领导申请人工智能的研发资源，通过用户访谈挖掘使用痛点，通过竞品分析思考设计突破点，独立完成交互设计，协调开发、设计资源推进可用性测试、开发。
魔形简介
魔形是一种基于主视觉自动化生成周边延展资源的智能编辑器，旨在提高延展资源的输出效率，降低设计人力成本。
项目背景
产品会配合节日或赛事推出活动，需要设计活动的主视觉及其周边的延展资源（例如 Banner）
延展资源基于主视觉通过简单的排版完成输出，属于「劳动密集型」的工作，难有创意发挥的空间。
- 延展资源的需求多且要求快速响应：目在运营工作中存在很多需快速相应的美术相关业务（如热点时事物料输出等），针对该环节设计往往需要投入较多时间，无法满足运营诉求
- 投放渠道多样，消耗人力：一般情况下，美术部门设计输出业务所需的 Banner 为标准尺寸，但实际投放需要针对渠道的差异，对同一个 Banner 制作数十个不同尺寸的需求，较为消耗美术人力
预期效果
- 节省人力：预计节省 0.5人天 / 物料延展
- 提升运营物料响应速度与质量：业务方可半自主快速&高质量产出美术物料，提升运营投放效率
我的行动
制定产品目标
合成算法
正如项目背景中所描述，产品最重要的是提高设计输出的效率，从而节省人力，所以合成算法是产品需要完善的核心体验。
编辑体验
算法无法做到万能，此时需要通过人工对合成后的效果进行微调从而达到预期目标，所以编辑体验也是非常重要。
我在制定产品目标选择设计方案上犯了 2 个重要的错误。
犯错一：
合成算法方面，采用了「人肉智能」（而不是人工智能）的策略，通过自行观察、与视觉设计师讨论的方式总结延展资源的设计规律，并将规律数据化提供给技术同学用于开发合成逻辑。
采用了固定、死板的算法面对简单场景时还能胜任，但测试过程中逐渐发现难以应对真实、复杂的场景。
发现问题后，我向公司内部申请了人工智能的技术支持，全面将合成的逻辑交由机器学习完成，为未来产品的质量和适应能力奠定基础。
对于技术、设计材料需要有完备的知识和应用意识。
犯错二：
前期将精力集中在合成算法上，忽视了编辑体验；在第一版上线后效果不尽人意，通过反思发现，合成算法的优化属于长期目标，短期内难以达到合成后可以直接使用的效果，所以重要还是要依赖编辑功能实现用户目标，所以短期目标要以编辑体验为主。
意识到产品重点的设置错误后，随即调整了方向加大编辑体验的投入力度。
长期目标固然重要，但不要忽视了短期目标的实现。
交互设计
梳理前后端数据传输规则
产品需要解析 PSD 文件用于后续的处理，前后端使用不同的库处理 PSD 文件，需要制定统一的数据读取、解释标准用于后续的数据交互。
和技术沟通了解到前后端分别使用的 PSD 解析库后，我了解了对应库的逻辑，并安装试用库的基本功能，结合对 PSD 文件及需求的理解，梳理了前后端数据传输规范，协助技术同学完成开发。
使用蚂蚁组件快速搭建
可用性测试
由于产品的目标用户是设计师群体，而在公司内部非常容易接触到这类群体，于是进行了小范围的可用性测试；通过 FIgma 输出简单的可交互原型测试目标用户对于方案的理解，测试设计模型与用户心智模型的匹配程度。
在产品编辑的流程中，用户需要对人工智能合成的方案进行打分（打分帮助算法进行迭代），在可用性测试中发现用户对此流程存在疑惑（打分是产品需求而非用户需求），产生包括不知道要打分，从哪里打分，为什么要打分等疑问。
基于上述发现，完成了方案的优化，清晰了打分的指引以及整体流程的感知，帮助用户了解产品的使用流程。
方案概览：
推动落地
邀请设计同学进行测试反馈
初版上线后，需要用户基于真实的使用场景进行使用，持续与用户沟通了解问题思考优化方向；另一方面用户的使用反馈对产品团队来说就是很大的鼓励（我们都希望产品被用户使用、喜爱）。
经过内部协调后很快安排了 PM 与视觉设计师同学参与试用，制定了 100 个 PSD 的使用计划。
过程中我们发现了许多可用性问题，梳理了问题清单；持续与用户沟通，并且以天为单位在项目群中同步用户反馈，最终将 100 个 PSD 输出的 400 多份延展资源作为产品首版的试用成果，鼓舞了团队的士气。
通过数据推动方案开发
PSD 中存在多种图层类型，包括文字、群组等，需要工程师针对不同类型进行适配。
其中就遇到了由于 Group 类型的图层未进行适配而导致的 PSD 文件上传失败的问题；由于不清楚此类图层在实际设计场景中的使用频率，技术工程师对于适配的价值缺少信心。
为了更好的验证解决问题的价值，我通过 Python 分析了团队一整年的设计源文件，通过 Python 的 psd-tools 模块读取了 PSD 中的图层类型进行统计，发现 Group 图层的占比并不低（18%）。
基于客观的数据，最终证明了解决问题带来的客观价值，和工程师一起解决了这一问题。
最小可行性
由于团队本身有主线业务需要支持，魔形编辑器的优先级相对较低，在项目推进过程中总是很难获得开发资源。
为了推动项目，帮助工程师可以利用主线项目的间隙进行「碎片化」工作，我先后将产品规划从季度一直细化到天为维度，从功能模块细化到每一个 Bug、优化点的优先级。通过拆解任务，一方面让整个产品的开发难度看起来简单了一些，也有利于提升产品的迭代速度（以小点为目标，而不是以大功能为开发目标）。
总结
相比交互设计工作中思考「如何让体验更好、如何实现业务目标」 ，在主持魔形的产品开发过程中，会更加侧重开发资源的合理利用 ，更多的思考如何让项目更快推出「能用」的版本。
过程中也出现了前期按照交互设计思维设计尽可能完美的产品，到了开发阶段从产品角度开始砍需求让版本迭代速度更快。
这是一种思维方式的转换。
对于后续工作的启发是，需要前期提前规划好需求的必要性和性价比、优先级，避免后续再砍需求造成前期的投入浪费。此外任务优先级尽可能拆分的细一些，例如先分不同版本，根据需求优先级放置到对应版本中，同一个版本内再细分优先级，通过这样的方式最小化、再小化的降低项目推进的阻力。
最后，感谢这么长时间一直挤出时间来支援产品工作的各位同仁以及提供各种支持的同事 🌻