Design

Introduction

This is a set of defaults for teams to use, but is not mandatory if teams have good reason to do something different (see What this is — and is not).

This section covers the broad topic of design as applied to experiences, business processes, experiments and technology.

Overview

In the context of product development, design can be used to reduce uncertainty and/or specify requirements. For example, an Interaction Designer might create a mock-up of the home screen of an app and use it to test whether users understand and value the proposition. Likewise, an engineer might create a high-level architecture diagram to explore technical designs and align understanding of the different technical components and their relationships, within a target solution. Design should be a collaborative and iterative process and should revolve around meeting user and business needs.

Experience Design

There are many methods to approximate and communicate an experience. Depending on where you are in the solution development lifecycle you will use different methods. In the initial stages, you should be more concerned with trying to define the bigger picture in low-fidelity. From there you can refine the design by validating the initial vision and iterating toward higher fidelity and, where appropriate, narrower scope. For example, designing different component states and unhappy paths.

Experience design principles

Design principles are value statements that frame design decisions and support consistency in decision making across teams working on a product or service. These are Infinity Works' design principles:

The three Fs: fit, function and feel: The thing we are designing should fit a user's need and place in the market; it should function as expected; and the way it feels should make people want to use it, regardless of whether they need to or not.

Design for everyone: We ensure the things we design work for everyone, regardless of their context or abilities. Designing for the edges makes products and services better for all users.

10x not 10% better: Our goal is to make things 10x better, not 10%. This requires using divergent thinking and systems thinking, and understanding how outcomes affect impact.

Systems, not pages: We take a systematic approach to design which creates the opportunity for reuse, minimises effort, and improves consistency. This does not mean being uniform, it means designing in harmony with the whole.

Data modelling

Data modelling is the process of analysing and defining the different data an organisation collects and creates, and the relationships between that data.

The goal is to create a visual representation of the data that accurately describes the data structure, how data will flow through the system whilst highlighting important data relationships. This can involve both the data input and output, whether generated through standard modelling techniques, predictive models such as Machine Learning / Artificial Intelligence or other means.

The process itself is an exercise in understanding and clarifying your data requirements.

Business processes mapping

Business process mapping details the steps that a business takes to complete a process, such as hiring an employee or ordering and shipping a product. They show the "who," "what," "when," "where" and "how" for these steps. These maps are also called business process diagrams and business flow charts. Like other types of diagrams, these maps use defined symbols such as circles, rectangles, diamonds and arrows to depict the business activities.

High-level architecture

The system architecture should be led by user and business needs, with a particular focus on non-functional requirements. From the start, you need to be thinking about how the system will work when it is running in production (see Operations).

Communicating a clear technical vision helps people stay aligned. It needs to be detailed enough to be a useful guide, without constraining or presupposing decisions that are best made during implementation. It also needs to be kept up to date to stay relevant as more is learned during delivery and the design evolves.

Technology selection

An important aspect of technical design is choosing which technologies to use. Some things to consider:

• Will any existing systems or components be reused?
  • Do they do what is needed or do they need to be modified or extended?
  • Do they need changes to meet required non-functional requirements?
  • How easy will that be?
  • Are they documented?
  • Is there good automated test coverage?
  • Is the code well-structured?
  • Are people who know the system available to help or advise?
• Are there restrictions on which technologies you can use?
  • Existing commercial agreements?
  • Limited skills present in the client organisation?
  • Strategic organisational preferences or prohibitions? For example, which cloud platform to use.
• Cost and the effect of the commercial model.
  • Pay-as-you-go tech makes it cheap to create ephemeral or long-lived test environments which have the same structure (though not necessarily scale) as production, and should generally be favoured.
  • Do some calculations about how the cost will scale to meet expected demand; in some cases, tech which initially seems cheap can end up very expensive when used at scale.

When choosing technologies, favour those you and staff in the client organisation are familiar with, but try not to be too constrained by that if it prevents you from choosing the right tool for the job. It is a delicate balance to strike, and one which needs careful thought.

Do not make any tech choices without proper investigation. Trawling the internet or asking around is a great way to generate some options, but you should try out the tech before settling on the answer, unless it's something you're already familiar with. (See Proofs of concepts).

Get in touch with an Engineering Practice Lead or other Tech Leads to walk through your thinking. This is a great way to validate your design and to share learnings.

And of course, remember that as consultants we are there to advise and recommend, but the customer is always in charge of making the final decision. Help them make the right decisions — ask for help if you feel they're making a mistake, and you're not able to help them realise the best possible approach.

Further reading:

• Design Docs at Google.

Explore and communicate the architecture

Visualise the architecture in a way that is easily accessible to the whole team and external stakeholders.

• Focus on simplicity and clarity.
  • Avoid complicated diagramming methods or those which cannot be readily interpreted by casual observers (such as ArchiMate or the more complicated UML diagrams).
• Have a clear purpose for each diagram.
  • For example, the authentication/authorisation flow, how sensitive data flows and is kept secure, or what makes the system resilient or scalable.
  • Do not try to squeeze too much into one diagram. Several simple diagrams are easier to understand than one complicated one, and more effectively drive clear thinking and useful action. In doing this, some information may need to be duplicated in multiple diagrams, but a little duplication is worthwhile for the added clarity.
• Use the right scale and level of abstraction for your diagram. As you "zoom-out", represent complicated subsystems with a single box when appropriate to keep the diagram simple.
• Use a mixture of diagram types — see below.

Further reading:

• The Art of Crafting Architectural Diagrams.
• Everything you need to know about architectural diagrams (and how to draw one)

Box and arrow diagrams

Box and arrow diagrams are an informal general-purpose way to represent system components and how they relate. Components are shown as boxes that are connected by one-way arrows.

• Annotate arrows, showing things like the request being made, the data passed, or the protocol used. Do not show information that is obvious or clearly implied, but favour showing more rather than having bare arrows.
• Establish a clear meaning for the direction of the arrows and be consistent in using it. For connection-based systems (such as those where the arrows represent HTTP or TCP calls) it is often sensible to draw the arrow from the client to the server, representing the direction in which the connection is established. When the direction of information flow is more important, you could instead choose that as the determining factor in the direction of the arrows. If information flows in both directions, draw this as two one-way arrows, with each annotated appropriately.
• Use colour to make diagrams more appealing, but do not rely on it as the only way to represent essential information — people with a colour vision deficiency may not be able to properly interpret such diagrams. Use labels and/or shapes in addition to colour.
• Avoid the use of logos as annotations or in place of simple boxes, as are sometimes used for cloud infrastructure diagrams. These are not as easy to interpret as simple boxes and get in the way of understanding.

diagrams.net (formerly draw.io) is a good, free, general-purpose online diagramming tool that avoids the limitations of many alternatives.

C4 Model

The C4 Model provides specific terminology for different scales of the diagram, which some people find helpful. It is not prescriptive about the details of how diagrams are formed, with boxes and arrows as the default.

Sequence diagrams

A sequence diagram shows interactions between entities in a system. It is a great way to clarify how the parts of a system interact chronologically for specific behaviours. Sequence diagrams are one of the most useful UML diagram types. Further reading: geeksforgeeks.org.

Several free code-driven web-based tools exist to create sequence diagrams: for example, sequencediagram.org and swimlanes.io.

[Image: geeksforgeeks.org]

Activity diagrams

An activity diagram is a kind of flow chart showing conditions and constraints which control the flow of activities. An activity diagram is a good way to model a business process, showing the sequence of events and actions. These diagrams are particularly useful for exploring all options fully, including edge cases and error scenarios. Activity diagrams are another of the commonly-used UML diagram types. Further reading: geeksforgeeks.org.

Options to generate activity diagrams from code are limited, but one free online tool is PlantUML.

[Image: geeksforgeeks.org]

Database schema diagrams

Relational database schemas are typically shown using Entity-Relationship Diagrams (also known as ER diagrams or ERDs). While the use of specific notations to show essential information means these diagrams can be hard for the uninitiated to fully understand, they are ubiquitous, and it is useful to be familiar with them.

Many database development tools will allow you to generate ER diagrams from an existing database. dbdiagram.io is a lightweight online tool to generate diagrams from scratch.

[Image: Guru 99]

Proofs of concepts

Architectural and technology decisions are best viewed as provisional and are dependent on what is learned during implementation. The best way to make a decision is often by trying out options with a "spike" to explore alternatives through throwaway proof-of-concept (PoC) implementations. (See Just enough, just in time.)

PoCs should be:

• Quick and simple, usually time-boxed.
• Focused on what will help you learn the most.
• Thrown away.
• Unbiased.
  • When you are trying to choose between alternatives, keep an open mind to all options and try not to presuppose the outcome.
• Used when there is a decision to be made (such as which CMS or logging library to use), rather than just to learn more about how long an already established approach will take to implement.
  • Where there is uncertainty about how long something will take, simply start by taking the thinnest vertical slice you can and implementing that; the extra time to implement a throwaway spike is unnecessary and wasteful.

What next?

Now that you have designed an experience, technical architecture or business process, it's time to get some valuable feedback to see if it meets expectations or whether it requires further iteration.