Design can operate at many levels within an organisation, with different benefits to bring in each arena. However, in practice, designers and user experience practitioners are often often stuck in a relatively narrow slice of the overall process. This is partly because management and other stakeholders have a limited view of what design and research can offer; but designers also bear some responsibility for not taking the initiative to extend their work where they can.

In this post, I present a model of the various levels of design within an organisation and discuss what kind of activities designers and researchers can undertake at each level and what benefits they can bring. This is not intended as a description of a design process, although there is obviously a relationship with that question.

I identify five levels of design: Strategy; Project; High-Level Design; Specification; and Agile Deliver.

STRATEGY LEVEL 

At the highest level, businesses and products need to decide what to do:

• Which strategic direction to take.
• What business model to pursue.
• How to expand and capture new business.
• How to consolidate and secure existing customers.
• How to simplify and reduce costs.

Decisions might be taken to:

• Create new products.
• Update or overhaul existing products.
• Add features or functionality to existing products.
• Rationalise product lines by combining products, or eliminating some altogether.

This is the level at which Research & Development might create innovative new possibilities using new technologies or production methods.

How can research contribute at this level?

At this level, broad-based, open-ended research can contribute in several ways:

• Research with clients can help to identify frustrations with current products and new business opportunities.
• Research within the company can help to identify process issues and cultural challenges that may need to be addressed in order to implement the strategy.

More targeted market research can:

• Help to validate the viability of different plans.
• Establish market share and key competitors.
• Identify key features for new products and key enhancements for existing ones.

Usability testing can:

• Help to identify key challenges with existing products that would be worthy of significant investment.

How can design contribute at this level?

Design thinking is crucial at this level in order to help formulate strategy and to help articulate it effectively. Designers can provide creative solutions to problems and opportunities identified by the business. They can consolidate disparate ideas into a single coherent story that helps the business to reach agreement, communicate their intentions and seek agreement from senior management.

Concept design projects can be used to explore the impact of new technologies, business models and innovative ideas; acting to provoke discussion and inspire the organisation.

Crucially, designers can play a role at this level in both consolidating and expressing the ideas that the business has; and in contributing their own ideas into the strategic discussions.

PROJECT LEVEL 

At the project level, a decision has been taken (at least in principle) to do something – perhaps building a new product, or adding a new feature to an existing one. The key activities at this level are:

• High-level requirements analysis and prioritisation.
• Estimation of development effort.
• Analysis of the architectural requirements; research and exploration of possible solutions.
• Planning how the project can be resourced and funded.

How can research contribute at this level?

Depending upon how far the project has progressed, targeted research can be used to:

• Validate the business viability of the project.
• Identify and validate client’s requirements and their priority.
• Establish key competitors and their strengths and weaknesses.
• Validate the logic of initial design decisions.

How can design contribute at this level?

Designers can contribute at this level by analysing the project aims and requirements and proposing a basic design direction. For example:

• Addressing questions of the basic form and style of a potential solution (e.g. Installed application vs. Browser-based delivery).
• Considering how the solution could be integrated into the rest of the product; or how the new product should interact with existing ones.
• Creating a high-level vision of what the end result could be like, that will help the whole team understand what is required; better communicate amongst themselves; and better sell the project externally.

At this level designers play a key role in solving basic design questions and helping the team to express to themselves and others what they are building – something that is often not clearly understood by the various participants. Designers can also play a crucial role by challenging the initial project assumptions and suggesting potentially radical alternatives – e.g. enhancing a related feature to achieve the same aims, rather than building a completely new one.

Designers should work closely with Developers and Architects to help them understand what is really needed and in turn to understand the key technical challenges. This two-way exchange can lead to better development estimates and improved technical solutions; it can also lead to revised and simplified designs, or improved designs that make use of previously unknown technical capabilities.

Key deliverables at this point may include wireframes, but they are more likely to include charts, diagrams, navigation flows, glossy visuals and well-crafted presentations intended to sell the project.

HIGH-LEVEL DESIGN

The High-Level Design level may follow on directly from the Project level; overlap with it; or be delayed whilst funding and go/no-go decisions are pending. Once High-Level Design begins, the business has committed to the project, funding and basic timelines.

The key activity in this phase is the decomposition of requirements and prioritisation of the work. This is likely to involve the creation of detailed backlogs of epics and stories, often using some form of planning software.

How can design contribute at this level?

At this point in the project the role of design is to establish a sufficiently detailed expression of the whole solution that stakeholders can all agree to it. This needs to be a highly collaborative process and should involve multiple iterations.

The design is still a vision at this stage – just a more detailed one than before:

• It needs to be in a form that is easy for everyone to understand and discuss. It should be distributable and its message should be consistent and repeatable.
• It needs to help people understand what it would be like to use the product – what it might actually look like and the real navigational flows.
• It must be sufficiently detailed to answer the key design problems, without getting lost in unnecessary complexity – it should focus on the “happy day scenario”, ignoring error conditions, edge cases, and the needs of minority users.
• It should focus on a reasonable ‘ideal’ deliverable, rather than being too concerned with the need to deliver in stages.
• The deliverable needs to be reasonably light and easy to modify – otherwise it defeats the object of being able to iterate the design.

This might seem like the ideal time to use a prototype, but these are problematic for a number of reasons:

• They are often hard to distribute.
• They are not linear, which makes it hard for people to experience them in a consistent and repeatable way.
• It is hard to create prototypes which illustrate the overall design, but do not get dragged down into unnecessary detail.
• Prototypes tend to rapidly become heavy and complex, making them difficult to modify and iterate effectively.

Sequential wireframes are an ideal way of expressing design at this level.

This stage of the project can be seen as similar to the process of crafting a screenplay and developing storyboards and animatics for a movie. Note that in these examples there is nothing woolly or imprecise about the deliverables – they are attempts to create a full description of the movie, just at a relatively low level of fidelity.

How can research contribute at this level?

Research can be conducted with the design work to get user feedback on the actual design proposal. At this stage there are lots of details missing, but it is also early enough to make major changes if needed.

SPECIFICATION LEVEL

At the Specification level, the designer needs to take the vision that has been agreed in High-Level Design and turn it into a set of specifications that explain the detail of how each piece should work. The specifications should aim to be complete and fully detailed. However, this should not be at the cost of making them too heavy and complex – specifications are only valuable if they are actually used. For this reason, it makes sense to create multiple separate specifications for different pieces and aspects of the project, because this makes them easier to produce, easier to share, easier to read and easier to update.

Note that once development begins, the product itself will rapidly become the specification – it is far more detailed and complete than any document can be. Therefore, all specification documents need to be seen as disposable.

At this point visual design needs to work through all of the details too, including resolving transient aspects like selection states, rollovers and how elements respond to changes in window size or screen resolution. The first round of assets should also be produced, e.g. icons and cut outs. Designers may also provide CSS values or code snippets to help developers to implement the design correctly.

At the specification level, prioritisation and the staging of features needs to be considered. Specifications are needed for the first iteration of the highest priority features of the product, so these should be done first. However, where possible, they should include an indication of how the feature will be extended in the future.

AGILE DELIVERY

Once development begins, designers must work to offer close support through agile development sprints. Types of activities at this level include:

• Redesign work in response to problems with implementation, or as a result of new lessons learned.
• Creation of additional assets.
• Adding more information to specifications in response to development questions.
• Testing builds of the product, raising bugs, talking to developers to understand problems and suggest solutions.

This is the level of crafting the interface to get the details right – especially the level of detail which cannot reasonably be captured in specifications. As stated above, the product should be seen as the ultimate specification, rather than any document. It is impractical to create a specification that is as detailed as the product itself and clearly impossible to keep such a specification up to date. Instead, it is better to begin building without waiting for all the details and to work through these during the build. This is the essence of Agile as a development methodology.

This also means that while it might be valuable to refer back to specifications that were produced in the previous phase, or to update them to reflect changes, it will be more effective in many circumstances to ignore them and specify new work in the form of changes to the current system, rather than as absolute specifications. Change specifications will be easier for developers to read and make use of as they are much shorter and formulate clearly what the developer needs to do, as opposed to the developer having to figure out how the current system differs from the specification (especially given that the specification is necessarily incomplete).

How can research contribute at this level?

Research can contribute during development by starting to user test the actual product as features become available and feeding back findings in the form of improvements. At this stage, this process can be seen as one of ‘sanding off’ the rough edges of the product.

Whilst testing is almost always valuable, it can be made much more effective if it is explicitly tied into the development cycle and time is set aside within sprints to make changes that are identified. Without this, there is a danger that improvements need to fight it out in the priority queue against upcoming functional work and will inevitably tend to lose out.