A Nameless Design Craft

The spectrum of design skills necessary to create successful software applications has been chopped up into an excessive number of overlapping disciplines like graphic design, visual design, information design, interaction design, user interface design, user experience design, and information architecture. As plentiful as our vocabulary is for describing the layers of the software design process, for years I’ve felt like there is a fundamental design craft that is absent from the discourse. This is my first attempt to articulate it.

The output of a design process is typically tangible. Visual designers produce mockups, user experience designers produce wireframes or page flows, information designers produce taxonomies or ontologies. These outputs describe solutions to design problems. The nameless design craft I speak of produces none of these visual or textual outputs. Instead, it produces an agreed upon structure in which the designers and developers will live in as the product evolves.

To explain, I’m going to discuss the enterprise platform we built while I was in my former job as the head of product for GoodGuide. The primary purpose of the platform was for companies, commonly retailers, to assess the sustainability of their suppliers. This requires collecting information about suppliers and sharing the results with the retailers and suppliers in a clear, actionable format.

Early on in the development of the platform, we found ourselves at a fork in the road with two possible paths before us.

Both the suppliers and the retailers needed to interact with the same data set. One path was to create a single user interface to serve both their needs. Different users could have access to different functions and subsets of the data, but the overall user interface would be the same for everyone using the system.

There were reasons against this path. While the suppliers and the retailers required access to the same data, their needs and motivations had key differences. For example, suppliers needed to input lots of data and understand their scores in granular detail. The retailers, in contrast, only required read-only access and wanted to understand the strengths and weaknesses of their suppliers in broad strokes. A second path was to design separate user interfaces; one for the suppliers and one for the retailers. Each interface would reflect the distinct needs of the user group. There might be shared UI patterns across both interfaces, but the screens would be structured differently for each party.

It might be tempting to look at the choice between the two paths as a common interface design problem. Through understanding the functional requirements, you could decide which design direction best meets those requirements. Or, you could look at choice as inconsequential. A successful MVP could be built following either path.

But the decision is neither a common interface design problem nor inconsequential. The path chosen will influence the long term vitality of the product. Let’s explore the pros and cons of each direction.

Path #1: A single user interface both suppliers and retailers.

Pros:

• Future enhancements made for either party will benefit both parties. The product team won’t have to dedicate resources for applying improvements from one user interface to the other. E.g., we may create a better way to visualize score distribution with the retailer benefit in mind. This enhancement may not be at the top of the suppliers’ priorities, but they will get the new feature nonetheless. There’s potential it will be serendipitously leveraged.
• One interface instead of two allows the engineering team to be more focused. The overall application structure, one might argue, is simpler.

Cons:

• While the differences between the retailer and supplier demands on the application may look relatively minor at first, they could diverge more over time. Enhancements beneficial to one party may be detrimental to other, leading to a constrained user experience for both.
• While it may, in one sense, be simpler to have one interface instead of two, supporting the divergent needs of both user groups may lead to exploding complexity in the app. E.g. the single interface may need to be configured differently for both parties making it relatively costly to build and test new features.

Path #2: Separate user interfaces; one for suppliers and one for retailers.

Pros:

• Each interface could be designed to fit its user group like a glove. Differences between the retailers and supplier requirements could be reflected in nuanced detail.
• While the engineering team would need to build two interfaces instead of one, each of them would serve a single purpose reducing complexity from configuration logic.

Cons:

• When there is functionality that should be applied to both interfaces, UI patterns may not translate across both screens. Some features will need to be implemented differently for each screen.
• Business pressures may lead to one interface being prioritized over another. For example, if signing up and retaining retailer users is more critical to business, the suppliers’ interface may be neglected, causing issues down the road.

If you were to look at the choice as a static design problem with a fixed set of functional requirements, path #2 looks more appealing. Removing the constraint of having to design a single interface for two different types of users allows you to design the optimal user interface for each use case.

If you were to make the judgment that the needs of retailers and suppliers would continue to diverge over time, then you would have to choose path #2. But we determined that, while there were some key differences between retailer and supplier requirements, the overlapping needs across all users was sufficiently high. We chose path #1 and built one user interface with some configuration differences for retailers and suppliers. While managing the configuration complexity was a constant risk area, this direction was fruitful. The choice led to strategic advantages for us that we were unaware of upfront:

• Retailers were more important customers to acquire initially since they had the power to essentially force suppliers into the platform. Other competitive platforms had chosen to focus on meeting retailers needs at the detriment of supplier needs, leading to increasing irritation on the supplier side. Because our supplier interface was in parity with the retailer interface, we achieved a dramatically better supplier UX. Retailers, vested in the satisfaction of their supplier partners, saw this as a differentiator of our platform.
• The intent of our platform was to join retailers and suppliers in a conversation about sustainability. It was valuable that we could say to suppliers that the retailers would see exactly the same thing that they saw about their products. A single user interface for both parties removed any mystery about how the data was being used by the other side. A common user interface was conducive to a transparent and clear dialogue between suppliers and retailers.
• Constructing the interface to be highly configurable allowed us to quickly handle new use cases in the platform when they arose.

The type of design decision I’ve explored here is upstream of the static design challenges traditionally discussed. Practitioners of this nameless design craft must understand the implications of known information on the product design, but they also must anticipate how the ecosystem around the product will evolve over time. The goal is not just to identify a design problem, come up with the best solution, and move on to the next problem. Instead, the objective is to create a structure that will allow a stream of good design work to result in compounding wins. This requires design insight, but also a feel for how business and technological factors interplay with the design.

To advance our ability to understand the area of design I’ve tried to identify, I have two questions for you:

• What would you call this type of design?
• What design decisions have you made that reflect this type of thinking?