Review Workshop: Make Professional Designs with Power Apps for Figma by Lukas Pavelka at the M365 Con

Lukas Pavelka’s workshop, “Make Professional Designs with Power Apps for Figma,” was presented at M365 Con on January 12, 2026, as a long-form session focused on one main idea: Power Apps development should begin with stronger design structure, not end with visual cleanup. The event page described the workshop as an in-depth introduction to Pavelka’s Power Apps Figma plugin, with emphasis on YAML import/export, responsive design, component libraries, documentation, and upcoming AI-driven capabilities.

That framing is important because it addresses a real weakness in many low-code projects. Teams often move quickly to functionality, forms, and data connections, then discover late in the process that the app lacks visual consistency, stakeholder alignment, or a reusable design system. The workshop positioned Figma as the place where that work should happen earlier, with Power Apps for Figma acting as the translator between structured design and app-ready output.

The session was not marketed as a designer-only talk. It was aimed at developers, consultants, IT professionals, and Power Platform enthusiasts who want to create better-looking apps without introducing a separate heavyweight front-end stack. That matters because the plugin’s promise is not “design for design’s sake.” It is speed, consistency, and fewer costly revisions once customers or internal stakeholders finally see the interface.

From that perspective, the workshop was really about maturity in Power Apps delivery. It argued that a polished app is not just about aesthetics. It is also about reducing friction in projects: fewer layout discussions after build starts, fewer ad hoc UI decisions screen by screen, and a better handoff from concept to implementation. That “from idea to handover” language also appears on the official product site, which reinforces that the plugin is meant to support a full delivery workflow rather than a one-off conversion trick.

Who Lukas Pavelka is and why this plugin exists

Pavelka’s speaker profile for M365 Con gives useful context for the workshop. It presents him as a consultant and builder working across Power Platform, SharePoint, Figma, agile delivery, and Atlassian tools, and notes that he created the Power Apps for Figma plugin to help users design more distinctive canvas apps. That background helps explain why the workshop blended product vision with practical implementation detail.

In public community coverage, Pavelka is consistently described as someone with a long IT career who moved from traditional software development into automation, low-code, and design-centric Power Platform work. A LinkedIn community summary of his workshop appearance highlights his transition from Java into Power Platform and his belief that Power Apps needed stronger design workflows if teams wanted to produce more professional applications.

That origin story matters because it explains the plugin’s tone. Power Apps for Figma was not presented as a purely creative tool for UI specialists. It was presented as something built by a practitioner who had already felt the pain of working in Power Apps without a strong design layer. The problem he is trying to solve is familiar: teams can build the logic, but the interface still ends up looking generic, inconsistent, or difficult to review before development effort is already sunk.

There is also a longer public trail behind the product. Pavelka has written about Figma-to-Power-Apps workflows since at least 2023, when he described ways to build mobile app designs in Figma and move them into Power Apps with near one-to-one intent. That history makes the workshop feel less like a trend response and more like the latest step in an evolving attempt to connect design practice with low-code execution.

What Power Apps for Figma actually is

The official site describes the plugin as a way to accelerate Power Apps development by designing in Figma, managing dependencies, and moving toward handover with more structure. That wording is revealing. It shows that the product is not trying to be only a converter. It is trying to become a lightweight design-to-development system for canvas app teams.

The pricing page helps make that structure concrete. The free tier includes Theme Designer, Import YAML file, Export to YAML, Layout Builder, and Help. The Pro tier, listed at €25/month, adds capabilities such as Code Viewer, YAML Snippet, Swap component, Dependency Model, Extended features, Duplicate Screen, Style Manager, and PDF export. Those features line up closely with what Pavelka highlighted during the workshop: a starter layer for basic workflow adoption, and a fuller toolkit for consultants or teams doing client-facing or production-grade work.

The documentation shows that the plugin depends on convention and structure rather than magic. For example, the export guidance explains how specific object types and prefixes influence what gets generated for Power Apps, including behaviors for ellipses, frames, containers, and HTML-related output. That confirms the workshop’s core message: Figma can become a practical source for Power Apps artifacts, but only when the design is structured in ways the plugin understands.

That approach is arguably the plugin’s real innovation. It does not attempt to make Power Apps disappear inside Figma. Instead, it gives Figma a kind of “Power Apps grammar.” Controls, components, screen regions, and reusable styles become legible to the plugin, which can then produce YAML and snippets that shorten the distance between mockup and implementation. This makes the product more disciplined than a screenshot-based import idea and more scalable than pure manual rebuilding.

The workshop’s strongest practical message: design before build

One of the most persuasive ideas in the workshop was Pavelka’s argument that redesigning old apps after the fact is usually a poor use of time. The event summary and related community writeups repeatedly frame the plugin as a way to design professional, scalable Power Apps in Figma first, then export them into Power Apps. The implication is that starting with fresh design intent is often better than trying to reverse-engineer a legacy screen-by-screen experience into something modern later.

That matters especially in consultant and agency contexts. If a customer reacts negatively to the visual style after development is already underway, the cost of change goes up quickly. But if the UI is reviewed in Figma, the same stakeholder can comment on color, spacing, hierarchy, layout, and branding before the app logic is deeply wired in. The workshop leaned heavily into that reality, and it is also consistent with the broader “design to handover” positioning on the product site.

This is where Figma’s own collaboration model becomes relevant. Figma’s Professional plan supports unlimited files, pages, projects, version history, and shared design collaboration features, which makes it easier for teams to create and maintain design assets as a shared source of truth. Pavelka’s argument depends partly on that collaborative strength: design is more useful when it can be reviewed, iterated, and reused by more than one person.

The workshop therefore made a wider case than “this plugin saves time.” It argued that design-first Power Apps work reduces project risk. It can make apps easier to standardize, easier to review, and easier to present to stakeholders who are not comfortable judging an interface only after it has already been implemented inside Power Apps. In practice, that may be the plugin’s most valuable contribution.

The role of YAML, structure, and repeatability

A recurring theme in the workshop was YAML. The session description explicitly says the plugin simplifies importing and exporting YAML code, and the free plan already includes YAML import/export capability. That alone signals that Pavelka is thinking about Power Apps design not merely as pixels but as structured, portable output.

Why does that matter? Because once a design can be represented in a structured form, it becomes easier to reuse, compare, document, and hand off. YAML is not just a transport mechanism in this story. It is part of turning low-code design work into something more systematized. Public community commentary around DesignKit and related workflows even connects this idea to source control, governance, CI/CD thinking, and design maturity, which shows how the plugin can fit into broader enterprise practices.

The documentation supports that interpretation. It does not present export as a loose visual snapshot. It talks about object handling, prefixes, and behavior in ways that imply a more formal mapping between Figma structure and Power Apps output. That is exactly the sort of repeatability larger teams need if they want to do more than build isolated apps one at a time.

This is also why the plugin’s feature list matters. Code viewer, YAML snippets, dependency model, duplicate screen, and style manager are not glamorous marketing extras. Together, they point toward a way of working where design is inspectable, copyable, explainable, and easier to reproduce. For solo makers, that may be convenient. For teams, it moves closer to an actual delivery system.

Responsive design and component libraries as the real differentiators

The M365 Con description specifically highlighted responsive layouts and component libraries, and that is one reason the workshop felt more substantial than a simple export demo. Responsive behavior is one of the harder parts of turning a mockup into a usable app, especially when business apps have to run across tablet and desktop form factors. By making responsiveness part of the conversation, the workshop acknowledged one of the places where static design tools and real app behavior often diverge.

Component libraries matter for a different reason: scale. A one-screen app can be styled manually. A multi-screen business app used across departments usually cannot. Shared buttons, inputs, containers, and visual patterns are what make a product feel coherent. Pavelka’s workshop made that point by emphasizing reusable elements, variants, and design systems inside Figma before export into Power Apps. That aligns with the product’s broader message around consistency and repeatable delivery.

There is also a practical Figma angle here. Shared libraries and larger-scale team design workflows are supported more fully in Figma’s paid plans, which makes them viable as a foundation for organizational standards rather than one-off files. That matters because Power Apps for Figma becomes more valuable when teams treat design assets as reusable infrastructure, not just project decoration.

Taken together, responsive layouts and component libraries are probably the strongest proof that the plugin is aimed at serious delivery work. They suggest a world where Power Apps development can be approached with the same design-system thinking that product teams already apply in web and app development. That is a meaningful shift in mindset for the Power Platform space.

Documentation, dependency models, and handover

Another detail that deserves more attention is documentation. The official Pro feature list includes PDF export and Dependency Model, and the site repeatedly talks about moving from idea to handover. Those are not throwaway extras. They address a constant weakness in fast-moving low-code projects: knowledge often stays in the head of the builder, and documentation gets skipped until it is painful.

A dependency model is especially useful because it makes navigation and relationships visible. Instead of treating screens as isolated layouts, it helps teams understand how an app fits together. That has value for developers, testers, project managers, and stakeholders who need to understand flow without reading formulas line by line. The workshop’s inclusion of this feature suggests Pavelka sees app architecture and UI structure as connected, not separate concerns.

PDF export and documentation also matter in consulting contexts, where deliverables often need to be shared outside the authoring tool. A screen design, component system, or app flow is more useful when it can be packaged and handed off cleanly. That is part of what makes the plugin feel business-oriented rather than hobby-oriented. It acknowledges that app building usually ends in review, documentation, support, or transition to another team.

This handover emphasis is one of the strongest reasons the workshop stood out. Lots of tools promise faster creation. Fewer tools pay equal attention to how design choices are explained, shared, and maintained after creation. Power Apps for Figma appears to be trying to solve that entire chain, even if it is still evolving.

The AI roadmap

The workshop description also previewed AI-driven features, and Pavelka has spoken publicly about this next phase as part of the product’s evolution. The idea is not just to add a chatbot for fashion. It is to reduce the need for users to remember every prefix, structural rule, or property mapping by hand. In that sense, AI becomes an interface layer on top of a system that already has formal design logic underneath.

That is an important distinction. AI features are only compelling when they sit on top of a strong model of the problem. Because Power Apps for Figma already revolves around structured controls, export logic, YAML, and component rules, a prompt-driven layer makes sense. It can potentially shorten the path from intent to output instead of simply generating vague mockups.

The roadmap also signals something broader about where low-code tooling is heading. Users increasingly expect conversational help, automation, and adaptive generation, but they still need guardrails. A system like this can be valuable because it combines AI convenience with a constrained output target: Power Apps artifacts that are meant to become usable app components rather than just pretty images.

Even so, the more important story is not the AI itself. It is that Pavelka seems to be using AI to simplify a design system, not to replace one. That is a healthier direction. It suggests the future version of the plugin may lower the barrier to entry while preserving the structured workflow that gives the product its real value.

The business case: who this is really for

The workshop made sense because the plugin clearly has a target audience. The free tier lowers the barrier to entry, but the Pro tier and feature set suggest the real sweet spot is consultants, agencies, internal product teams, and serious makers who repeatedly build customer-facing or employee-facing canvas apps. Those are the users most likely to benefit from component reuse, documentation, dependency views, snippets, and style management.

For that audience, the price is not really the core question. The real question is whether the plugin saves more time than it costs. If it reduces redesign work, shortens feedback loops, makes handover cleaner, and allows teams to reuse design systems across multiple apps, then the economics are easy to justify. That is especially true in environments where app polish affects adoption and stakeholder confidence.

For casual makers building a quick internal app, the value proposition may be less urgent. They may not need formal component libraries or PDF handover packages. But the workshop was not really aimed at that audience. It was aimed at people trying to make Power Apps delivery more repeatable, more professional, and more presentable.

That targeting is part of why the session worked. It did not pretend every Power Apps user has the same needs. Instead, it made a focused case that design discipline becomes more valuable as apps become more visible, more numerous, and more connected to business expectations.

Final takeaway

The strongest takeaway from Lukas Pavelka’s workshop is that it reframed Power Apps design as infrastructure rather than decoration. Through Figma, YAML workflows, responsive layouts, reusable components, dependency mapping, and documentation, the plugin aims to give Power Apps teams a more deliberate path from idea to implementation. The official workshop description, product site, pricing details, and documentation all support that reading.

What Pavelka is really pushing is a change in mindset. Instead of accepting that business apps should look acceptable after the fact, he is arguing that design systems, structured exports, and stakeholder-visible prototypes should be part of the build process from the start. That is a bigger idea than a plugin feature set, and it is what made the workshop more interesting than a standard tool showcase.

Whether every Power Apps team adopts Power Apps for Figma is almost beside the point. The workshop made a convincing case that low-code development is growing up, and that the teams who bring design, structure, and documentation into the process earlier will move faster and deliver better experiences. In that sense, Pavelka’s plugin is not just solving a niche workflow. It is pointing toward what a more mature Power Apps delivery model could look like.