infotech
Before you begin
Three things to keep in view.
- Choose a bounded process with clear users, records and a completion point.
- Test the experience with users before adding more features.
- Give the application an owner, a support route and a release process.
Look for a repeatable source of friction
Start with a process people can explain clearly: an approval that sits in an inbox, a spreadsheet copied between teams or a paper form entered twice. A focused problem is easier to understand, measure and improve.
Avoid selecting the first project simply because it is highly visible. A better candidate has an available process owner, information the team can access and a manageable set of dependencies. Write down the current effort and common errors so the first release can be evaluated against something more concrete than enthusiasm for a new tool.
Put it into practice: Select a process whose owner can participate throughout the first release.
Follow the information
Map where the data comes from and where it needs to go. Identify the owner of each record and who should be able to see or change it. This gives application design a clearer foundation.
Think about both the normal record and the difficult one. A request may arrive twice, an attachment may be missing or the responsible employee may change. Decide how those situations should be represented. Choose the application and data approach after understanding these needs, rather than forcing every process into the same type of app.
Put it into practice: Agree the authoritative source for each important record.
Design with the people who do the work
A short prototype can reveal more than a long requirements document. Put the proposed experience in front of users, listen to what slows them down and adjust before expanding the solution.
Ask users to complete a task without explaining every step for them. Watch where they hesitate, what information they search for and which labels need clarification. Include the people who review or approve the work, not only the person entering the first form. Their needs are part of the same experience.
Put it into practice: Test a complete task with someone who did not design the app.
Give the application an owner
Agree who maintains the app, handles questions and prioritizes improvements. Environment management, access and release processes should be proportionate to the importance of the application.
Ownership includes more than knowing who built the first version. Identify who can approve a change, maintain a connection and answer a support question. Keep the important decisions documented and make sure production changes are reviewed before release. The level of control should reflect how important the app has become to the business.
Put it into practice: Document who approves, releases and supports a change.
Learn before you scale
Review adoption and feedback after the first release. Use what the team learns to improve the process and decide where low-code development could help next.
A useful review looks at completed work, unresolved exceptions and the experience of the users. If adoption is low, investigate whether the process is unclear or the app creates extra steps. Improve the first workflow before copying it across departments. Reuse the patterns that work, while allowing different teams to explain their actual needs.
Put it into practice: Use observed work and feedback to decide what should scale.
Explore Microsoft guidance
Make it specific to your business.
Bring a process, a priority or a decision you are working through. Our team can help you explore the Microsoft capabilities and implementation choices that fit.
Start a conversation