Applying a design authority role, pt 1

I’ll start this off by saying that there is in my mind, not one role that is defined by Design Authority.

There are in fact three.

Program Design Authority:

This Design Authority is ‘single point of truth’ for the design of a Program. Programs deliver benefits to an organisation. The projects that are within the program are responsible for delivering the outcomes, which map up to the programs benefits. (‘Outcomes’ delivering ‘capabilities’, which deliver ‘benefits’.)

In the program context, the Design Authority marshals the capabilities that are required to deliver the desired benefits, and subsequently the outcomes from the sub-projects.

Over time, through feedback from the sub-projects the Design Authority will monitor the development and the alignment of those projects with the overall capability requirements of the organisation.

Enterprise Design Authority:

Similar to a Programs’ Design Authority, however the Enterprise Design Authority holds a persistent or lasting role, whereas program design authorities will cease to be useful once the program ends.  The Enterprise Design Authority preserves the Enterprise business intent, and provides design assurance for the programs of work within the enterprise.

Visual Design Authority:

This is the role that is more common and would be familiar to anyone working in a development environment.

The Visual Design Authority is the role that is responsible for the ‘design strategy’, as it relates to all things visual or interactive. This includes aspects like how the visual appearance evolves of a website, or what methodologies are in place for the design of interactivity or business processes, whether or not information architecture principles are applied and how and when and by whom.

Everyone needs to set up the Design Authority in the way that best suits his or her purpose. The term design means different things to different people; hence since I come from more than one space (being both the interface design, enterprise design spaces) I can see both points of view.

Why I like the concepts around the Design Authority is that it removes the ambiguity of where the assurance responsibility lies. In many contexts this role can be very useful, especially in terms of assuring alignment of effort with the original vision, and in terms of providing consistency and stability of visual design output and approach.

Even for small business this can be useful, because where resources are limited and time is short, effort that isn’t true to the original goal can be expensive and sometimes crippling.

Within the private web development field I would even actually say that the concepts behind a Design Authority, could hold a lot of value in terms of quality assurance. Where the outputs of a development team can be independently reviewed against the original client intent, which ALWAYS looks good.

This Design Authority role is ever expanding particularly as there is more and more rapid work or agile work being done in the software / web development space.

In light of that, if you would like to pitch a question about what a Design Authority role could do for you, or if you want to comment on how you use a Design Authority already, I’d love to hear from you.