Generate an app from Azure SQL DB

Aug 2019 | Microsoft

Case Study



Sole design owner, partnered with a Product Manager and a dev team.
This project was a high-visibility project that greatly contributed to the MAU growth of 170% from FY19 to FY20.

Azure? I thought you worked in Power Apps?

Correct! My primary area of focus in Power Apps was growth and integration projects. In this case, Power Apps was to have an integration experience starting in Azure SQL DB, ending in Power Apps canvas (creation) space. Due to my role, I often worked as an adaptive designer in other product spaces.


I learned other products' design systems and collaborated with their research and design teams in order to deliver a truly native experience. If each product spoke it's own language, I was learning and translating our goals to be expressed in our partnering products' tongue. One of my favorite parts of my role was establishing and maintaining relationships with other design teams across the company.



It's amazing getting the opportunity to not only work with my design team, but amazing and talented people across the company.


Integration. Growth. Azure. MAU. What's the project's goal, then?

The goal is to leverage Azure's user base to be interested in us. We make low-code apps, generated from data tables. Azure can have data tables in Azure SQL databases. Since we already offer the ability to generate an app from their data from within Power Apps, we'd thought that we need to secure a discoverable entry point from within Azure SQL DB to bring them over to the Power Apps creation space, and to gain their interest enough for them to return.


Integrating with Azure: understanding their users through research.

Azure has a pro-dev userbase. They aren't afraid of technicality. Azure users loathe excessive flourish and flair; they want to get to the point and to have each bit of information displayed be completely relevant, as Azure generally can be data dense.


Given some first rounds of knowledge transferring to-and-fro from the Azure designer and myself, I'd come up with a few ideas for layout and flow options.



Weighing options for flows we can utilize. I personally enjoy piecing out flows like this because it allows conversations for the high-level experience before sweating the details.



Using sticky notes, I played with a physical version of the landing experience, having had some insight into Azure patterns at this time.


We eventually created the first version of the project.



Key decisions: Discoverability and landing

The landing experience had two major areas for consideration -- placement in the SQL database subnavigation menu, and the look of the landing page.



When designing the content of the home page, it was essential that only minimal amount of information was presented. The design features a call-to-action and a Learn more tile in Azure's styling to ensure it felt native to the UI. Although content feels sparse on the page, the goal was, whenever technically feasible, to allow a "recent apps" section to be visible below the tiles when an app was made with an Azure SQL table.


Politically, naturally our product team wanted PowerApps to be listed much higher and more discoverable than it was currently located. Azure came with a very fair response-- they support a plethora of services, and surfacing Microsoft products specifically would serve an injustice and feel needlessly market-y, which Azure users have complained about for past experiences. Out of our hands, we negotiated a spot in the subnavigation at the bottom of the general section.


Key decisions: Trial messaging behavior



When you click the CTA, "Create an app", you can potentially be blocked by not having a license that enables you to use Power Apps. Although Azure didn't have unified guidance on licensing/trial notifications, we were able to supply trial messaging behavior guidance work I had worked on in the past for our design org. Azure's surfaces were definitely unique to interpret coming from a Fluent-based product.


Clicking on the banner will open a "blade" where you can start your trial without derailing the original process.


Key decisions: App creation



By bringing the trial experience into Azure, we were able to skip a redirect to the true PowerApps "start a trial" page to make it feel like a direct create experience from Azure to PowerApps. Utilizing existing patterns, shown is the visualization of the current loading experience, then the dialog that the user would see after their app is successfully generated.


Nice!... That means the project is done and over with, right?


A role not often associated with product designers is keeping up with and monitoring designs after they've shipped. A couple of things happened before and after it was shipped to public that prompted additional action.


Stakeholder response


A few times it was noted how barren the UI for the home page was. Although it fulfilled the need for a minimal and as-needed structure that Azure users were used to, PowerApps leadership wasn't happy about the mild representation.


Off of this, seeing PowerApps hidden in the general section also had a similar response. Azure and Power Apps leadership tussled that one as the ICs waited for an answer.


Post shipment: Qualitative research


Along the lines of PowerApps feeling hidden in the general section, users responded that it was first difficult to find the product in the subnavigation menu.


Related to the home page being sparse, most users felt that switching through the menu, it was hard to differentiate the PowerApps page from the other data-heavy pages, making it unnoticable when exploring.


In addition, although we've cut out the marketing page experience, there was a severe drop off rate after seeing the home page, then another hefty drop off rate after clicking "Create an app". Something wasn't quite grabbing their attention.


Personal reflection


Today, I would tell you that this first iteration of the Azure work was probably the hardest flop I've experienced after designing a project. It's hard to see something fail, especially with the drop rate we had and the careful consideration, but it also meant that we now had fuel to do something new and exciting to make sure the second version succeeded. Along with the new features planned for the second version, including showing PowerApps apps created from SQL tables, I was enthusiastic to address the feedback and research results from the first iteration to redeem myself and to better the experience for our customers.


Version 2



Discoverability and landing




Leadership negotiated a full "Power Platform" section under SQL in Azure to help with discoverability. A command bar with a create CTA and feedback were added. This time around, I was pointed to try a different and special type of page layout; a true "Get started - home" pattern that was, at that time, just established elsewhere in the team. With a large illustrated CTA in the middle and additional content with a learn tile below it, the page felt more filled and satisfied stakeholders and grabbed the attention of our users.


If you look below the command bar, you'll also see a new pivot. We were able to scope in the "Power Apps apps created with Azure SQL tables" into the project as well to help further integrate the two products.


Apps page



For the day 0 experience, we show the list but with no content. We show an Azure empty state with a CTA to create an app from a SQL table-- a pretty standard Microsoft pattern.



After the user creates some items, you can see your apps created from an Azure SQL table, and also have a link that takes you directly to the Power Apps apps page.


What's kind of hilarious is that this is about the time when PowerApps officially got a space in its name and changed to Power Apps.



This is just showing, depending on what you click on the page, where it'd go (all linking out to somewhere in PowerApps).


Finally.


V2 had proven a lot more successful than v1, also satisfying the needs of Azure's users and stakeholder demands. For future iterations, I'd love to include, like our "create and app" entrypoint in Sharepoint (now called Microsoft Lists), going to the list of SQL tables in Azure, having a creation experience coming from SQL table creation would be another great place to add this convenient feature.


Being patient and trusting the process, even with a few bumps in the road is a test of perserverance, dedication, and commitment to design and to being customer-centric. I'm proud of the way I've maintained a growth mindset and powered through to address the problems to create a truly successful feature and integration. This project taught me a fearlessness and head-first approach to new topics, allowing me to lean on my strong adaptive skills.