Design and Prototyping

Step #1:
UX/UI Design

• Start by defining the list of user journeys for the application. User journeys are comprised of the sequence of steps or interactions a user goes through while interacting with the application. You’ll begin to model each of these UI within the no-code vendor’s drag-and-drop editor.

• You can create UIs from ready layout templates, such as pages with tabs and dashboards. You can also create a custom UI of any structure from scratch using the no-code UI Designer to structure page layout, tables, areas, columns, etc.

• Which are the most essential UIs to focus on within the prototype? Prioritize the ones that have significant impact to user performance or productivity, or which will have the greatest business value/savings as defined by the Business Use Case. Explicitly defining the priority UIs and journeys will help you invest more time in UX to gather the most stakeholder feedback and identify potential usability issues.

• What is the value delivered by this new prototype UX/UI over existing practices? Don’t just simply replicate a paper form into no-code – look for opportunities as you digitize to streamline the user experience by eliminating duplicate entry of data or by hiding/removing exception logic.

Step #2:
Workflow and Logic Design

• The Business use case likely will have collected a great deal of information about the current / future business process. You’ll begin to model each of these processes within the no-code vendor’s visual process editor. You can either design the processes from scratch, or if you have some BPMN compliant processes (using other drawing tools), you may be able to import them into the no-code vendor’s tools (if they support BPMN import), and then transform it into an executable process for performing an initial check of expected system behavior.

• A common example of a workflow is a purchase approval process, where purchase requests are submitted, reviewed, approved or rejected, and processed in a predefined sequence of steps involving different stakeholders such as requesters, managers, and finance personnel.

• In this 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.

• Think about more than just workflow and incorporate business rules and additional logic, because it might be useful for the stakeholder. An example of a business rule could be a pricing rule for a sales order, where the price of a product is determined based on factors such as the product category, customer segment, and quantity purchased. The business rule may specify if a customer is in the ‘VIP’ segment and purchases more than 10 items from the ‘Electronics’ category, a 10% discount should be applied to the total purchase amount.

• Also consider the inputs and outputs of the workflow, which will be important when it comes to connecting the process to back-end systems or data.

• As with the UI design, it’s important to clearly prioritize the list of in-scope processes to put the most focus on the processes and process use-cases which have the greatest business impact or productivity gains for the priority roles/stakeholders.

Step #3:
Integration Design

• When creating a prototype of an integration, aim for simplicity. This stage typically does not need a complex integration that fully incorporates all data. Instead, it only needs to demonstrate the potential of integration.

• You may want to consider simply configuring a static data or data mock-up of the integration to allow you to visually showcase to the stakeholder how it might be working, but avoiding the need to invest in building out the interface. This can help you avoid unnecessary complexity and possible delays at this stage.

• If real integration is important, to facilitate easy data exchange consider using the no-code vendor’s support for representational state transfer (REST), or simple object access protocol (SOAP) services. Alternatively, you could leverage pre-built connectors if they are available from the no-code vendor’s platform or from their Marketplace.

Step #4:
Dashboards & Analytics

• The no-code tools typically provide the ability to rapidly and visually compose a dashboard or report, through drag-and-drop of prebuilt components into a dashboard page. This is 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.

• You can then configure these widgets to connect them to data from other systems. There may also be a set of prebuilt components available through the no-code vendor’s marketplace that offer a rich set of visualizations and data sources.

• As with the integration design, start simple and focus on demonstrating the vision of how a dashboard may be used; it’s not necessary to have accurate data that correctly matches the process. For prototyping, you should consider stubbing out data or using simpler data that may be easily available. You’ll come back to data during later stages, but for now it’s sufficient to simply show the ability to demonstrate and articulate what type of data, and how it can be analyzed. The accuracy and completeness of the data can be addressed down the road.

Pre-built App Template Design

• In Options Analysis, if you have identified the possible fit of Pre-built App Templates (available from the no-code vendor or third-parties via their Marketplace), as a starting point you should include them wherever there is a fit.

• It may be sufficient to integrate them in their default state and without changes; this will help you illustrate the breadth of out-of-the-box functionality provided, but without having to undergo the effort of configuring them to meet your specific requirements.

• However, these modules may have limitations or restrictions that can affect the functionality of your prototype. It's important to test each component thoroughly to ensure it works as expected, and to identify any potential technical limitations early in the process.

• Keep in mind there may be third-party costs or expenses associated with Marketplace components – you may try to obtain an evaluation version from the vendor if possible, so you can validate them as part of the overall solution without having to finish off commercial negotiations.

Process Decomposition

• As your targeted process gets broader in scope (possibly spanning across cross-functional processes that span the enterprise), it will make the prototype harder to navigate and less intuitive for the users. 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 in the prototype — 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 navigate.

Custom Component Design

• In Options Analysis, you may have identified the need for select custom built components that must be included into the solution. While sometimes these may be stubbed (as in the case of custom integrations), there may be certain ones so critical to the successful prototype, that you need to include into your demonstrations.

• If this is the case, you will need to plan for sufficient time to include professional developers (as part of a Fusion Team), into the prototyping effort. Try focusing on discovery and possibly just creating the elements that are actually visible to end users.

Advanced Design Considerations

• No-code prototypes can be prone to performance issues if they're not optimized correctly. During the preparation phase, make sure to test your prototype on a range of devices and networks to identify any performance issues, such as slow load times or unresponsive features.

• If your application is going to have omni-channel experiences (such as mobile access or external portal users), plan for the right level of development expertise within the prototyping effort.

• Localization can often play a crucial role in its success, as it ensures the user interface and content are customized for the target audience, which makes it easier for them to use the product. There should be no-code tools supporting application localization. When preparing a prototype, it is essential to demonstrate the capabilities and limitations of product or service localization.

• If available, use your no-code tools to allow administrators to set up and manage access rights for different user roles, such as restricting access to certain parts of the platform, or limiting the ability to make changes to specific data sets. It is important while demoing to ensure that users have the appropriate level of access they need to do their jobs while maintaining the security and integrity of the system’s data.

• Even if you are taking advantage of prebuilt marketplace 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.

• You may need to consider data migration requirements as part of the prototyping; 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 or CSV files, which are usually supported as a file format across a wide range of systems.