听起来您有两个任务： 任务 1 对对象进行分类，对于一系列对象，用户在多个维度（属性）的每个维度上为每个对象分配一个类别（值）。任务 2：创建和修改维度和类别。
在数据建模者、面向对象程序员和数据库设计者之外，维度和类别的概念是一个很难掌握的概念。您应该为用户不理解类别和维度之间的差异做好准备。但是，用户通常会理解表格，其中每一列都是一个维度（包含多个类别），每一行都是一个对象。尽可能使用表格。
第一个关键问题是通过用户研究弄清楚任务1和任务2是整合还是分离的程度。
如果任务是集成的，用户经常不假思索地从一个任务切换到另一个任务，那么一种 UI 设计就是有一个按维度的对象表，但提供一个空白列（或“插入”按钮）以允许用户添加维度。列标题具有用户可以编辑的维度名称。标题下方的空间列出了该维度的类别。每个类别名称都是可编辑的，并且有一个空行（或“插入”按钮）用于添加新类别。下面是要分类的对象，每个对象的每列中都有一个维度下拉列表。
在可用性测试中，请注意用户尝试通过单击类别列表中的类别而不是从下拉列表中选择来设置对象的类别。使类别列表在视觉上分开显示以防止这种情况发生。
您可能需要一个按钮来隐藏/显示类别列表，因为这可能会占用大量空间（即使使用滚动条）。即使任务 1 和 2 紧密集成，我认为您会发现用户有时可能希望将类别列表移开。
如果您发现任务 1 和 2 是分开的，很少一起完成（例如，用户通常设置其维度，然后对一堆对象进行分类），那么您最好为每个任务使用单独的窗口（或页面），尽管在它们之间来回导航应该很容易。例如，虽然用户通常可能会事先设置其维度，然后很少修改它们，但有时用户会意识到在对不寻常的对象进行分类时需要一个新的维度类别，因此您提供了一个“添加类别”菜单项，该菜单项可以让用户到“管理类别”窗口，其中为当前维度插入了一个新类别，等待用户提供名称。
任务 1 的窗口与以前相同：对象表，每个维度都有一列下拉列表，但不包括类别列表、维度名称的编辑以及添加新维度的能力。如果用户需要扫描需要分类或重新分类的对象，或者如果用户通常需要将一个对象与其他一些对象进行比较（例如，决定如何对对象进行分类），则这是最有效的。然而，如果用户的任务确实仅限于分类基于外部信息（例如，从纸上转录信息）一次一个对象，然后考虑一种表单而不是表格，显示一组列表框，每个属性一个。只需单击每个列表框即可设置每个类别，这比使用下拉列表更快。
任务 2 的窗口可能类似于任务 1 的标题部分。它与任务 1 中使用的表格一致，允许用户同时查看多个维度的类别，帮助他们找出最佳的分类方案（例如，帮助他们找到本质上相同的类别出现在两个不同维度中的位置）。然而，如果空间是一个问题，那么请考虑一个维度列表，每个维度都显示主从关系中的类别列表。
任务 2 的最终用户功能和灵活性是树状控件。树的根级别包括维度，层次结构中的下一步包括每个维度内的类别。主要优点是它支持尺寸依赖的关于类别。例如，可能有一个车辆类型维度，其中包括汽车、船、飞机等类别。对于汽车类别，可能有一个车身类型维度，其中的类别仅适用于该类别（轿跑车、掀背车等）。 ）。从属维度在树中由类别的分支表示。结果是树在每个级别的维度和类别之间交替。
重要的是在视觉上区分类别和维度，也许通过不同的图标，也可能通过不同的字体——告诉用户层次结构中的交替步骤在本质上是不同的（例如，如果您创建一个维度，那么您应该在至少两个类别）。即使如此，如果用户混淆了维度和类别，请提供一种轻松恢复的方法（例如，允许他们将一堆“维度”移动到另一个维度下，将前者转换为类别）。
我想再次强调人们在维度和类别等抽象概念上遇到的困难。即使人们确实理解了这一点，通常也很难自己创建合适的维度和类别。您需要考虑可能会导致复杂的交互（例如，当类别移动到新维度时，对象分类会发生什么？）。如果您期望每个用户真正创建自己的新颖维度，那么您可能需要认真重新思考您的整个方法。这是一项本质上复杂的任务。
如果文化、组织或领域已经存在相关的多维方案（例如我们针对汽车的方案），用户会做得更好。当然，如果已经有一个方案，那么您可以研究它并将其安装为产品中的默认尺寸集。任务2只需要支持以允许专家用户对其进行微调。
