Power App - Design Reviews

The focus and usp of LowCode is it increase in productivity by decreasing development time. Unfortunately this can be misconstrued as decreasing beyond the actual development. Development is just one piece in solution delivery, it also includes:

• Archecture Review
• Design Review
• Security Review
• Code Review
• UAT
• Life Cycle Managment
• Support

and more.

Just because its LowCode doesn't mean you can skip the above, in fact with the prevalence of citizen developers they can be even more critical.

Key to a good solution is the 4 reviews

• Archecture Review
• Security Review
• Design Review
• Code Review

Code reviews

I've spoke about code reviews before (Power Apps and Power Automate), they are a key gate keeper to ensure that the solutions will be stable and easy to maintain.

Security Reviews

Security reviews are self-explanatory with the value they add, and just because its LowCode doesn't mean they are 100% secure. I've spoken about security vulnerabilities (again for Power Apps and Power Automate) in the past. Add in data (what you are collecting, how you are storing, how access is controled, business visibility, etc) you can see that a security review is critical.

Architecture Review

Architect reviews should really be your first review in the process. They check that Power Platform is even the right solution, what impacts business controls will have (e.g. DLP, licenses, addons, usage). Additionally they will know what changes are coming, not just for the Power Platform but all the systems that are key components. A good architecture review will save you lots of pain, and potential wasted effort, just imagine if you have to can the whole project because that connector you need is blocked.

Design Reviews

The benefits of a Design review are often not as visible or understood (and why this article is focused on it).

A design review should go in tandem with the arch review, I like to think of it as the same as building a house. The architect will design what it possible, the engineer will tell you if its practical and the best way to build it.

During a design review the developer will explain to a senior dev how they plan to cover key design aspects. So what should a good design review cover:

• Device
• Site Map (access / navigation)
• Connections
• Key Components
• Stack (e.g. flows and tables)
• Solution design

What it shouldn't cover is:

• Site Map (screens / layout)
• UI
• UX
• Theme
• Standard components
• Code

Device

This is kind of obvious, but the design review should understand the device (mobile/tablet/desktop) and how the app is suitable for it.
Is it responsive, how will it scale on larger devices, what will the impact of non-targeted devices be.

Site Map

Again another easy one, how are the users going to navigate through the app, does it need a consistent menu, should that be a custom component. If required how and when will the app elevate privileges to certain users.

Connections

The power from Power Apps is all about its connections. But is the developer using the right connections, are there too many (security will want a justification), are those connections using right permissions (does your app really need to delete the user's emails?).
Often developers feel more is better when it comes to connections, the more connections the more features. But that is not only a security flag, but can make the app slow, and difficult to use.

Key Components

What is a key component I hear you ask, well any component that is non-standard (and by this I can mean a collection of standard components used to create a component e.g menu). Why would that mean its key, well if you are putting effort into making your own date picker when there is an out of the box one it must be critical.
The developer should be able to explain why the component needs addition dev time, why the standard wont do, and hows it going to be built. Key components drive complexity, and a design review is all about simplicity, optimization and sustainability.

Stack

Another kind of obvious one, what else is going to be in the solution export and why. Does it need flows, if so why not use in app connections. Does it need Dataverse table, again why, are you prepared for premium license costs. Where are you going to use environment variables, etc. All key decisions that should be made before development and all should have justification.

Solution Design

And this is the big one, this is the practical logical approach. Similar to UI and UX this could easily be subjective, with there being no wrong answer. The key to the solution design is the developer knowing the options and explaining why they chose that solution. As a developer it is far too easy just to think there is only one solution, and once you have found it move on. When actually there is always multiple, and you should think of as many as possible, then chose the right solution.

An example would be a date selector, it could be

• Simple input which uses regex match to enforce format.
• Out of the box date picker
• Template date picker (gallery based)
• Completely custom

They all have strengths and weaknesses in specific situations, the developer needs to know them all and demonstrate that knowledge and decision making.

As you can see there is so much benefit in a good design review (and the other 3 key reviews), just getting your lead/experienced dev's to share their expertise alone is a long-term benefit beyond measurement.