4.3.4. 故事编写工作坊

故事编写工作坊

故事编写工作坊是开发人员、用户、产品和其他对编写故事有帮助的人共同参加的会议

在工作坊期间,参与人员编写尽可能多的故事,此时不对故事排优先级。

正确举办故事编写工作坊可以非常快速的编写大量故事。良好的故事编写工作坊结合了头脑风暴的最佳要素和简单原型法。可以把一个简单原型画在纸上,笔记本上,白板上,并画出软件内部高层之间的交互。在工作坊中,随着参与者对用户在使用软件过程中可能要做的事情进行头脑风暴,不断构建原型。这并不是像传统原型法或联合应用设计中,要确定实际界面和字段,只是为了从概念上确定工作流

故事与简单原型

比如,下面就是通过故事编写工作坊整理的招聘网站的简单原型。

招聘网站简单原型

其中:

  • 每个方框代表着网站的一个新组件
  • 方框中带有加粗的文字是组件的标题
  • 标题下面是组件要做的和包含的列表
  • 方框间的箭头标示组件间的链接

对于一个网站,组件可能是一个新的页面或当前页面的一块区域。所以,每一个链接意味着弹出一个新页面或者在同一个页面上显示信息。

比如,搜索工作可能是一个页面或者首页上的一块区域。

开始画原型前,首先要决定从哪种用户角色开始。需要用每个角色来重复这个过程,不论什么顺序。然后,画一个空的方框,告诉参与者这是软件的主界面,询问他们当前这个用户角色能在这个界面做什么。即使你现在还不知道主界面是什么,有什么用,这也没有关系。参与者会想出角色会做什么。对角色做的每一件事情,画一条指向一个新的方框,然后写一个故事。

比如上面的图,我们可以得出以下故事:

  • 求职者可以发布他的简历
  • 雇主可以发布工作
  • 求职者可以搜索工作
  • 求职者可以看到搜索条件的工作
  • 求职者可以看到指定工作的详细信息

这些故事都不需要界面是该如何设计。但是,走一遍流程可以帮助大家想出尽可能多的故事。

我发现深度优先的方法最有效

对于第一个组件,写下主要的细节,接着是与第一个组件相连的组件B,一样写下其主要的细节。然后是与B相连的组件,而不是回到第一个组件A,描述其他与A相连的组件。

广度优先的办法非常不容易理解,因为很难记住自己刚才在哪条功能线上

另外,我们要尽快扔掉简单原型

在画好简单原型后的几天内,一定要扔掉或擦掉它、
原型并不是开发流程中的一个长期工件,因为长期留着可能会导致不必要的困惑。
如果觉得在故事编写工作坊中还有发现所有故事,可以把原型保留几天,再看看是否还能写出一些漏掉的故事,然后再考虑扔掉它。

在画原型的过程中,问一些有助于找到遗漏故事的问题,示例如下:

  • 用户接下来最有可能做什么?
  • 用户会在这里犯什么错误?
  • 在这里,用户会有什么困惑?
  • 用户需要什么额外的信息?

    在问这些问题是,考虑一下当时用户的角色。许多答案都和用户当时角色有关

    原则

    在故事编写工作坊期间,我们有一些工作的原则需要大家都了解并且遵守

  1. 应该把重点放在数量上,而不是质量上。
  2. 即使最后会用电子方式保存故事,但在工作坊里最好还是使用卡片。
  3. 只需把想法记录下来就行。最初大家觉得不好的故事经过几个小时后可能会变得很棒,或者会激发我们相处其他故事。
  4. 不要为每个故事都陷入长时间的讨论中。
  5. 如果一个故事是多余或者能被更好的故事替换,就扔掉这个故事。

    小技巧

    另外,还有一些小技巧能够让工作坊进行的更加顺利。

  6. 可以维护一个待办问题列表,将一些当前不是最重要的故事记录其中,留着以后再来解决。

  7. 如果我们卡在某个点过不去,这时不妨看看竞争对手的产品或类似的产品。
  8. 留意在工作坊中成员的贡献。有些参与者在大部分或者整个期间都保持沉默,可以在中间休息的时候和这个参与者谈谈,确定他并不是不适宜这个过程。要让参与者觉得大家只是在记录而不是评价故事,会更乐于参与。

    最后,再次重申故事编写工作坊中的讨论应该在较高层面上。我们的目的是在短时间内写出更多的故事。这不是设计界面或解决问题的时候。