Stage 3
Design and Prototyping

When you are starting the design process, it’s natural to start focusing on the thorny details of trying to solve the immediate business challenges. It’s tempting to want to go deep into designing the specific features you believe will represent the first release. But design (like architecture) must balance near-term needs with future thinking — you must keep in mind your longer-term aspirations and business vision (identified in the business use case) to guide the evolution over time. So, it’s critical that the Design and Prototyping stage of the lifecycle focus on the whole solution — you’re defining the long-term vision and architecture, not merely a few of the immediate parts.

Another key tenet of this stage is that you should try to leverage the power of the no-code platform to define the design of the application directly. Instead of putting the functional requirements into an intermediate document and then translating it into code at a later stage, the functional requirements and design process in no-code development are much more efficient and streamlined. A no-code architect should define an application with all the needed parameters using the no-code tools (e.g., fields, dashboards, UX/UI, and workflows) and make changes on the fly when presenting and evolving a prototype. Unlike traditional prototyping, with no-code, you’re building the software itself. It’s not a simple low-fidelity wireframe or some type of “throw-away” clickable prototype — you’re building a working iteration of the final application.

The Design and Prototyping stage should be performed using the no-code platform visual tools themselves. This allows for rapid ideation cycles where the design effort more directly and immediately can be tested with end users. While the exact number and type of tools will vary depending on which vendor you select, there are typically at least five major design activities performed during this stage:

UX/UI design

The no-code stakeholder is the primary business owner of the requirements and is the person ultimately accountable and responsible for representing the sponsoring business function or unit. There should only be one business owner, and they will act as the ultimate viewpoint when it comes to making any decisions on requirements or priorities.

Workflow and logic design

Designing business rules and processes (both human and system processes) using a visual workflow designer.

Integration design

Designing how the app will connect to other systems of record or databases, using application programming interfaces (APIs) or connectors.

Dashboards and analytics design

Designing the pages or reports that will provide analytical insights.

Each of these will be briefly discussed in the following sections.

Usually, the first step in the prototyping process begins with defining UI elements for the input of business data, typically by providing a visual forms builder. The capabilities of the forms builder may vary, but they will usually offer some sort of “drag-and-drop” design (from a standard palette of UI controls or “widgets”) onto a visual canvas that allows you to design the form and its required elements. More sophisticated no-code tools will already have the needed components to provide optimized and consistent UX, including templates and recommendations. They will also have a larger library of controls, and some may even offer the ability to find and import controls from an external marketplace for even greater levels of customization and flexibility.

The data model is usually connected to the UI, and advanced no-code platforms allow you to combine data modeling with UI design. This is especially powerful during this Design and Prototyping stage as it allows you to iterate very quickly without having to separately define the data model. Another powerful benefit of this stage is the ability to rapidly build the UI within the no-code tools themselves; there is no need for external prototyping tools, such as Figma, Adobe XD, etc. as the prototyping is done seamlessly within the no-code platform.

Beyond just defining the form, this step of the design process also typically includes some implicit business process steps associated with the UI. The form data will nearly always require some business rule validations before you can leave it. This usually also includes the required inputs/output events (or triggers) that may be linked to the form and the chaining of multiple forms into a mini workflow (if the input steps will not all fit into a single form). The forms may also be dynamic, with defined rules or conditions that may cause optional or dynamic parts of the forms to be displayed. All these additional layers of form design help make the input easier and more intuitive for the end user, but they require more detail and definition during the design process.

The UX of the no-code app is often (but not always) a composable UX (i.e., one which represents data from multiple other systems). The benefit of a composable UX approach is that it provides a simpler experience for end users by allowing them to enter data into the app once. Users do not have to navigate to multiple systems and reenter the same data multiple times. This can provide great improvements in productivity and speed of data entry.

Many no-code tools will offer the ability to define the business process, but this is an area where there is a fair degree of variance in capability. On the simple range of the spectrum, the no-code tool may simply provide the ability to chain multiple forms together to express navigation through the application. On the other end of the spectrum, more sophisticated no-code tools will offer a full-blown business process designer that visually describes the business process, typically in some type of process notation. Some may offer support for industry standards like Business Process and Model Notation (BPMN). BPMN-enabled designers are great as they represent common knowledge across different stakeholders and can be easily read by different groups/users.

During the Design and Prototyping stage, it’s usually fine to focus on the “happy path” process (i.e., focus on the default process featuring no exceptional or error conditions). Later, during the next phase, we will come back to the design activities and add in more variant and exception paths but, for now, the simple process will help test the vision. It is important, however, to also think about more than just workflow and incorporate business rules and additional logic because it might be useful for the stakeholder.

While the high-level business process may be simple to understand, process definitions can sometimes quickly become more complex during the design process. The top-level business process may call many lower-level subprocesses to address specific variations or common activities within a process. The nesting of processes is not technically required — you could define all the steps as a single, large process — but proper nesting of processes is encouraged as it will ultimately improve both the ease of understanding and reuse of your process definition. For example, a top-level order processing workflow may call a nested inventory picking workflow to ensure products are reserved and picked for the customer before returning to the next step of the top-level workflow. Nesting prevents you from creating one monolithic workflow that is hard to understand and maintain.

The ability to describe the business process visually is very important as it allows the business stakeholders to describe requirements in a language that easily matches the way they think about their business function — a sequential flow of decisions, actions, and results. This allows them to provide feedback more readily on both the accuracy of the current process (if you are automating a process that exists), and it helps them envision TO BE processes that you may be introducing.

The integration design is an essential part of nearly every no-code tool. This allows your no-code app to work with the business data from other applications, and it helps your app fit into an existing set of IT applications and data sources. However, the integration design capabilities will vary tremendously across no-code tools. Some may be limited to only working with a few data sources, such as working with spreadsheets or database tables. Capable no-code platforms will offer a broader selection of ready-made integrations (usually referred to as “connectors” or “adapters”). Sometimes, they will even offer a broader marketplace where you can discover and reuse prebuilt integrations that are offered by either the vendor or by their community.

During prototyping, try to keep the integration simple — this stage doesn’t typically require full-blown data integration but just an illustration of the possibility. You will find that representational state transfer (REST) and simple object access protocol (SOAP) services are often the best way to set up easy data exchange, or you may be able to use a prebuilt connector. In the next phase, you may need to get into more complex integration design activities. For example, you may have systems for which there is no off-the-shelf connector — it may be because it’s a custom application or because it’s a less commonly used system (and the no-code vendor or their community hasn’t yet seen sufficient market demand to build a connector). To handle these scenarios, typically no-code platforms offer some type of Software Development Kit (SDK) for building custom connectors if one doesn’t already exist. However, this will require additional custom development skills to be part of your project team. It also may require coordination with the no-code vendor to operationalize the connector into your runtime environment if your platform is running in a cloud environment.

Some additional notes on integration design:

• It is usually highly recommended that no-code tools NOT map directly to another system table or data source. This creates a dependency on the underlying system, which can cause the no-code mappings to “break” if the other system is upgraded or changes its data model. Instead, most no-code tools will use a standard API for any systems to enable them to be more resilient when the applications are upgraded.

• While the no-code platform may offer prebuilt integrations, this does not remove some of the fundamental complexity of internal application integration. Your IT department may have heavily customized or extended the existing systems, which may require additional logic to be added to the integrations or mapping. This is where a fusion team may be required.

• You may need to consider data migration requirements as part of this activity as well. This may be needed if the integration is more of a one-time load of data files into the system or if you are replacing a legacy system (and need to preload it with key reference data). For migration/import of data, you should attempt to find the easiest path; for example, a common approach is to import existing data through Excel files, which are usually supported as a file format across a wide range of systems.

This design activity guides the prototyping of the pages or reports that will provide analytical insights. The no-code tool will typically offer some way to visually compose a dashboard or report, often through drag-and-drop of prebuilt components into a dashboard page. This will be similar to the UX/UI forms design but will leverage prebuilt visual widgets (e.g., bar charts, line charts, and highlight tables) to assemble into a dashboard page. There will be some way to configure these widgets to connect them to data from other systems. There may also be a set of prebuilt components available through the vendor’s marketplace that can offer a rich set of visualizations and data sources.

Dashboards are important as part of your no-code app design to help employees to monitor the performance of the business use case at once. With just one UI form, the user has a more limited view of the process. Having a dashboard allows users to view multiple visualizations at once and understand the business from many different angles. Dashboards also make it much easier to compare data on the fly as they can group together related data visualizations into a single page that allows users to quickly get a sense of how those visualizations are related in real-time. This allows your users to make connections in the business data that can drive new insights and enable taking more holistic actions to improve the process.

Finally, dashboards help your no-code app make better use of the data that is already collected, making it contextual, holistic, and actionable. Having embedded dashboards within your no-code app can help every aspect of your users’ operations by enabling them to become more data-driven and allowing them to leverage that data to drive insight and focus on the right areas. One good place to start is by focusing on targeted key performance indicators (KPIs) that are meaningful to your business process. KPIs are the metrics that will be used to determine whether a process is performing successfully. This helps the average user focus on the top improvement areas and helps improve overall levels of impact and efficiency.