13、面向组织变革的界面设计：组织符号学方法

面向组织变革的界面设计：组织符号学方法

1. 引言

在组织中，计算系统的真正价值并非技术本身，而是其提升组织绩效和效率的能力。因此，软件系统应被设计为整个组织的一个集成部分。由于组织处于不断发展变化中，技术信息系统也应随之改变，以与组织的非正式和正式系统保持一致。

技术信息系统的变更往往伴随着高昂的成本，软件产品的维护成本可能远超其初始开发成本。为了让软件产品能随组织发展而演变，我们需要一种可行的机制。一种可能的解决方案是使用高级语言，以便在无需更改代码的情况下对软件产品进行修改。本文将提出一种为计算机支持的协同工作（CSCW）系统构建用户界面的方法，以适应组织的变化。

根据Grudin的观点，不是组织去适应群件系统，而是系统必须适应组织的实践。CSCW系统应融入组织信息系统，尊重工作场所建立的社会规范。为了建模和理解社会背景，CSCW领域融合了认知和社会心理学、面向工作的社会学和人类学等多种学科。

已有研究表明，要构建合适的CSCW系统，就必须理解组织背景。然而，即使在系统设计期间，组织也在不断发展。此外，竞争市场促使组织不断改进其工作实践，这些变化通常会产生社会影响，CSCW系统需要适应新的组织环境。本文将展示一种基于组织符号学（更确切地说是语义和规范分析）的架构和方法，以支持系统设计和使用过程中的组织变革。

为了应对组织中系统设计的复杂性问题，我们提出将系统架构分为两部分：静态部分和动态部分。静态部分包含受组织变革影响可能性较小的元素，对应Sommerville所说的“持久需求”，例如医院始终需要医生、护士等；动态部分则更易发生变化，对应“易变需求”，如医院的医疗政策相关需求。

语义分析用于构建系统的第一部分，它能生成组织的稳定模型，并将语义模型转化为面向对象的实现模型。在语义分析中定义本体图时，会应用到可供性理论，在这种视角下，对象被理解为代理行为的集合，而非具有一组属性的独立事物。规范分析则用于指定组织的语用和社会层面的方面，通过所提出的架构，规范与CSCW系统界面的多个方面相关联，当规范发生变化时，系统可以进行修改，以支持组织在系统使用过程中语用和社会层面的变化，这些更改由界面工程师通过界面配置环境（ICE）完成，无需直接进行代码维护。

2. CSCW研究与不断变化的系统

寻求在使用过程中修改CSCW系统的替代方案的主要动机之一，是社会群体的动态性质。在这些群体中，行为模式通常会随时间变化，新成员也在不断加入。从组织符号学的角度来看，我们处理的是在社会环境中不断互动、相互影响的代理群体。

CSCW研究界一直在探索各种替代方案，以确保系统在开发完成后仍能满足用户需求。这些方案包括设计灵活的CSCW系统、为意外使用进行设计以及设计可定制的CSCW系统。

“定制”可理解为“在使用环境中修改计算机应用程序的活动”。然而，群件系统的定制提出了一系列问题，例如：
- 哪些群体流程和工作文化允许并鼓励参与者进行定制？只有当定制成为工作流程的一个组成部分时，所有参与者的成功定制才有可能实现。
- 如何进行协作定制？在协作工作环境中，影响多个参与者的定制步骤必须由所有受影响的人执行或达成一致。
- 在群件的不同领域，我们是否需要不同类型的定制机制？
- 如何将人机交互（HCI）领域的发展成果应用于实现定制支持？
- 一般用户界面和用于定制群件的用户界面之间有哪些共性和差异？
- 如何在定制支持中纳入权利和限制？当定制可能影响整个工作小组时，有必要为定制行动定义约束条件，那么由谁来定义和定制这些约束条件呢？
- 需要什么样的系统架构来允许在系统使用过程中进行定制？定制机制如何集成到系统中？
- 在初始开发过程中，如何考虑多样化和动态的需求，即如何确定未来应用程序的可定制点和可定制程度？

可定制系统的研究通常假定用户应负责定制任务。Morch确定了终端用户定制的三个层次：
- 定制：终端用户可以设置各种配置选项的参数。
- 集成：终端用户可以通过预定义组件为应用程序添加新功能。
- 扩展：终端用户通过添加新代码来改进应用程序的实现。

尽管终端用户定制有一些成功的应用案例，但让终端用户修改系统以适应因规范变化而带来的复杂社会变化，仍是一个远未解决的问题。因此，为了获得即时的实际效果，本文提出一种架构，使界面工程师能够更轻松、经济地修改系统。我们认为，终端用户接近他们的工作领域，他们的专业知识应在系统修改的定义中得到考虑；同时，界面工程师关于技术和建模的专业知识在复杂系统修改中也很重要。在本文提出的方法中，界面工程师和终端用户应共同合作对界面进行更改，通过参与式设计（PD）技术，让用户参与到系统修改过程中，并尊重他们的决策权力。

3. 所提出的架构

3.1 终端用户界面

终端用户界面分为两部分：静态部分和动态部分。静态部分基于语义分析，动态部分则在运行时根据规范构建或配置界面。

设计终端用户界面时，我们假定CSCW系统的目的不是取代员工，而是帮助他们改进工作实践。设计师和用户应参与参与式建模，以改进工作实践，构建新的（或修改后的）社会背景模型。

从符号学的角度来看，设计师和用户需要构建他们未来工作实践的即时模型，系统应支持他们的人类行为。在构建系统的第一部分时，我们关注人类代理的可供性，以生成界面的静态部分，其中包含在动态部分会被修改的对象。对于代表预期工作实践的本体图中工人的每个可供性，我们需要回答以下两个问题：
- 系统是否应支持此可供性？并非所有可供性都直接与我们希望系统支持的工作实践部分相关，有些可供性可能与工人的行为无关。
- 如何支持这种代理行为？界面是终端用户感知系统的部分，我们不应将界面视为具有一组属性的独立事物，而应考虑代理在系统中如何感知它。

在这个阶段可以使用参与式设计技术，之后设计师需要将对用户感知的理解转化为界面设计技术。例如，在设计静态部分的终端用户界面时，以“发送”可供性为例，它在本体上依赖于“工人”和“消息”。我们可以认为“发送”与工人的行为相关，并且是系统应支持的工作实践的一部分。为了避免错误，我们需要考虑在工人的社会背景下“发送消息”的含义，不能仅仅将“按钮”作为发送消息的唯一方式，“回车键”也是一种选择。同时，本体依赖关系意味着某些可供性只有在其他可供性也存在时才可用，因此可以将其作为显示界面元素的条件。例如，“发送”可供性依赖于“消息”可供性，那么与“发送”可供性对应的界面元素只有在代表“消息”存在的软件元素（类、数据或界面）确认其存在时才应显示。

终端用户界面的第二部分通过规范的解释动态生成。这部分界面的更改受到计算技术的限制，例如：
- 如果更改限制访问某些类型信息的规范，需要系统在运行时有可配置的参数。
- 如果更改规范以要求或允许工人填写新表单，则需要在运行时通过组件集成将其包含在工人界面中。
- 如果包含指定解决问题新程序的规范，可能需要自动生成新代码。

因此，界面工程师需要了解技术的限制，规范的更改只有在与界面的动作机制相关联时才可行，那些无法在界面上体现更改的规范将直接编程到系统代码中。

动态部分的界面包含“感知”和“动作”两种机制。在向终端用户显示界面之前，应用程序需要从界面配置环境（ICE）获取界面设置。首先，ICE需要有足够的使用上下文信息，包括使用系统的代理、代理正在执行的任务以及其他使用上下文数据。感知机制通过特定协议的消息将数据传输到ICE，ICE利用这些数据识别要分析的规范组。例如，上下文信息可能包括：
- ：表示将显示给用户的界面元素与“解决问题”可供性相关。
- ：表示John是使用系统的工人。
- ：表示问题解决的阶段。
- ：表示John负责第4步。

ICE接收到上下文数据后，会返回一个包含界面元素及其操作的参数列表。“动作”机制接收这些数据，并将其转化为终端用户界面的修改，如配置界面（启用/禁用按钮）、集成新的界面元素（添加预定义表单）或开发新的界面代码。例如，界面设置可能包括：
- ：表示第4步的“实施”按钮应启用。
- ：表示第4步的“动作”文本框应启用。
- ：表示第4步的“警告”标签应显示。

3.2 界面配置环境

界面配置环境包含一个JESS（Java专家系统外壳）推理机和知识库，以及一个将规范转换为Jess语言的数据库。Jess是一个完全用Sun Microsystem的Java语言编写的脚本语言的专家系统外壳，它支持开发基于规则的专家系统，并能与用Java语言编写的代码紧密耦合。在提出的架构中，这个推理机接收上下文信息，并通过前向链机制决定应采取的行动。

数据库中存储的信息包括在规范分析期间进行的“规范指定”（转换为Jess规则）和“动作指定”（将规范与界面设置联系起来的规则）。规范和动作指定由规范管理器和动作管理器构建。

界面工程师使用规范管理器以声明方式指定和维护规范，每个规范通过翻译模块转换为Jess语言，Jess推理机立即使用新的知识库开始工作，因此规范的更改可以直接转换为新的界面配置，无需修改代码。例如，规范管理器中的一个规范可能是： Obligated/Specify_Actions(?Y)>，表示在“解决问题”可供性下，当员工代理负责某一步骤时，他/她有义务指定该步骤的行动。

规范管理器中指定的规范通过动作管理器中指定的规则与终端用户界面的对象关联起来。这样做是为了保持规范与应用程序界面的独立性，规范处于更抽象的层面，动作指定将这个抽象层面与界面联系起来。

界面工程师使用动作管理器指定终端用户界面实现中可用的界面对象和动作。我们将任何界面元素称为“界面对象”，将其可能的动作称为“对象的动作”，例如简单按钮的显示、启用、设置图标等动作，或通过添加软件组件集成的复杂框架及其多个配置参数。在实现层面，界面工程师应将这些界面元素视为对象，因为它们是使用面向对象技术实现的。

指定对象和动作后，界面工程师使用动作管理器工具将规范的“动作部分”（通过规范管理器指定）与界面上的对象及其动作关联起来。当Jess推理机得出规范的动作应被触发的结论时，动作规则将被触发（通过前向链），将规范的动作映射到要应用于终端用户界面的界面设置列表。例如，动作管理器工具中的一个规范可能是： ButtonImplement_S ?Y (Enable) …>，表示“指定动作(?Y)”的动作被转换为界面设置“ButtonImplement_S ?Y (Enable) …”，该设置将返回给动态界面的动作部分。

下面通过一个场景来详细说明架构的动态部分执行过程：
1. 动态终端用户界面的“感知部分”向Jess推理机发送上下文信息： , , , 。
2. 推理机通过前向链（和统一）触发规则：resolution/Employee (?X) and Step (?Y) and Responsible (?X, ?Y) => O,?X/Specify_Actions(?Y)，并得出 的结论。
3. 推理机再次通过前向链（和统一）触发规则：O/?X/Specify_Actions(?Y) => ButtonImplement_S ?Y (Enable) …，并得出 的结论。
4. 推理机将包含 , , 的列表返回给动态界面的“动作部分”。

这个过程可以用以下mermaid流程图表示：

graph LR
    A[动态终端用户界面感知部分] -->|上下文信息| B[Jess推理机]
    B -->|规则推理| C{规范动作触发?}
    C -- 是 --> D[触发动作规则]
    D --> E[生成界面设置列表]
    E -->|界面设置| F[动态终端用户界面动作部分]
    C -- 否 --> G[无动作]

通过以上架构和机制，我们可以在组织规范发生变化时，较为灵活地对系统界面进行调整，以适应新的组织环境。在接下来的部分，我们将通过一个实际案例来进一步探讨该方法的应用和效果。

4. 讨论

所提出的架构已在一个案例研究中得到应用，以Pokayoke系统为例，它是一个用于支持采用精益生产范式的制造组织进行问题解决和决策的计算系统。Pokayoke基于工厂中的一个“五步”程序，该程序用于分析和实施纠正、预防、安全和健康维护行动。每当识别出不符合项时，必须采取行动纠正它并防止再次发生；当出现潜在不符合情况时，应执行防错（Poka Yoke）行动。

支持问题解决过程的工具分布在过程的不同阶段，例如：在第三步使用鱼骨图（Ishikawa Diagrams），在第二步和第三步使用头脑风暴，在第三步使用5-why分析法。这些工具嵌入在系统中，并与异步通信工具相结合。

Pokayoke系统界面按照本文提出的方法分为两部分。动态部分主要用于规范的指定，这些规范建模了问题解决方法中的责任、职责和权限，例如访问Pokayoke某些功能的权限、任务顺序以及在问题解决过程的不同阶段谁负责哪些任务。例如，在Pokayoke环境中的一个规范是：任何用户都可以在头脑风暴会议中提出想法，但不允许指定纠正问题的行动。

通过分析用户在使用过程中对系统提出的修改要求，对该方法在Pokayoke系统中的应用进行了评估。Pokayoke的实现仅限于上述类型的规范，不包括如为用户添加预定义或新的强制性任务等规范，因此这类规范的更改被视为代码更改。在系统由7个终端用户进行测试期间，应用了Muller等人提出的参与式启发式评估方法。

在应用参与式设计技术时，7个用户和5个界面专家总共提出了25项修改建议，具体情况如下表所示：
|提出者|总建议数|动态部分规范修改|代码小修改|静态部分屏幕布局修改|
| ---- | ---- | ---- | ---- | ---- |
|终端用户|14|9|3|2|
|界面专家|11|4|5|2|

在组织大规模使用Pokayoke系统的3个月内，48个用户提出了3项修改建议，其中2项涉及系统的动态部分，1项是小错误，易于纠正。

分析对Pokayoke系统提出的总共28项修改建议，发现54%的修改涉及动态部分，32%是静态部分的小代码修改，14%是静态部分屏幕布局的修改，且需要超过一天的实施工作。这表明所提出的方法具有很大的潜力，因为它避免了54%的应用代码修改。如果能支持更多类型的规范更改，这个比例可能会更有利。

5. 结论

多个领域的研究表明，要构建适合工作实践的软件系统，必须理解组织背景，这意味着要考虑组织的正式和非正式系统，技术系统应从中发展而来。组织就像一个有生命的有机体，技术系统应能够适应组织的变化。

本文通过提出一个用于系统界面配置的规范驱动环境，解决了随着组织规范变化而允许系统进行更改的复杂性问题。该方法在Pokayoke系统的设计和初步使用中得到了应用。

此方法并非要完全解决问题，而是为该主题的讨论做出了初步贡献。未来的工作应在更多案例研究中进一步开展，特别是针对定制和个性化方面。

综上所述，这种基于组织符号学的界面设计方法为适应组织变革提供了一种可行的途径，通过合理划分系统架构的静态和动态部分，利用语义和规范分析，以及界面工程师和终端用户的协作，可以更灵活、经济地对系统界面进行调整，以满足组织不断变化的需求。

以下是整个架构的主要流程总结列表：
1. 终端用户界面通过感知机制将使用上下文信息传递给界面配置环境（ICE）。
2. ICE中的Jess推理机根据上下文信息和规范进行推理。
3. 推理机触发相应的规则，将规范的动作映射到界面设置。
4. ICE将界面设置返回给终端用户界面的动作机制。
5. 动作机制对终端用户界面进行相应的修改，如配置参数、集成组件或扩展代码。

整个系统的工作流程还可以用以下mermaid流程图表示：

graph LR
    A[终端用户界面 - 感知机制] -->|上下文信息| B[界面配置环境 - Jess推理机]
    B -->|规则推理| C[动作规则触发]
    C -->|界面设置映射| D[生成界面设置列表]
    D -->|界面设置| E[终端用户界面 - 动作机制]
    E -->|界面修改| F[终端用户界面展示]

通过这种方式，系统能够根据组织规范的变化动态调整界面，更好地适应组织的发展和变化。