At first, the goal of product development seems easy: Figure out what users need and then build it. However, there are several other factors Agile teams must consider about each product. Not only must it fulfill users’ needs, but the product also must have an intuitive interface. It should also conform to the needs of the hosting platform and be compliant with any applicable rules and regulations. Eventually, keeping track of all these factors and more can get overwhelming.

Luckily, Agile product coach Ellen Gottesdiener realized this and helped simplify development planning. She proposed seven major factors to consider when creating a digital product or improving one that exists. These “7 Product Dimensions” are User, Interface, Action, Data, Control, Environment, and Quality Attribute.

In this article, we will go step by step through the 7 Product Dimensions and look at a few useful tips to make this framework actionable.

7 Product Dimensions” by EBG Consulting is licensed under CC BY-NC-ND

Users

Users are any person or thing that will interact with your product. This could be a human or another integration system. Examples include a shop customer, company employees, or even another piece of software connected to your product.

Interface

Now that you know more about the user, how will they interact with this product? That’s what we call the interface. This can take the form of a webpage, mobile app, desktop screen, or API endpoint, to name a few examples. Take care not to confuse the interface with the product environment. We will take a closer look at what “environment” means later in this article.

Action

How do users benefit from this product? Action describes what the product will do for users. To keep every action distinguishable from others in your design, you should articulate each one with a separate verb. Here are some examples: Add new client, begin billing process, and edit client information.

Data

Most digital products will collect information the user provides (input data) and present information to the user (output data). Together, these two elements form the data dimension of product development.

Let’s say, for example, your product processes billing for a utility company. Users may input data such as their name, contact information, or ID number. And, for its part, the product may output data such as the user’s current amount due or the bill processing date.

Control

Control refers to all the rules the developer must follow for a product or feature. This is the place to describe all data and regulations that will restrict any aspect of your product. As part of your development plan, you should outline these controls in as much detail as possible. Be sure to include any relevant laws and regulations that pertain to your industry and location.

Here’s an example: When collecting identifying information from clients such as a social security number, each client can only have one at a given time.

Environment

A product’s environment is the technology and infrastructure needed for a product or feature to work correctly. When designing a product or planning a major update, this is the space to outline system requirements. That could include the software architecture for implementation, cloud clusters, web hosts, and more. When you talk about adding a new feature or updating an existing one, the environment points to where the change is performed. For example, we change only a page of an entire website or only one screen in a mobile app.

You may notice that environment is close to interface but still fundamentally different. Interface refers to how the user interacts with the product. Meanwhile, environment refers to how a product or feature interacts with other features, platforms, or integrations.

Quality Attribute (QA)

Finally, the quality attribute, or “QA,” refers to any required quality controls. Any controls described earlier must have a corresponding QA.

So, what is the difference between QA and controls? Outside forces like laws and regulations set controls. Meanwhile, developers establish the associated QAs.

To illustrate the difference, let’s look back at our example of a control: When collecting identifying information from clients such as a social security number, each client can only have one at a given time.

Now, here is the associated QA: Controls dictate no user can have more than one SSN. Therefore, the software cannot support the input of more than one SSN for a single client.

Illustrating the 7 Product Dimensions With a User Story

To make sure your Agile teams understand what they need to deliver, it helps to write a user story containing all the relevant requirements. If you are unsure how to write a user story, check out our article on best practices.

Below is a user story sample utilizing the 7 Product Dimensions as a guide. I point out every dimension, marking how it factors in and where to organize it correctly. For this sample, I use the simple scenario of a customer adding a dependent to a bank account. Let’s see how this works:

As the Account Manager (User), I need to add a dependent (Action) to my account management page (Interface) to provide access to this dependent (another Action).

(Data)

  • Input Data: Name, ID Number, Relationship status (Husband, Son, Parent, etc.)
  • Output Data: Non-Applicable in this case.

Control (Business rules and/or restrictions)

  • Only a valid ID number can be accepted by system. When it is invalid, block the operation and show error message.
  • If the informed ID number is already associated to the Account, block the operation, and show message.

(Environment)

  • Implement in both web and mobile versions of online banking.

(Quality Attributes)

  • Not allowed to use an invalid ID Number for the dependent.
  • Not allowed to use duplicate ID Numbers for an account.
  • Only after being added can the dependent person access the balance for the linked account.

Tips for Implementing the 7 Product Dimensions into User Stories

After seeing that example, you may still feel uncertain about how you will document each of the 7 Product Dimensions and incorporate them into your user stories. A good way to uncover each dimension is to ask stakeholders targeted questions in the early planning phases.

Here are a few sample questions:

  • Who will use this product/feature? (User)
  • What will the product/feature do? (Action)
  • How will the user interact with this product/feature? (Interface)
  • Where will we need to implement it? (Environment)

Similarly, you can depend on your colleagues to ensure the 7 Product Dimensions are clear in the user story. As your scrum teams review each user story before a sprint, ask them if they can identify the user, action, environment, and other dimensions. Like many parts of the Agile process, this framework is simple to understand but can be hard to fully utilize at first. Remember that trial and error are part of the process, and you’ll find it easier to identify the 7 Product Dimensions with each sprint.

If you need some help along the way, remember that Programmers is available for staff augmentation. We provide your team with experts well-versed in Agile and the 7 Product Dimensions. Contact us today to add a scrum team that is ready to go on day one!