Summary

Motto: “Every contact leaves a trace.” (Edmond Locard)

Type: A pattern of dynamics between Design Outcomes and Design Resources

Definition: Design resources, as well as the way how working with these resources is organized, are leaving a characteristic signature on a design outcome. It is often possible to guess, from the design outcome, which design resources designers used, and how the working with the resources was organized.

Alternative names: Conwayian laws, Resource Signature, Design Style.

Topics: constraints, consistency, templates, frameworks, convention-over-configuration

Desirable: In situations where consistency among design outcomes is essential.

Undesirable: In complex real-world situations and in new domains where it may lead to unnecessary limited or complex solutions.


Description

The characteristics of design resources directly influence the design outcome’s form and possibilities. This influence can happen at all levels, from simple design tools to complex organizational structures. Selection of design materials, for instance, leaves a clear signature on a design outcome. But all design resources, including tools, methods and organizational structures supporting a design activity may leave a typical signature on a design outcome.

The following table illustrates levels at which this pattern may occur:

Level Examples
Technology and tools Templates, material characteristics or default tool settings drive the shape of outcome
Individual designers Designer’s style, skills and preferences drive the shape of outcome
Team and organization Team organization and communication structures drive the shape of outcome (Conwayian laws)

At the tool level, the pattern is a consequence of possibilities and limitations of used design tools. Design tools empower designers but at the same time, they may constraint designers’ actions. These restrictions often leave a typical signature on a design outcome. Mary Collins, in her post “Web Design Trends: Why Do All Websites Look the Same?” noted that modern websites style-wise look very similar: “large full-width background image or video in the header, overlaid text, followed by a block of short text, and then the obligatory icon columns.” Collins argued that this uniformity has its origins in popularity of UI frameworks, in particular Bootstrap, as well as the availability of pre-designed website themes, such as those in WordPress.

In software design, developers need to use software frameworks and libraries. These frameworks often have recommended ways of working and their conventions. Some software frameworks follow the convention-over-configuration approach, making it easier to do things that mimic particular conventions. Sometimes, such frameworks are called “opinionated” frameworks as they embed and promote “opinions” about how things should be done. Such “opinionated” frameworks encourage designers into doing things their way. By design, such frameworks are leaving a strong signature on a design outcome. For example, Maven, one of the most popular software project management tools, strongly encourages applications to follow standard Maven directory structure and file name conventions. In practice, that means that virtually all Maven projects will have a very similar source code organization. While this may be limiting in some cases, the significant advantage is that anyone who worked on one Maven project will be able to work in another Maven project more efficiently.

One advantage of the design signature pattern is that it facilitates consistency and better understandability of design outcomes. Myers argued that since all user interfaces created with the same tool will be similar, such tools help to achieve a consistent look and feel (Myers et al. 2000). For instance, Bootstrap and Google Material Design are frameworks for creating unified user experiences across diverse platforms and devices. While being very flexible, these frameworks come with predefined elements and resources, such as material icons, which can give applications a distinctive Bootstrap or Google material look and feel. This consistent look and feel, in turn, can make it easier for users to reuse their experiences from other applications across diverse channels.

Having design tools that impose strong constraints, while limiting designers, also can simplify the design of new design outcomes. Tools without such constraints may lead designers to create unnecessarily complex and difficult to use designs. Nielsen’s 2010 report on the usability of iPad applications nicely illustrates this issue:

“The first crop of iPad apps revived memories of Web designs from 1993 when Mosaic first introduced the image map that made it possible for any part of any picture to become a UI element. As a result, graphic designers went wild: anything they could draw could be a UI, whether it made sense or not. It’s the same with iPad apps: anything you can show and touch can be a UI on this device. There are no standards and no expectations.” (Nielsen 2010)

The main disadvantage of using tools with predefined elements is that they constraint the design outcome and may limit options and creativity of designers. Websites that use predefined templates may lack clear distinction in style from other sites, which may cause user dissatisfaction or users’ perception of the company as unoriginal or amateurish. Consequently, tools with fewer constraints may lead to more innovative designs. As argued by Shneiderman et al. (2007), the success of Flash user interface tool was partially based on the lack of predefined widgets. It stimulated innovative designs because it encouraged designers to explore different ways to control the interaction, instead of just using buttons and scroll bars. We may argue that lack of predefined elements in a user interface was a typical signature of the Flash tool.

The Conwayian laws pattern may also occur as a consequence of individual designer’s background and preferences. In his examination of forces that generate a style in architecture, Chiu-Shui Chan (2001) argued that an architectural style is not only a similarity of physical features in a designed object. Instead, a style also reflects designers’ personal aspects, including operations of cognitive mechanisms, utilization of repeated procedures, personal preference for specific images, and manipulation of certain seasoned design knowledge. Designers have their own unique sets of skills, knowledge, and experiences, and often they have developed their design styles. Moreover, sometimes a designer may be invited to design something exactly because of this style. That means that different design outcomes produced by the same designers will often have some standard features.

The Conwayian laws pattern may also be visible at the level of design processes and organizations. Established processes and organizational structures may influence the form of design outcomes. Melvin Conway, in what is nowadays known as Conway’s law, stated that organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations (Conway 19681). In other words, the structure of a system will follow the organization of the people that built it (e.g. see Lewis & Fowler 2014). When designing a complex system, two modules A and B cannot interface correctly with each other unless the designer and implementer of A can communicate with the designer and implementer of B. MacCormack et al. 2012 similarly explored the duality between product and organizational architectures, highlighting the impact of organizational design decisions on the technical structure of the artifacts that these organizations develop. This pattern may enable organizations to create particular types of design outcomes efficiently.

If an organization frequently produces a specific kind of design outcomes, having a stable, optimized organizational structure can be a significant advantage. When established organizational structures do not match well requirements of design outcomes, this pattern may lead to negative consequences. If the organizational structure makes it difficult to introduce particular changes, this pattern may lead to missed opportunities or lower quality. Gokpinar et al. (2010), in their study of vehicle development process of a major auto company, found out that mismatches between product architecture and organizational structure lead to a number of quality issues. In other cases, this pattern may lead to unnecessary complexity. For example, Bass et al. (2012) reported a case in which a software architect was asked by the management to add a database component to the software solution without clear functional need. The main reason was that database department was overstaffed and underworked and they needed something to do (page 59). “Design by committee” is another example of unnecessary design complexity introduces by imposed organizational structures. Fred Brooks (2010) argued that outcomes of a design by committee lack focus and result in impractical products with too broad functionality. Brooks elaborated that the people in committees, to protect their interests and avoid conflicts, are often reluctant to reject any request:

Each player has a wish list garnered from his constituents and weighted by his personal experiences. Each has both an ego and a reputation that depend on how well he gets his list adopted. Logrolling is endemic—an inevitable consequence of the incentive structure. “I won’t naysay your wish, if you won’t naysay mine” (page 41).

Illustration of the Conwayian Laws. Credit: Martin Fowler.

The Conway’s pattern is a consequence of inertia (resistance to change) of design resources. The opposition to change of design resources is not necessarily a problem. Having stable tools, habits, and organizational structures often make designing more comfortable, more predictable and faster. Such inertia may be a design decision, for example, if the goal is to create consistent design outcomes. But such inertia may happen implicitly, for instance, due to sheer size and complexity of used resources. Social dynamics in design teams and organizations also contribute to this pattern, such as in the case of the Conwayian laws. As noted by James Coplien (1999) in his discussion of Conwayian laws, “[software] architecture is not so much about the software, but about the people who write the software. The core principles of architecture, such as coupling and cohesion, aren’t about the code. The code doesn’t ‘care’ about how cohesive or decoupled it is; … But people do care about their coupling to other team members..” The resistance to change means that the resources may be difficult or costly to change, often leading to a more manageable option of design outcome adaptations. However, too much inertia may lead to situations where design outcome becomes unnecessarily constraint or complex.

The Conwayian laws pattern is related to the inverse Conwayian laws pattern. Design resources may get their “signature” form as a result of the need to support efficient creation of certain types of design outcomes. The Conwayian laws pattern is also related to the conformity pattern. Adopting popular design resources with established best-practices also means accepting particular constraints and ways of working with these resources.

Questions to Ask Yourself

  • Do you have your design style? How much do you care about it?
  • Do you use templates and standard sets of technologies and materials in your designs?
  • Do templates and standards help you to simplify and speed up your design efforts?
  • Do these templates and standards limit your design efforts?
  • How do you ensure consistency (when needed) in multiple design activities?
  • Is your organizational structure aligned with the structure of your design outcomes? How?
  • Have you ever experienced the effect of Conwayian laws, where your designs copied the communication structures of your organization?
  • Have you ever build unnecessary complex designs due to wrong organizational structures?
  • Have you ever experienced the effect of inverse Conwayian laws, changing your organization to suit the design outcome structure better?

Cover Art

The screenshot of several popular WordPress themes with similar styles.

Footnotes