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