Introduction to Design

Much like Alice in the famous fairy tale “Alice’s Adventures in Wonderland,” you may be tempted to start charging down the “no-code rabbit hole” by immediately building your first app without really having a clear plan of where you’re heading. Because it is simple to build no-code apps, it’s easy to immediately get immersed in the details of app building and lose sight of the bigger picture. But you will regret this later in your journey when you get bogged down in the complexities of project delivery without a clear view of the essentials needed to ensure successful business outcomes. Or worse, like Alice, find yourself at the wrong destination, and end up with an app that doesn’t fulfill your needs.

You might ask, “Isn’t this just like any other software development project?” It’s true that the concept of application design is not new. Design activities of some fashion have been part of the software lifecycle since computer programming was first invented. However, to make full use of the no-code benefits outlined earlier in the book, it’s important to recognize some fundamental differences in the Design Phase of a no-code project compared to a custom software development.

Traditionally, design activities in custom software development involved a high degree of technical notation and abstraction that required advanced technical skills that most business users don’t possess. This was needed to translate the business requirements into specifications for the technical components and architecture that a programmer used to start writing code. For example, a skilled business analyst might have used Agile “user stories” and specialized tools to design the user interface and capture the workflow. However, these tools require another person to “translate” those designs into detailed specifications that are useful to a developer. This translation process was often complex, time-consuming, and prone to transmission errors.

That’s why design work has often been done by developers or technical architects. However, the roles are different in no-code projects (as we explored in Chapter 4). Business stakeholders and end users are more directly involved in the design itself because no-code tools and processes are more accessible to nonprogrammers. For lower complexity applications, the business doesn’t need any support from IT at all! This has a fundamental advantage in terms of improving the alignment of the design with the business needs.

Another difference from traditional software development is the efficiency of the design process. Typical software development depends on creating intermediate design specifications and technical documents that serve as the “bridge” between the business function and developers. While software design specifications and tools have improved greatly over the years, they still all suffer from similar challenges. Design documents often suffer from the “telephone game” problem — introducing transmission errors at an early stage of their development. They are laborious to create in the first place and even harder to keep updated — it’s common that many design documents become out of date almost as soon as the first version is released and the application begins to evolve. With no-code, the work of the Design Phase is to use the no-code tools directly as much as possible. This results in a “living” design model — the design and the implementation are updated simultaneously over time from a shared model.

Another inherent challenge of traditional development projects is maintaining the accuracy and fidelity of the original business requirements when it is communicated and rolled out across the team. You may start with a clear and simple definition of high-level business needs, but these quickly become obscured as more levels of detail are defined. Each step in the design process must, at some level, translate the original intent into a different lower-level set of more detailed constructs. This is very much like the classic party game, where one person tells a story to another person. As the story gets repeated multiple times, errors in translation begin to inevitably creep in. You may end up with something that, at the end of the project, bears no resemblance to the original intent. With no-code design, there is a singular definition of the application — defined and updated throughout the lifecycle using the no-code tools. This improves the accuracy and understanding by eliminating handoffs and reinterpretation. All stakeholders across the business function and development can share a common view without requiring translation into intermediate documents or semantics.

Finally, one of the challenges with any software design is that it must be aligned (and continually realigned) as the needs of the business change. Ongoing changes are a given in the rapid and dynamic environment in which most enterprises compete. This may be continuous improvement of business processes, innovation of new products or services, or responding to a new competitive threat. As the pace of business increases, the software applications that your business depends on must also be continuously updated, creating the risk of introducing misalignment. The business function may have already adapted to some external process change, but the software development teams don’t yet fully understand the intent, which means the app doesn’t fully reflect the present state of the business. With no-code projects, bringing together a commonly shared view across business and development helps improve the business alignment with the application itself.

It’s time to examine in more detail what a No-code Design Phase looks like. While it may sound daunting if you lack a technical background, don’t be alarmed! It’s quite straightforward and composed of four key activities. Each of these will be described more fully in the following chapters, but let’s briefly discuss the essential stages:

Stage 1 Business Use Case

The first stage defines the highest-level business requirements for the solution you’re building and outlines the criteria for business success. During this stage, it’s important to keep at the right level of detail by focusing on the “what” and the “why” but not the “how.” While it’s tempting to get into details such as defining the application UI or specifying inputs/outputs or technology components, the Business Use Case stage should focus solely on higher-level requirements and business processes. In Chapter 7, we will give examples of appropriate levels of requirements and define a simple template you can use to capture and understand the business requirements and evolution over time. This stage should also consider the full-picture definition of the business. It’s important to not start constraining yourselves too much about how this might be broken into releases over time. That will come later, but for now, maintain a broad view of what the solution needs to be.

Stage 2 Options Analysis

The second stage helps start to decompose the overall solution vision and shape the fundamental building blocks of the solution by selecting the right combination of packaged software, custom development, no-code development, templates, and components. This particular stage can seem overwhelming at first, given the potentially large number of options available, but we’ll help you simplify this process with a basic decision framework. This will help minimize the number and complexity of elements in the overall solution and reduce the ongoing effort required to maintain it.

Stage 3 Design and Prototyping

This stage looks broadly at the vision identified by the business use case and uses visual prototyping techniques to quickly ideate and imagine the breadth of the solution vision by defining user experience (UX)/user interface (UI), workflow, analytics, etc. Importantly, work activities in this stage will be performed using the no-code tools themselves — not intermediate document specifications that are later turned into code. The focus of the prototyping should be breadth over depth — you’ll flesh out rapidly what appears to be a working iteration of the solution within the no-code environment itself. It will seem to have most of the desired business processes, forms, etc., but the depth of the functionality and logic may be incomplete or stubbed out. The scope of this stage is still the broadest possible view of the solution (in alignment with the Business Use Case). Do not constrain your project by scoping down into releases yet.

Stage 4 Project Assignment

The last stage decomposes the vision into smaller use cases/apps/components. This is where you begin to define your target roadmap by focusing on the smallest possible initial scope that delivers business value — what is often referred to as the Minimum Viable Product (MVP). The MVP must deliver a minimum amount of utility quickly without being bogged down by the fullest view of the features and functionality that will be added over time (these will be added incrementally through a set of rapid updates). Think of this as the minimum number of features required to make the first version of the product useful. As this MVP release is defined, you will make key decisions on prioritization, what must be delivered first, the sequencing of dependent features, etc. Finally, you will apply a key framework called the Application Matrix (introduced in Chapter 5) that determines the right delivery model based on assessing the complexity of the application. The identified delivery model will guide the assignment and organization of the required resources (e.g., budget, roles, system environments, etc.) needed for the first release of the application.

The Design phase may sound like a sequential activity, but it should be largely iterative — activities performed later in the Phase may uncover new ideas or opportunities that should trigger you to iterate on earlier thinking. This is typically true as you prototype the vision and design — you’ll think of things that may inform changes to the business process. Unlike classic software development, no-code design allows the business vision to be influenced at times by the “art of the possible” and to respond to new or innovative ideas. This is a very powerful concept that will encourage innovation — no-code offers the ability to make changes to design easily and quickly while immediately validating a working model with business stakeholders. This means the cost of experimentation is lower, compared with traditional software development approaches, which encourages the use of ideation and iteration techniques and a boldness that comes with a “freedom from failure” approach.

This may sound like a lot, but it’s quite straightforward. Each of these stages will be explored in the following chapters, along with guidance, sample templates, and practical tools that can be used at each step along the way.