应用用户体验复制技术来命名一个API

At commercetools we love experimenting and trying out innovative ideas that let us get the best possible solution for our users. This time we used an existing framework for an unusual purpose: to come up with a name for a new feature and its resource in our platform.

在commercetools，我们喜欢实验和尝试创新的想法，让我们为我们的用户获得最好的解决方案。这一次，我们将一个现有的框架用于一个不寻常的目的：为一个新的功能及其在我们平台上的资源想出一个名字。

But before spoiling all the fun, let’s go back to the initial problem we were trying to solve. Based on previous research, we were aware that some customers selling products in different storefronts are often creating one project per storefront needed. As a consequence they end up duplicating data and/or synchronising it between projects.

但在破坏所有的乐趣之前，让我们回到最初我们试图解决的问题。根据以前的研究，我们意识到，一些在不同店面销售产品的客户经常为每个店面创建一个项目。因此，他们最终会在项目之间重复数据和/或同步数据。

One of the reasons for that setup was that each storefront had to sell slightly different product catalogs. Imagine having a product catalog of 500K products, all with their product data and pictures, where the 95% of it is available in all storefronts the customer has. We needed to improve our customer experience so they could avoid the multi-project setup scenario and just send the right data to each storefront, or in case of B2B, to each customer.

这种设置的原因之一是，每个店面必须销售略有不同的产品目录。想象一下，有一个50万种产品的目录，都有它们的产品数据和图片，其中95%的产品在客户拥有的所有店面都有。我们需要改善我们的客户体验，这样他们就可以避免多项目设置的情况，只需将正确的数据发送到每个店面，或者在B2B的情况下，发送到每个客户。

Call me by your name

叫我的名字

During the discovery phase of the project, when the team was gathering use cases to define the problem better and model the domain, we conducted multiple interviews with targeted users of our APIs. It’s during these initial steps when the team usually establishes the Ubiquitous Language, a common language between team members and our users.

在项目的发现阶段，当团队在收集用例以更好地定义问题并对领域进行建模时，我们对我们的API的目标用户进行了多次访谈。正是在这些最初的步骤中，团队通常建立了 无处不在的语言、团队成员和我们的用户之间的共同语言。

However, we realised that different participants were using a variety of terms to designate the same type ...