20240707 - 如何和所有的成员一起从无到有推进功能落地

中文版

English version see below 😀

这次的 Design Discussion 的主题是“一路走来困扰我的问题之如何和所有的工种一起从无到有推进 功能落地”。（本文中的“功能”用于指代 Feature）

工作中实际遇到的问题以及个人解决方案

讨论之前我先以我在工作过程中所实际碰到的问题以及我个人的解决方案作为引子：

• 如何清晰地传达设计
• 如何让每个人都知道当前的生产状态
• 如何让 QC 方便地知道测试流程
• 如何将参与制作的所有成员都凝聚到一起
• 如何方便地追踪进度

如何清晰地传达设计

• 关于如何清晰传达设计
  • 之前的项目一直用的是下列方案
    • Confluence - 设计呈现
    • Jira - 任务追踪
    • Excel - 任务倒计时
  • 好处
    • 非常结构化
  • 缺点
    • 可视化很弱
    • 难以知道你自己的工作与其他工种的工作之间的联系
      • 可能发生的情况是直接从 JIRA board 中拿出一个 jira 直接进行生产，其实并不了解这个东西会被用在什么地方，也不知道别的工种的工作如何与自己的这部分工作结合在一起
    • 很难以全局视角总览整个功能的实现情况

• 如何清晰传达设计
  • 受到 [[Stone Librande]] 的启发，我开始使用 One Page Design 来呈现设计
    • 可视化的方式使其能够更有效地传递信息
    • 比起纯文本而言更易读
    • 鼓励评论
  • 即将设计可视化地以卡片方式进行呈现

• 如何清晰传达设计
  • 其实就是将 Miro 引入了工作流中
    • Miro - all-in-one 的信息汇总处
    • Confluence - 信息存储，也便于搜索
    • Jira - 任务追踪
    • Excel - 任务倒计时
  • 好处
    • 可以方便地在一个地方查看所有信息
    • 有很好地可视化方案
    • 便于理解不同工种之间的工作内容的联系（后面会详细介绍）
  • 缺点
    • 对 PM 和 QC 提出了更高的要求（需要使用正确的 labels 对 jira 进行标注）
    • 手动维护成本比较高（所以引入了自动化的 jira-structure，后面会提到）

如何让每个人都知道当前的生产状态

• 如何让每个人都知道当前的生产状态
  • 有一段特定的生产时期中引入了每周的 QC smoke test
    • 让 QC 对功能的全流程进行测试，以发现问题
  • 引入了每周的评审会议（后来改进为了圆桌 playtest 的形式）
    • 圆桌 playtest 的形式可以让每个参与人员都以玩家身份对其进行体验，从而
      • 对功能全貌有所了解
      • 更容易提出反馈意见
      • 清楚地了解一些设计决策产生的原因

如何让 QC 方便地知道测试流程

• 如何让 QC 方便地知道测试流程
  • 引入了逻辑流程图以清晰定义预期操作和预期行为
  • 这不仅可以帮助 QC，也可以帮助参与设计的所有人都清晰了解设计如何被呈现

如何将参与制作的所有成员都凝聚到一起

• 如何将参与制作的所有成员都凝聚到一起
  • 之前的方法很难知道自己的工作是如何与他人的工作结合的（特别是对于 Designer 之外的工种，很容易出现前面提到的拿到 jira 就直接做的情况）
  • 由此引入了 LoQ-JobFamily 表
    • 左边的设计细节部分所呈现的本身就是对应 L3 阶段的情况
    • 这个表将对应设计细节的不同工种在不同 level of quality 级别下的目标进行拆分列出，由此可以让参与该部分的成员清楚知道自己的工作内容如何与他人的工作内容结合到一起

如何方便地追踪进度

• 如何方便地追踪进度
  • 引入了 jira-structure
    • 手动维护的成本比较高，所以使用 jira-structure 中的 auto filter 对相应的 jiras 进行自动化归类显示
    • 由此可以在 LoQ-JobFamily 表格中的对应位置来显示这部分的生产进度
  • 另一个好处在于在进行评审会议时，可以通过查看“最近 x 天关闭的 jiras”来方便地知道当前版本与之前版本的差异情况

快速总结

• 快速总结
  • 为了能清晰地传递设计
    • 引入了 One page design 的可视化呈现方法
  • 为了能够让每个人都清楚知道当前的生产情况
    • 引入了每周的 QC smoke test
    • 引入了每周的评审会议（后来改进为了圆桌 playtest）
  • 为了能让 QC 更好地知道测试流程
    • 引入了逻辑流程图以清晰定义预期操作和预期行为
  • 为了能将参与实现的所有成员凝聚在一起
    • 引入了 LoQ-JobFamily 表格，让大家知道自己的工作如何与他人工作结合在一起
  • 为了能更好地追踪生产进度
    • 引入了自动化的 jira-structure

理解合作的本质

• 理解合作背后的本质
  • 责任 & 参与
  • 沟通 & 迭代

责任 & 参与

• 理解合作背后的本质
  • 责任 & 参与
    • 设计师应该对设计负责
      • 这并不仅仅只是一句看似无用的废话，只有设计师真正对自己的设计负责，才有可能感染参与设计实现的每位成员，让他们一起对设计负责
    • 我个人的观点是每个人都拥有设计，设计师不过是推动其向前的助力
      • 诚然，是设计师将设计进行整合，但设计应该是属于每个参与者的，每个人都应该对其报以批判的眼光，而不仅仅只是瀑布式地接受任务并完成任务
    • 让所有实现人员参与设计本身使得所有人员都共享设计，对其做出贡献
      • 设计师应该在一切开始之前尽可能了解与该设计相关的所有背景，限制（limitation，即无法做什么事），局限（constraint，即在一定条件下才能做的事），并且向大家收集可能的方向（其实算是某种头脑风暴），之后基于此来产出设计初稿
      • 之后便进行生产实现
      • 组织大家进行 playtest
      • 基于 playtest 的结果对设计进行迭代，并不断重复以上步骤

沟通 & 迭代

• 理解合作背后的本质
  • 沟通 & 迭代
    • 设计不应该是瀑布式地，固定式的，而应该是基于 playtest 结果不断迭代的
      • 所有参与者在 playtest 时的感受都是真实的，都能够对改进设计提供帮助
      • 有时候可能需要做一些设计权衡，但每个参与实现的成员都应该清楚知道这背后的原因

要点

• 要点
  • 不断思考，不断学习
    • 不仅让思考结果能够让自己受益，应该尽量使得整条工作流上的其他成员也能受益
  • 设计师应该将大家凝聚到一起
    • 改进工作流能够让所有人都更加轻松
    • 了解别人的工作也能启发自己的工作
  • 拥抱 playtest 以及迭代式设计
    • 一起 playtest！
    • 迭代式开发不仅仅只是一种方法论，应该是一种思维
      • 这意味着需要不断挑战你（自以为正确）的假设
      • 拥抱失败
      • 并基于 playtest 的结果不断改进
    • 不应该将迭代看做是无谓的工作而感到沮丧，而应该将其视为改进设计的机会而感到兴奋！

不同工具流的特点对比

在之后我们更具体地讨论了不同工具流的特点：

• Feature Sign-off
  • 工具
    • Excel - 将设计以行为单位进行拆解
    • Jira - 任务追踪
  • 好处
    • 因为大家所用的形式都是一致的，区别只是在于细粒度的拆分，所以可以认为其保证了下限
    • 对于 programmer & qc 很友好，因为他们可以逐行进行实现/检查
  • 缺点
    • 难以维护
      • 特别是当功能变得复杂，以及要维护的东西越来越多时
    • 难以跨团队进行内容的检索
      • 因为所有的设计都被分开存储在不同的 excel 中，很难进行全局检索
    • 对于不同工种的颗粒度要求是一致的，这很不合理
      • 特别是对于设计而言，比如对于一些符合常识的设计，比如一只小狗需要其会游泳，可能大家大概都能想到最终期望的效果，但如果是从未见过的幻想生物的游泳行为，那可能就需要很多行才有可能较好地进行定义（而且因为很难进行可视化表达，很多细节可能会漏掉，只能通过口头传达）
• Web-based
  • 工具
    • Confluence - all-in-one 的设计呈现/储存方案
    • Jira - 任务追踪
  • 好处
    • 易于搜索内容
      • 得益于 confluence 内置的搜索工具，可以较为方便地以关键词进行搜索
  • 缺点
    • 可视化很弱
    • 难以知道你自己的工作与其他工种的工作之间的联系
      • 可能发生的情况是直接从 JIRA board 中拿出一个 jira 直接进行生产，其实并不了解这个东西会被用在什么地方，也不知道别的工种的工作如何与自己的这部分工作结合在一起
    • 很难以全局视角总览整个功能的实现情况
    • 页面内容变多之后加载会变慢，并且经常需要重新登录
    • 因为没有统一的模板，所以呈现的效果依赖于使用者
• One-page（可视化设计）
  • 工具
    • Miro - all-in-one 的信息汇总处
    • Confluence - 信息存储，也便于搜索
    • Jira - 任务追踪
    • Excel - 任务倒计时
  • 好处
    • 可以方便地在一个地方查看所有信息
    • 有很好地可视化方案
    • 便于理解不同工种之间的工作内容的联系（后面会详细介绍）
  • 缺点
    • 对 PM 和 QC 提出了更高的要求（需要使用正确的 labels 对 jira 进行标注）
    • 手动维护成本比较高（所以引入了自动化的 jira-structure，后面会提到）
    • 相较于 confluence 而言，可能跨文档搜索没有那么方便
    • 因为没有统一的模板，所以呈现的效果依赖于使用者

各工种成员对于新的工作流的反馈

• QC
  • 觉得 jira-structure 能够自动链接和更新对应 bug，不用在各个页面之间多次切换，非常方便
  • 并且 miro 中可以很方便地查看设计
  • 逻辑流程图只要熟悉之后就能比较方便地使用
• VFX
  • Miro 没有格式限制，并且编辑方便
  • 对于简单一些的功能，每周评审可能效果会好一些，因为可以比较快速地看到最新的进展，但对于更复杂一些的功能，可能评审时间需要调整
• VFX
  • 当前的 one page 版本有更好的全局视角
  • 并且基本不用在多个页面中频繁切换，体验要优于 confluence
  • 信息汇总之后也比较方便看
  • 比较喜欢圆桌 playtest 的形式，可以让大家都参与其中，并且能以不同的视角来看待自己的工作，应该让所有的参与者都在与会者有比较好的参会体验，而不是坐着看了一个小时之后拿到了一个新的任务，所以新的形式比较好
• Programmer
  • 没有特别的感觉
  • 更重要的是人与人在细节问题上的沟通
  • 文档更多是作为实现时的检查工具，如果忘记了才会看
  • 每周评审可以保证质量推进
  • 压力会来自于质量要求的更改
  • 可能并不一定适合每一个人
• Animator
  • 重要的是让更多人能够参与其中，一起圆桌测试是很好的形式
  • 并且希望 QC 能够更进一步作为 QA 来辅助设计的推进
  • 不应该只是领导参与会议，负责动画师甚至其他工种也应该参与 playtest，否则信息在传达过程中就会缺失
• Audio
  • 希望能够接到的是更场景化的和情绪导向的声音需求，而不是功能性描述——“希望在这里有一个声音能够吸引玩家注意”
  • 当前工作流可以让声音设计师更好地了解具体的应用场景和需求，有利于进行声音设计
  • 有时候感觉页面中的信息太多了，不知道从何看起

基于此所进行的讨论

• Q 有时候感觉页面中的信息太密集，希望能够改进信息的组织形式
  • 需要加入更显眼的开始视图，并辅以清晰的跳转链接来帮助导航
  • 不一定非要将内容平铺，也可以将内容以类似网页的形式进行组织（即更清晰的从上到下的结构）
• Q 设计师应该如何与多工种很好地进行合作，避免产生瀑布式的、任务分配式的设计
  • 这里其实前面在合作背后的本质部分提到了，设计师应该在基于设计意图的前提下充分与各工种成员进行沟通，从而尽可能达到双方所期望的结果，并且在实现之后基于测试结果进行迭代。因为每个成员都参与 playtest，所以他们能够清楚知道设计决策背后的原因，有时候甚至他们自己也可以提出改进建议
  • 并且这也是构建情感化游戏设计系统（Emotional Game Design System, EGDS）的必要性。Game Designer 提升的办法应该是让自己成为 Experience Designer，虽然可能没有办法在每一方面都做到对应工种的实现能力，但是应该要对各个工种都够提供的帮助都了然，这样既能够减少沟通成本，也能更好地推进设计
• Q 如何确定页面所要包含的内容的范围（比如是否要将所有相关内容都放在里面）
  • 在前面提到过，可以基于 Jira Epic 来创建 miro page，理想情况下当前页面中的所有信息都是直接由你负责的，并且是直接相关的。剩余一些虽然与之相关，但却不是直接负责生产的部分，可以在页面下方贴上外链，这部分内容主要是设计师用于追踪相关进度，不太需要耗费太多篇幅。
• Q 关于文档编辑权限
  • 理想情况下应该是共建的形式，但为了避免误操作，目前的形式是设计师进行维护，并且开放页面的评论权限，这样别的成员也可以方便地对页面信息进行评论，并由设计师进行维护更改
• Q 是否会增加设计师的工作量
  • 当前所做的其实是将原本 confluence 上的内容以 miro 进行呈现，如果要实现较好地可视化传达，其呈现难度确实会更高一些，但对于维护而言是更方便的
  • 这些信息本就需要被呈现，只是需要以良好的方式被组织起来
  • 未经转化的会议记录不应该直接成为文档内容的一部分，应该经过转化后成为页面的一部分
• Q 对于不同工种的成员，其阅读需求不一样，该如何满足
  • 文档最终服务于三种需求
    • 生产团队的需求
      • 大家需要知道自己所负责的部分是如何对功能产生贡献的
      • 并且最好能够知道自己所负责的部分如何与他人工作结合在一起，由此也可以激发创意
    • 使用团队的需求
      • 比如对于一个 ingredient，当关卡设计师阅读文档时比较关心的是“是什么”以及“怎么用”，他们并不用太知道当前的生产进度（设计师需要及时与使用团队更新当前进度以及迭代情况）。那么就需要基于这样的需求来将内容进行适当分割，比如提供“1 min overview (what and possible gameplay scenarios)”以及“how to use (metrics and tips)”部分以适应他们的需求。
    • 任何人都能接手的需求
      • 其实目标就是做到 self-explained
      • 应该提供具有实践价值的模板来帮助大家形成共识，从而更好地理解每个部分的作用

可以继续延伸的讨论话题

• 如何以恰当的形式进行 Playtest
  • 会上提到了 EOTA (Experience observation theory advice) 的方法
    • E - No discuss
    • O – what did you found
    • T – problems to be addressed
    • A – how to address
  • 对于不同类型的功能，其适合的 playtest 方法也不尽相同，以后需要对此进行详细讨论
• 如何成为更好的 game designer
  • 前面提到了一部分关于 experience designer 的部分，以后有机会可以更详细地展开

可能的新的设计呈现方式

① 为了提升可阅读性

• 提供巨大显眼的开始视图
• 提供可跳转的 table of content 脑图
• 提供 1min overview 以供人们快速了解这个功能（包含可能的玩法场景）
• 基于 jira epic 来创建新的页面（可以将相关 jiras 放在最下方）
  ② 为了帮助人们找到需要的信息
• 基于需求来切分内容模块（考虑谁会是读者）
  • 对于生产团队
    • 设计师会带着他们一起看整个设计，所以他们更关心的可能是 Logic Flow 部分
  • 对于使用团队（比如对于使用该功能的 Level Designer）
    • 理论上设计师也需要带着他们一起看整个设计，所以对于他们有用的可能是 How to use 部分
  • 为了让整个设计不言自明（以使得任何人能够接手）
    • 这个就需要设计师对 Design Detail 部分更好地进行呈现
    • 并且如果大家能够基于相同的模板来进行信息呈现，理解的成本就会降低
• 使用跳转链接来使得读者可以快速回到 TOC 部分
  ③ 为了更清晰地呈现信息
• 即 Design Detail 部分需要设计师很好地进行设计
  ④ 如何让 QC 清晰知道如何进行测试
• 即 Logic Flow 部分
• 希望不仅只是作为 quality control, 而是 quality assurance 来提升设计
  ⑤ 如何将参与制作的所有成员都凝聚到一起
• 引入 LoQ-JobFamily 表格，让大家知道自己的工作如何与他人工作结合在一起
  ⑥ 如何更好地追踪生产进度
• 引入自动更新的 jira-structure（使用正确的 labels 来实现这一点）
  如何让每个人都清楚知道当前状况
• （可选）引入每周的 QC smoke test
• 基于需要组织评审会议（比如圆桌 playtest）
  • 使用恰当的形式组织 playtest（并不是每个功能都适合使用圆桌 playtest 的形式）

感谢您的阅读，欢迎大家批评指正！

---

English Version

The theme of this Design Discussion is “Questions that bother me along the way: how to implement a feature from A to Z together with ALL job families”

Problems I met and how I resolve them

Before the discussion, I will start with the actual problems I encountered during my work and my personal solutions:

• How to deliver the design clearly
• How to enable everyone aware of current status
• How to enable QC to know the flow easily
• How to connect all job families together
• How to track production status

How to deliver the design clearly

• How to deliver the design clearly
  • Before, we use the following tools
    • Confluence - deliver the design
    • Jira - track the mission
    • Excel - jira epic countdown
  • Pros
    • Structured
  • Cons
    • Not good at visualization
    • Hard to make you aware of the connections between your work and others’ work
      • What may happen is that you take a jira from the JIRA board and start to implement directly, without actually knowing the context, where it will be used, or how others’ work will be connected with your work
    • Hard to track as a whole picture

• How to deliver the design clearly
  • Inspired by [[Stone Librande]], I start to use One Page Design to deliver my design (i.e., to visualize your design with the format of cards)
    • Visualization makes it be more efficient on delivering info
    • Easier to read compared with pure text
    • Encourage comment

• 如何清晰传 How to deliver the design clearly
  • I introduce Miro into the workflow
    • Miro - all-in-one place to check info
    • Confluence - storage, and facilitate the search across teams
    • Jira - track the mission
    • Excel - jira epic countdown
  • Pros
    • Convenient to check at one place
    • Good visualization
    • Easy to understand the connections between all job families
  • Cons
    • More requirements for PM and QC to use correct labels
    • Manual maintain takes time (so we introduced auto update jira-structure)

How to enable everyone aware of current status

• Introduced weekly QC smoke test during a specific production period
  • Let QC test the entire process of the feature to find problems
• Introduced weekly review meetings (later switched to roundtable playtest)
  • The roundtable playtest allows everyone involved to experience it as a player, so that they could
    • Get a full picture of the feature
    • Provide feedback easily
    • Clearly understand the reasons for some design decisions

How to enable QC to know the flow easily

• How to enable QC to know the flow easily
  • Introduced a logical flow chart to clearly define expected input and expected output
  • This not only helps QC, but also helps everyone involved in the design to clearly understand how the design is presented

How to connect all job families together

• The previous method made it difficult to know how everyone’s work was combined with the work of others (especially for job families other than Designer, it was easy to only do the work directly after getting the jira as mentioned above)
• The LoQ-JobFamily table was introduced
  • The design details on the left itself correspond to the situation at the L3 stage
  • This table lists the goals of different jobs at different levels of quality corresponding to the design details, so that members involved in this part can clearly know how their work is combined with the work of others

How to track production status

• How to track production status
  • Introduced jira-structure
    • The cost of manual maintenance is relatively high, so the auto filter in jira-structure is used to automatically classify and display the corresponding jiras
    • This allows the production progress of each part to be displayed in the corresponding position in the LoQ-JobFamily table
  • Another benefit is that during the review meeting, you can easily know the difference between the current version and the previous version by viewing the “jiras closed in the last x days”

Quick summary

• To clearly communicate the design
  • Introduced the visual presentation method of One page design
• To enable everyone to clearly understand the current production situation
  • Introduced weekly QC smoke test
  • Introduced weekly review meetings (later switched to roundtable playtest)
• To allow QC to better understand the test process
  • Introduced a logical flow chart to clearly define expected inputs and expected outputs
• To bring all members involved in the implementation together
  • Introduced the LoQ-JobFamily table to let everyone know how their work is combined with others’ work
• To better track production progress
  • Introduced an automated jira-structure

Understand the core behind the collaboration

• Responsibility & Participation
• Communication & Iteration

Responsibility & Participation

• Understand the essence behind collaboration
  • Responsibility & participation
    • Designers should be responsible for their designs
      • This is not just a seemingly useless nonsense. Only when designers are truly responsible for their own designs can they inspire every member involved in the design implementation and let them be responsible for the design together
    • My personal opinion is that everyone owns the design, and designers are just the driving force to push it forward
      • It is true that designers integrate the design, but the design should belong to each participant, and everyone should be critical of it, rather than just accepting and completing the task in a waterfall manner
    • Let all implementers participate in the design itself so that all people share the design and contribute to it
      • Designers should try to understand all the background, limitations (i.e., what can’t be done), constraints (i.e., things that can only be done under certain conditions) related to the design before everything starts, and collect possible directions from everyone (a kind of brainstorming), and then produce the first draft of the design based on this
      • Implement
      • Organize everyone to playtest
      • Iterate the design based on the results of playtest, and repeat the above steps

Communication & Iteration

• Understand the essence behind cooperation
  • Communication & iteration
    • Design should not be waterfall-like or fixed, but should be continuously iterated based on playtest results
      • All participants’ feelings during playtest are valid and can help improve the design
      • Sometimes some design trade-offs may be required, but each member involved in the implementation should clearly know the reasons behind them

Takeaways

Comparisons between different workflow

Later we discussed the pros and cons of different tool flows in more detail:

• Feature Sign-off
  • Tools
    • Excel - Break down the design line by line
    • Jira - Task tracking
  • Props
    • Because everyone uses the same format, so it can be considered that it is friendly to less-experienced designers
    • Very friendly to programmers & qc, because they can implement/check line by line
  • Cons
    • Difficult to maintain
      • Especially when the feature becomes complex and there are more and more things to maintain
    • Difficult to retrieve content across teams
      • Because all designs are stored separately in different excels, it is difficult to do global retrieval
    • The granularity requirements for different job families are consistent, which is unpractical
      • Especially for design, for some designs that conform to common sense, such as a puppy needs to be able to swim, everyone may be able to think of the final desired results, but if it is the swimming behavior of a fantasy creature that has never been seen, it may take many lines to define it well (and because it is difficult to express visually, many details may be missed and can only be communicated verbally)
• Web-based
  • Tools
    • Confluence - all-in-one design presentation/storage solution
    • Jira - task tracking
  • Pros
    • Easy to search for content
      • Thanks to the built-in search tool in confluence, you can search by keywords more easily
  • Cons
    • Not good at visualization
    • Difficult to know the connection between your work and others’ work.
      • What may happen is that you take a jira directly from the JIRA board and directly implement it, but you don’t actually know where this thing will be used, nor do you know how the work of others’ work is combined with yours
    • It is difficult to have a global perspective on the implementation of the entire feature
    • The page will load more slowly when the content grows, and you often need to log in again
    • Because there is no unified template, the presentation results depends on the designers
• One-page (visual design)
  • Tools
    • Miro - all-in-one place
    • Confluence - Information storage, also easy to search
    • Jira - task tracking
    • Excel - jira epic countdown
  • Props
    • Convenient to check at one place
    • Good visualization
    • Easy to understand the connections between all job families
  • Cons
    • More requirements for PM and QC to use correct tags
    • Manual maintain takes time, need automation setting
    • Can not search content from other teams directly
    • Depends on the user, could make it good or bad

Feedbacks from different job family members

• QC
  • Jira-structure can automatically link and update the corresponding bugs, without switching between pages many times, which is very convenient
  • And miro can easily view the design
  • As long as you are familiar with the logic flow chart, you can use it smoothly
• VFX
  • Miro has no format restrictions and is easy to edit
  • For simpler features, weekly reviews may be more effective because you can see the latest progress easily, but for more complex features, the review time may need to be adjusted
• VFX
  • The current one page version has a better global perspective
  • And basically there is no need to switch frequently between multiple pages, the experience is better than confluence
  • It is also easier to read after the information is put together
  • I prefer the round-table playtest format, which allows everyone to participate and look at their work from different perspectives. All members should have a better experience as participants, rather than sitting and watching for an hour and then getting a new task, so the new format is better
• Programmer
  • No special feeling
  • What is more important is the communication between people on details
  • Documents are more of a checking tool for implementation, and I will only look at them if forget
  • Weekly reviews can ensure quality progress
  • Pressure comes from changes in quality requirements
  • It may not be suitable for everyone
• Animator
  • It is important to allow more people to participate, and roundtable testing together is a good form
  • And I hope that QC can go a step further as QA to assist in the advancement of design
  • It should not be just the leaders who participate in the meeting, but the animators and even everyone involved should also participate in the playtest, otherwise the information will be lost in the communication
• Audio
  • I hope to receive more scenario-based and emotion-oriented sound requirements, rather than functional descriptions - “I hope there is a sound here that can attract the player’s attention”
  • The current workflow allows sound designers to better understand the specific scenarios and requirements, which is conducive to sound design
  • Sometimes I feel that there is too much information on the page and I don’t know where to start

Discussions based on this

• Q Sometimes I feel that the info on the page is too dense, and I hope to improve the organization of the information.
  • A more prominent start view needs to be added, supplemented with clear jump links to help navigation
  • It is not necessary to lay out the content flat, and the content can also be organized in a web page-like format (i.e. a clearer top-to-bottom structure)
• Q How should designers work well with all job families to avoid waterfall-style, task-oriented designs?
  • This is actually mentioned in the previous section on the core behind the collaboration. Designers should fully communicate with members of different job families based on the design intent to achieve the results expected by both parties as much as possible, and iterate based on the playtest results after implementation. Because each member participates in playtest, they can clearly understand the reasons behind the design decisions, and sometimes they can even make suggestions for improvement themselves.
  • This is where the needs of creating the Emotional Game Design System (EGDS) comes from. The way a Game Designer grows is to become an Experience Designer. Although it may not be possible to as capable as other job families in their expertise, designers should be clear of the help that others can provide. This can not only communicate efficiently, but also have better chance to improve a design.
• Q How to determine the scope of the content to be included in the page (such as whether to put all related content in it)
  • As mentioned earlier, you can create a miro page based on Jira Epic. Ideally, all the information on the current page is directly related and belongs to you. The remaining parts that are related but not your team is not directly responsible for production can be posted as external links at the bottom of the page, this part of the content is mainly used by designers to track related progress and does not need to take up too much space.
• Q Regarding document editing permissions
  • Ideally, it should be a collaborative page, but in order to avoid miss-editing, current way is for designers to maintain and grant the page comment permissions, so that other members can also easily comment on the page, and the designer can maintain and iterate it.
• Q Will it increase the workload of designers?
  • What we are doing now is actually presenting the original content on Confluence in Miro. If we want to achieve better visual communication, the presentation difficulty will be higher, but it is more convenient for maintenance.
  • Info needs to be presented one way or another, but it needs to be organized in a good way.
  • Unconverted meeting recap should not be directly be part of the page content, but should be converted first
• Q Different job families have different needs, how to handle this?
  • There are three needs
    • The needs of the production team
      • Everyone needs to know how their work contributes to the feature
      • It is also better to know how their work is connected to others’ work, which can also inspire creativity
    • The needs of the user team
      • For example, for an ingredient, when the level designer reads the document, they are more concerned about “what is it” and “how to use it”. They may don’t need to know too much about the current production progress (the designer needs to update the current progress and iteration status with the user team timely)
      • Then it is necessary to divide the content appropriately based on such needs, such as providing “1 min overview (what and possible gameplay scenarios)” and “how to use (metrics and tips)” sections to meet their needs
    • The need for anyone to take over
      • In fact, the goal is to be self-explained
      • Templates should be provided to help everyone reach a consensus and better understand the role of each part.

Other topics may be extended in the future

• How to do playtest in an appropriate way
  • The EOTA (Experience observation theory advice) method was mentioned in the meeting
    • E - No discussion
    • O – what did you find
    • T – problems to be addressed
    • A – how to address
  • Different type of features have different suitable playtest methods, which need to be discussed in detail in the future
• How to become a better game designer
  • A part about experience designer was mentioned above, and this is to be discussed in the future

A possible new workflow

① To improve readability

• Provide a large and eye-catching start view
• Provide a table of content mind map that can be used for navigation
• Provide a 1min overview for people to quickly understand this feature (including possible gameplay scenarios)
• Create a new page based on jira epic (you can put the relevant jiras at the bottom)
  ② To help people find the information they need
• Split the content based on needs (consider who will be the reader)
  • For the production team
    • The designer will walk them through the design, so they may use the Logic Flow part heavily
  • For the user team (such as the Level Designer who uses this feature)
    • In theory, the designer also needs to walk them through the design, so the How to use part may be useful to them
  • To make the entire design self-explanatory (so that anyone can take over)
    • This requires the designer to better present the Design Detail part
    • And if everyone can present information based on the same template, the cost of understanding will be reduced
    • Use jump links to allow readers to quickly return to the TOC part
      ③ To present information more clearly
• That is, Design Detail part requires good presentation
  ④ How to let QC know how to test clearly
• That is, the Logic Flow part
• Hope to involve them not only as quality control, but also as quality assurance
  ⑤ How to bring together all members involved in the production
• Introduce the LoQ-JobFamily table to let everyone know how their work is connected to others’ work
  ⑥ How to track production
• Introduce an automatically updated jira-structure (use the correct labels to achieve this)
  How to let everyone know the current status clearly
• (Optional) Introduce a weekly QC smoke test
• Organize review meetings based on needs (such as roundtable playtests)
  • Organize playtests in an appropriate form (not every feature is suitable for the form of roundtable playtests)

Thanks for your watching, looking forward to your comment 😀