Prototype to MVP

Tips on completing the UI

• For simple DIY projects, the UI may be mostly already defined from prior Prototyping efforts. Start by reviewing the list of user journeys from the prototype.

• You should have already gotten approval from your stakeholder on the UI, so this effort may seem close to finished. However, there are probably still areas you may need to review for completeness.

• Are there any remaining forms or screens needed to complete the full process? For existing forms, what about additional business rules and validation logic needed for MVP? This area will need focus, especially if you have chosen the ‘Complete Workflow’ approach to MVP as you may have to add in edge cases or variations that were not fleshed out fully in the prototype. For the ‘E2E Process’ approach to MVP, you may also need to review the flow for completeness, if any parts were not covered during the earlier Prototype due to constraints.

• You may also have captured desired usability enhancements from earlier reviews or from the concurrent Feedback Loop (e.g. streamlining of the user flow throughout the application by combining steps or automating population of fields).

• The prototype design approved by stakeholders should be ‘challenged’ to maximize re-use of the composable elements; and to add in extended UI validation rules or UI enrichment.

• You should review if there are pre-built composable elements in the vendor’s no-code Marketplace which may assist with the development of the UI by lowering cost and development time.

• You may need to address localization or accessibility requirements, based upon the target user audience; this ensures the user interface and content are customized for the user, which makes it easier for them to use the product. Your vendor’s no-code tools offer a range of tools for application localization. You may not have addressed localization in the prototype, so this may be needed to add in during this stage.

• Finally, the UI will also likely undergo some form of brand / UI review and may require updates to ensure consistency with overall corporate standards. Plan for the time and effort for addressing their feedback into the schedule.

Tips on completing the Data Model

• During prototyping, you generally do not focus on defining the data model separately; it is generally more efficient to start with the UI/UX (which is easy for the stakeholders and users to understand), and combine the data modeling simultaneously with the UI development. As a result, the data model did not try to capture every entity or fully define all attributes; ‘Close enough’ was sufficient to define enough of the business domain so you can validate the essential business vision with your stakeholders.

• However, as you move into the current stage, data modelling is an important part of the MVP creation process. The design of the data model should be reviewed to identify missing or incomplete data entities/attributes, especially if a ‘complete workflow’ approach to MVP was selected. Try to identify edge cases and variants that may require extended data to be captured in the system.

• It is recommended to review the list of features to identify areas in the data model you may need to supplement with a more complete definition and design. The build of individual features during this stage will often drive missing data model entities, entity attributes and entity relationships needed to support the additional feature additions that are in scope for MVP.

Tips on completing the Workflow

• Based on the selected MVP approach you should ‘challenge’ the presented workflow from the Prototype against the MVP target

  • ‘E2E Process’: make sure you have defined a happy path for the whole business process end to end. Finish off or complete any steps you may have omitted or skipped in the earlier stage.

  • ‘Complete Workflow’: It’s now time to elaborate all possible ‘edge’ cases for the selected flow, which may have been skipped over in the earlier prototyping efforts.

• Review the flow of the app from start to finish. As with the data model evolution, it is recommended to review the list of features to identify areas in the workflow you may need to supplement with a more complete definition and design.

• However, keep focused on the primary objective of your app as outlined by the Business Use Case. This will help you focus on essential features and avoid unnecessary complexity in the workflow.

• Limit options - avoid overloading the app with too many features or complex options. Keep it simple by including only the essential functionality that aligns with the app's purpose.

• Map out the steps in the user journey that app users need to take and ensure the process can be completed, especially with regards to manual or legacy process implications. (This is especially true if there are manual processes that will need to be maintained to address edge cases in the business process.)

Tips on completing the User Experience

• Evaluate optimizing the UX for more complex apps to not just minimize clicks, but also by removing unnecessary actions from the user (e.g. – auto-population of some fields based on business logic, and hiding fields/streamlining the workflow for happy path scenarios.). This is essential to help drive high user adoption.

• Use consistent and intuitive elements: Stick to familiar and consistent user interface elements such as buttons, dropdowns, and checkboxes. This helps users navigate the app easily without needing extensive instructions.

• Prioritize usability and accessibility: Design the app with usability and accessibility in mind. Ensure clear labels, logical organization of elements, appropriate color contrast, and support for different devices and screen sizes.

• Are there additional multi-lingual or UX localization requirements to support different user populations? Any accessibility requirements?

• Minimize data entry: Reduce the amount of manual data entry required from users. Leverage features like pre-populated fields, default values, and data import/export functionalities to simplify the workflow.

• Automate repetitive tasks: Look for opportunities to automate repetitive tasks within the app. Utilize no-code automation logic and workflows to streamline processes and save users time and effort.

Tips on completing the Integration

• Keep in mind for composable architectures, the overall level of integration complexity tends to be higher – both due to higher numbers of integrations and diversity of APIs.

• In the Design and Prototype stage, you may have mocked up data and/or stubbed interfaces as they weren’t necessarily needed to show the end to end flow. You should now go back to the eternal systems or data sources identified and begin replacing stubbed backends from the Prototype with real integration.

• Do pre-built integration connectors exist in the marketplace? If not, do the vendors offer simple and documented REST APIs? Will custom development be required to build integrations with SDKs or proprietary APIs?

• You may have identified third-party services which will be composed into the core no-code application. (For example, sales tax calculation may be automated by a third-party module or APIs) These will most commonly be provided as open APIs, which can be easily integrated using integration REST capabilities.

• Make sure to consider all in-scope communication channels. Besides basic email, are there additional communication or messaging channels that have to be connected (e.g. telephony, SMS, WhatsApp, etc.)?

• Your IT organization may have implemented an enterprise service bus (ESB), or other middleware to orchestrate data exchange. You may be able to use pre-built integrations that should be leveraged as part of building integrations. Be sure to include IT to confirm you are in compliance with these integrations that are reused for connecting to existing IT systems.

• More complex integrations may require additional technical expertise and/or custom integration development; this may require the use of a Fusion Team model, to provide the necessary professional development skills needed. This will take longer than no-code development, so plan these into later iterations if possible as they become available.

• Plan to thoroughly catalog and validate the list of the systems/ integrations needed and confirm the level of technical complexity needed to support interfacing with their systems. You will have sized them when estimating the MVP scope in the Project Assignment stage, but you should confirm once you start the actual build as integration complexity can often be misestimated.

Tips on completing the Access Rights

• The no-code platform should 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 that users have the appropriate level of access they need to do their jobs while at the same time maintaining the security and integrity of the system’s data.

• Start by defining different roles and responsibilities within your application. Determine the level of access each role should have and the tasks they are responsible for.

  • A recommended practice is to define functional (e.g. ‘Underwriter’ for lending process) and organizational (e.g. ‘Boston branch’, ‘Dallas branch’ for lending workflow), roles for the project and only then define access restrictions. Generally, try to restrict access by only organizational and functional roles, and only grant access to specific users only if there’s no other workaround for a requirement.

  • Implementing more granular permission settings allows you to assign specific access rights to highly targeted individual user groups. This finer level of control ensures that users have the necessary permissions without granting unnecessary access.

  • Your IT organization may already have defined an overall Role-Based Access Control (RBAC) strategy. RBAC assigns permissions based on predefined roles, which simplifies access management by grouping users with similar responsibilities and access needs into predefined roles. This may streamline the necessary work for your application.

• There are some considerations around access restrictions common to many no-code apps that should be evaluated:

  • Licenses - which no-code platform licenses will be granted to different types of end users? Do all end users need a full license, or might they use a more restricted license? (e.g. read-only or limited use licenses) Depending on your no-code vendor’s licensing model, some no-code tools might offer different licenses and\or licensed add-ons\connectors which may lead to defining roles that grant appropriate access based upon user license type. (e.g. some no-code tools have mobile apps and/or customer or partner portals that require additional access restrictions).

  • Usability/Productivity - Don’t default to just allowing all roles to access all sections of the app – especially those which might be irrelevant to them (this can overwhelm users). Instead, consider mapping each user to functional roles which grant them access only to specific sections of the no-code app which are relevant to their job function. This can result in higher levels of user satisfaction and productivity.

  • Secure/Sensitive Data - identify highly secure or sensitive data within your application and limit access to it only to those who require it. Grant access on a need-to-know basis to reduce the risk of unauthorized data exposure.

• Consider what access each role or user needs to different entities within no-code app (e.g. Customer, Lead, Activity) in the following dimensions:

  • by operations (who can create, read, update, and delete records and who cannot)

  • by records (e.g. different sales reps see only leads from their respective territories)

  • by columns (e.g. only call-center supervisors can change customer’s type)

• Do you need to restrict anything in your no-code app database to control permissions outside of the UX? (E.g. limiting the option to export list of leads to spreadsheet only to specific user role?) In other words, you should consider the need to define operation permissions too, to prevent insecure access even from outside the no-code app itself.

• For more complex requirements, you may sometimes need to implement different levels of dynamic user access privileges based on the business process or business rules. For example, no-code platforms usually offer the ability for the workflow engine to restrict or grant access rights based on workflow conditions or business rules. You may also consider embedding business rules in edit pages to restrict input depending on user role, record type or status.

• Throughout your development, you should test access rights regularly to verify that assigned permissions are working as intended. Conducting tests with different user roles ensures they can only access the appropriate areas and perform authorized actions.

Tips on completing the Reports / Analytics

• The no-code platform likely provides the ability to compose a dashboard or report rapidly and visually ‘on the fly,’ through drag-and-drop of prebuilt components into a dashboard page.

• During the building of the Prototype, you may use these tools to quickly stub out data or used simple data sets to demonstrate the functionality and flow. Now you will need to start thinking about the accuracy and completeness of the data, and ensure it is working with live/realistic data.

• You should strongly consider taking advantage of prebuilt Marketplace dashboard components if they are available, which may simplify and streamline the development effort.

• You should address data migration requirements needed to support operational use. A one-time load of data files into the system may be required, especially if you are replacing a legacy system (and need to preload it with historical 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.

• You may also have identified the need to integrate with existing data warehouse/data lakes to meet broader reporting or analytics requirements. This may require working with a data architecture team to integrate with existing data architectures through their APIs.

Tips on completing the External Access

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

• No-code platforms can vary somewhat widely in their ability to support external users (e.g., customers or partners). Ideally leading no-code platforms should be able to be configured to open up various parts of your system (with restricted access rights), to external users, such as customers, partners, contractors, stakeholders, or external teams.

• Mobile experiences also can vary significantly depending on the capabilities of the no-code vendor. Some merely offer responsive experience which can render in a mobile browser. More advanced no-code platforms should provide support for native mobile experiences and offer a mobile app (from iOS or Android app stores), which allows for user access from native mobile devices.

• As a last resort, custom-built portal, web or mobile experiences can sometimes be developed (if the no-code vendor offers an SDK), but will significantly increase development time and complexity and should be used sparingly. If this is the case, you will need to plan for sufficient time to include professional developers into the MVP development effort as part of a Fusion team model.