PowerApps from a design perspective: expectations vs. reality

Product Designer Karen Haidinger reflects on the experience of building a rostering product using Microsoft’s low-code platform.

Royal Greenwich’s street services team are responsible for waste collection and street cleaning across the borough. We’ve written previously about how we’re building a rostering tool using Microsoft PowerApps, to improve the back-office efficiency of the service. 

We chose PowerApps because it had the most flexibility of a set of low-code platforms we explored and fitted well with colleagues’ existing PowerPlatform skillset. This post shares a designer’s experience of working with PowerApps to produce a first version of the product in private beta. 


What we worried about before starting work with PowerApps 

Our main concern was that PowerApps’ constraints might mean compromising on usability. Losing the simplicity of the interactions and UI we tested in our alpha phase would mean a huge part of the value of having something bespoke for users would vanish. We had to make sure we understood some of the main UI and UX constraints (e.g. no drag and drop interaction) so we could assess how big this compromise would be and what it would mean for our project. 

We also wondered if PowerApps would be complex for designers to work with. This is a tricky one as designers have unique understanding of coding or coding skills. Personally, I found having some previous knowledge of JavaScript and ActionScript made it easier to learn to work with PowerApps.  

Finally, we were unsure how designers and developers could best collaborate when working with PowerApps. Low code tools open up more opportunities for designers to play a role in development, but we were unclear about the best use of our designer and developer’s time and skills, as this was a new way of working for us.  


What proved easy 

We found some things straightforward: 

  • Collaboration between designers and developers: We designed and documented all styles and new interactions in Figma, which acted as our single source of truth for designs. My efforts as a designer were focused on implementing the 'polished' UI straight into PowerApps and working closely with our developer, Nathan, to implement the more complex parts of the new interactions. This was a great way to speed up the process. I personally found that everything that involved dynamic data being connected or filtered could be better (and more quickly) handled by developers. Of course, this can vary between different designers, depending on how comfortable they are with coding. 

  • Implementing bespoke UI elements and making sure they reflected the Figma designs we tested with our users was easier than we initially expected. We were able to achieve very similar results and compromises on design and usability were minimal. 

  • Creating a basic shared component library and updating components from linked apps was straightforward. We are still assessing how additional much work would be needed to share these with other product teams, such as by linking these libraries to Royal Greenwich's Design System. 

  • Editing and updating all UI elements in a ‘gallery’ was quite quick as they are automatically duplicate styles. A ‘gallery’ is one of the core front-end building blocks in PowerApps. It lets you display data from a back-end table to users of the app. It can display multiple records; each record appears as a new ‘block’ on the screen, and takes on the style of the first ‘block’.

 Screenshot of a rostering tool built in Microsoft PowerApps, which shows a repeating gallery element that contains the names of waster collection rounds and the staff that are assigned to each round.

As an example, we used PowerApps galleries in our app to display all the rounds in our allocation screen.  The allocation gallery is formed by the same item repeated for each record. In this example, the record is the allocation round card with type of round (colour bar), title of the round, vehicle, name, and role for each staff member.


What we found difficult 

We encountered a range of challenges while working with the platform: 

  • Developers and designers could not work on the app simultaneously. PowerApps doesn’t support this at the moment. We tried an experimental GitHub plugin that allows multiple people to work on the app simultaneously without the risk of losing changes and versions, but the plugin proved to be unreliable. We had to work around this, with one person exiting the PowerApps environment so that others could make changes. 

  • Keeping consistency was hard work! Styles could not be easily copied from one component to the other, so we had to individually apply and update styles on elements like forms dropdowns and text fields. We partially solved this by using global variables - which store properties that can be referenced from anywhere in the app and pass on styles to the components. 

  • It is hard to customise elements. You cannot update multiple styles at once (colour, font size, border) - instead, having to set them individually with lots of clicks (one for each for different attribute). This is counter-intuitive for designers used to tools like Figma or Sketch, where you can easily copy and paste styles between elements. We are starting to explore to what extent a component library can help solve the two points above, so UI elements are reusable and consistent within a project and across different projects.  

  • The way errors are handled in the app could be improved. Some elements disappear from the screen when there is a problem with data connection, for example, so it can be confusing as the app appears to be broken at times. 

  • Microsoft’s Figma import tool initially looked like a promising way to turn Figma prototypes into working app components, but ended up having had limited value to us. Many of the elements imported from Figma into PowerApps appeared broken. We achieved better results by recreating the UI elements in PowerApps manually. 


Limitations of designing with low-code tools 

The PowerApps platform has some constraints, which we had to adapt to as the product progressed: 

  • Drag and drop interactions are not possible. This limitation meant rethinking and designing the initial interaction we tested for our app during alpha. Fortunately, this also meant avoiding potential accessibility issues with drag and drop interactions, as they can be challenging for users with impaired mobility or people who use alternative input devices like voice control software. 

  • The component library functionality is basic. There is a lot of space for improvement so that components can be more easily used and customised between apps or projects. This is especially true of components in galleries and forms, which are the basis of PowerApps. 

  • Some compromise will be required. Some elements, such as date pickers and dropdowns, have quite limited customisation options. In other areas, simple design choices, like creating a rounded rectangle, can currently only be achieved with workarounds. 

  • Some training is required. I don't think PowerApps is straightforward enough for any designer to just start using, especially with regards to connecting data sources. We benefitted immensely from having an in-house PowerApps expert who ran working sessions and workshops to get us started - and keep us on track throughout the project. Fortunately, there is a lot of great documentation on PowerApps and video online tutorials



On the whole, we have been impressed with PowerApps’ capabilities. One significant advantage is being able to see an app taking shape so quickly and to be able to test 'the real thing' with users, to get positive feedback, build engagement and identify improvements.  

We are still assessing and testing how robust our app is, as it performs slowly at times, when handling more complex data structures. We are intending to integrate our app with the council’s HR system, iTrent. As part of that, we will move the app’s data repository from SharePoint to a SQL database, which we believe will solve these performance issues. This is a key factor for us, as this will have direct impact on its usability, and consequentially trust and adoption by users. 

Overall, the pros outweigh the cons and we see PowerApps as a great resource to quickly build and test something tangible and real (with real data!) with users. It works particularly well to build simpler apps that are based on forms or repeated data patterns that can be easily displayed as galleries in PowerApps. 

If you’re new to building with PowerApps, we found Microsoft’s documentation and glossary helpful. We were also able to resolve issues and blockers by learning from experts on YouTube, such as Shane Young and Reza Dorrani

Share and Enjoy:These icons link to social bookmarking sites where readers can share and discover new web pages.