The difference between commercial success and failure could be simply the difference between good design and poor design, but it might also be a symptomatic of a problem in the approach or methodology being used.
(Ed. and 101 other procedural, people or political problems)
We are familiar with designs for buildings (architects drawings) and engineering designs (blueprints). Similar disciplines and templates apply when designing software and IT systems, subject to industry and house rules and best practice guidelines…either implicit or explicit design principles.
IT and business projects sometimes talk about green field sites and working with a blank piece of paper to indicate the absence of constraints, that is not having to work with or around existing (legacy) processes, systems or technology. The freedom to work unencumbered on something brand new is tempting.
If a project, product or service was every truly new and stand-alone, i.e. separate from its environment (Ed. it isn’t), you could ignore the following:
- Integration and compatibility (inter-operability)
- Customers and Users come with expectations, knowledge and prior experience
- Standards; a formal repository of good design knowledge, guidelines, patterns and templates, and the skill and experience to apply it
- More informal heuristics or rules-of-thumb (ditto)
- Past successes and mistakes, which will (should) inform the current activity
- The future; whither ongoing support, development, maintenance & change management
All these factors are part of the recipe for good design, together with a pinch of creativity, leadership and luck.
What is design?
In simple terms, the design defines ‘how’ something will be built or created, realising the stated requirements or more informal needs i.e. the ‘what’ (and to some extent the why, when and how much). In a typical waterfall-type project, the requirements stage is followed by design, which is followed by development/fabrication etc. Each linear stage informs the next stage and subsequent activities. For example, these statements or predicates (sometimes used to define programming logic) could be used to measure the success of the project and how suitable the finished product is:
- The requirements specify the [needs|desires!expectations] of the [sponsor|customer|user]
- The design meets the [functional|non-functional] requirements
- The design meets [legal|regulatory|technical|operational|strategic] criteria
- The finished [product|service] meets the design specification
- The finished [product|service] satisfies the requirements – a virtuous circle
There are other factors like cost, timescales, testing activity and other measures of Quality, available technology, materials and skills etc. but I think it’s clear that design is key to getting the right outcomes.
Let me expand the possible criteria for a [good] design, (2) & (3) above. A good design should consider the following…imagine a conversation in a green field (literally) where a property developer says to a builder, ‘I want a housing estate here.’ The design of the houses, the access and utilities infrastructure, the marketing and sales activity, for example, should include generic elements such as:
- Functional requirements, i.e. what the product or service should do/achieve, its features and capabilities, what it does, not necessarily how it does it
- Accessibility, usability and availability for all potential users
- Other non-functional requirements such as performance, security and other ‘iliities’ in IT terms, reliability, scalability, configurability, maintainability etc.
- Compliance with internal and external standards, regulations and laws, including safety, sustainability and copyright etc.
- Alignment with corporate strategy, including technology or architectural frameworks
Reading down this list, the opposite of good design is failing to meet these criteria, which might result in the product not being fit for purpose, not being reliable, failing foul of regulations etc. So design could be seen as a defensive pursuit, mitigating the risks of not doing certain things adequately. In a wider sense Projects are concerned with doing the right things and doing things right to achieve the desired outcomes.
I mentioned ‘marketing and sales’ above. Historically these were a separate set of activities, considered after the build. However, the ability to market, sell and distribute something has become almost the first consideration, as mentioned in IT elements Brand and Strategy, particularly in crowded markets, with faster time-to-market cycles, globalisation etc. Is good design ultimately about how much of something is sold or used, not some inherent and immutable measure of quality?
How and what to design?
The outputs of any design activity tend to be specific to the technology and domain, e.g. software, buildings, engineering parts, clothes, education materials or best practice procedures etc., as well as the process undertaken and the methodology or framework adopted.
However, the following themes and elements of design are common or similar across multiple disciplines. These examples are typical for technology and software systems.
Templates or [design] patterns provide a proven reusable framework or best practice for designing and fabricating multiple copies or instances of the same or similar artefacts. At one end of the scale of reuse are methods and common approaches, all the way to a cookie cutter solution.
Software that is copied and modified (Ed. you may be familiar with copy-and-paste actions in word processors and spreadsheets?) does not constitute a design pattern because a formal process is unlikely to be followed, nor will there be evidence of what the developer did (traceability). Copying code may be efficient and practical, but it may also reproduce design flaws and defects; moreover, we know that a design should meet the needs, so copying the finished product may not be a correct solution or best fit?
Design patterns do however allow for reuse of code fragments or modules or configurations of existing components. However, this may require other disciplines and recognition of an inventory or architecture of constituent parts that make up the whole finished product.
Most non-trivial designed things (products or services) benefit from early modelling of the requirements, the design or a [nearly] finished product to demonstrate (‘demo mode’) or test particular features or capabilities of interest.
There are many different types of prototype or model produced at different stages of a product’s development lifecycle. Software as an intangible product offers much more scope for multiple build-review-modify cycles.
Low- and high-tech prototypes are an essential part of the design process. Although the terms are flexible, low tech is likely to be a visual mock-up or wire-frame of the finished product with very little functionality ‘under the bonnet’. A high-tech prototype may look indistinguishable from a fully working product, but may be lacking full connectivity or build quality and may not meet non-functional requirements.
If a product or service is essentially ‘finished’ it may undergo internal (alpha) or selected external (beta) testing. Depending on the audience and expectations of the production roll-out it may be a trial, intended as a proof of concept (POC) or proof of approach for a process – essentially an extension of testing in live use.
Finally in this section one of the most important subsets of non-functional requirements that a designer needs to be concerned with, how usable an application or product is. Not only does your computer game, chair, smart phone or bridge need to work, but it must also be:
- Accessible to all potential users in different situations and environments,
- Intuitive and easy to use (or learn how to use),
- Provide the necessary feedback and messaging to the user,
- And many other criteria.
Usability or usability engineering (UX) is covered by its own IT element.
Earlier in this module I talked about a traditional sequential product development lifecycle with a discrete ‘Design’ stage. Increasingly in computing the design is absorbed as part of [software] development, although there are specialisms such as graphical design (design and production of illustrations and artwork) and User Interface/usability design. There are also domain experts involved in architecture, network and database design, for example, which are closer to [hard] engineering disciplines.
I hope you found this interesting? If so, you may want to read about Requirements that traditionally precede design, or Development and Testing that follow. Despite a tendency to try to squeeze these separate activities together, good design still matters.
© 2016 IT elementary school