Innovation at the Speed of Information


October 2001

Innovation at the Speed of Information


Most of the software interfaces and documentation still being developed today are organized either structurally or functionally.

Structural organization implies that the documentation is organized by the way the software was developed. This is the organization that would be expected if the technical writer and interface designers use the developers for most of the content of the documentation. The developers are very familiar with the way the software system is organized but less familiar with the way users would use the software to get their jobs done.

Functional organization implies that the interface and documentation designers divided the content into logical units based on software functions. Functional organization may or may not coincide with structural organization.

However, users of the software system integrate the software among their entire set of job functions. The organization of their tasks will likely not coincide with either the structural or functional organization of the software systems they are using.

Modern interface design and documentation design is based on the needs of the users of the software. Software manufacturers realize that systems that are easy to use have a competitive edge over systems that are difficult to use even if those systems are more elegant or have greater functionality.

Interface designers and documentation architects are familiar with the difficult and time-consuming job of identifying users and doing detailed task analyses so that they can match the interface and documentation to the needs of the users. One of the needs in interface design is to place system functions that are used concurrently or in order on the interface in a way that is most convenient for the user. You have all heard the complaints about interfaces that require the user to be all over the place in the system just to get one user task completed. Similarly, how often have you had to page through a help system or documentation to get to several functions that are being done nearly concurrently by you but are in very different parts of the documentation.

Steven D. Eppinger in an article titled “Innovation at the Speed of Information” in the January 2001 issue of the Harvard Business Review describes a tool that may help interface designers in their user task analyses. He calls the tool the Design Structure Matrix. The article and the Eppinger application of the Design Structure Matrix is directed to innovative product design. However there are strong similarities with interface design and documentation design.

He divides the product design process into design tasks. Some tasks can be done independently of all other tasks. Some design tasks are dependent on the completion of other design tasks, and some design tasks must be completed before others can be completed.

The relationships between design tasks can be represented graphically using the Design Structure Matrix.

The matrix lists all of the tasks in the same order along the vertical and horizontal axes. Reading along a row, an X under a task implies that the task in the row depends on the task listed in a column. Looking at the first row in the diagram, you can see that task A does not depend on any other task for its completion. In the second row, task B depends on task, A, J, and G. By looking at the first column, you can see that tasks B, C, D, I, and J depend on the completion of task A.


Use the Design Structure Matrix to rearrange the order of the tasks.

An obvious problem is that task B depends on the completion of tasks that are scheduled to be done after task B. This requires an iterative process to do the series of tasks. This can greatly increase the cost of doing the tasks as well as degrade the quality of the completed tasks.

Using the Design Structure Matrix, it is possible to rearrange the order of the tasks to minimize or eliminate the need for iterations in doing a series of tasks. In terms of the matrix, the trick is to get all of the X’s to the left of the diagonal. Notice that for the example we are showing this is impossible. Then, the best solution is to do the tasks that require iteration at about the same time.


The Design Structure Matrix represents the relationships between design tasks.

By changing the order, or organization, in a more complex situation, it is possible to make the process much more efficient. Although the author uses design processing examples, we as information developers can apply these matrices to interface design or documentation.

For more information, read the article in the Harvard Business Review and visit Steven Eppinger’s Web site at