Prototyping in Axure vs. Power Apps

As I described in part one of this blog series, prototyping was an integral step of our user-centered design/discovery process. When we first started on the project, the UX Architect and I used Axure, a well-known prototyping tool familiar to us. However, as the project progressed, we moved into prototyping in Power Apps directly.

Several reasons led to such change:

  • Our client’s security policy required that we keep the prototypes in their tenant.
  • Axure is a third-party tool.
  • When developers built the new solution in Power Apps, they could not reuse any Axure elements, such as the interaction that we built with Axure’s dynamic panels. While they could inspect the Axure prototype about spacing, color, or padding, they had to re-create all design elements in Power Apps.
  • Some Axure controls or design elements were difficult to replicate in Power Apps due to formatting and accessibility limitations, which created inconsistencies between the prototype that stakeholders saw and the final solution.
  • Using Axure also incurred an additional licensing cost.

The table below lists some pros and cons between Axure and Power Apps.

Axure vs. Power Platform

As shown in the table above, prototyping in Power Apps presented significant advantages over Axure. Not only were we able to keep all content within the same tenant, but also our Developers could reuse some prototype code and design elements when they started development, such as directly copying form controls and functions from the prototype.

In addition, as the time of writing this blog, the project team has been developing a Power Apps Component Library, with the consistent design of form elements, which will further streamline code and element reuse in the future. In addition, the project team has been mentoring client employees from several business units in their InfoPath form from the modernization process. The Component Library will serve as a great tool to help these people, who may not have any UX or user interface design knowledge, follow UX design best practices.

Prototyping in Power Apps did pose some challenges because it always takes time to learn something new. However, I was very motivated and started to prototype in Power Apps as soon as I had the opportunity. I saw how our Developers quickly added, removed, or modified form elements when we worked together on some app requirements. I also had a glimpse of the Power Platform capabilities when I attended a workshop two years ago and knew it was citizen developer-friendly. (See my previous blog: Microsoft Business Applications: A UX Researcher’s Perspective).

My prototyping experience in Power Apps proved to be very positive, and I felt empowered by the Power Platform. Here’s why:

  • I received a lot of help from my Developer colleagues, especially Stephanie Zaloga (LinkedIn). She created a template for me based on a canvas app she developed, which included many frequently used form elements and controls, pre-formatted with the appropriate fill, border color, hover, and font variations. I could easily reuse them in my prototype without having to go through the tedious formatting process. (The Component Library in development will further help.)
  • I focused on improving form instructions, labels, and controls, based on form design and plain language writing best practices, which I was familiar and comfortable with.
  • I was able to prototype cascading data fields and simple interactions, usually crucial to meet client’s business needs, with just a few essential functions in Power Apps, such as Switch or If. During development, our Developers could copy and paste these correctly formatted controls, such as dropdown fields, text inputs, and HTML text/instructions, directly to the final solution, which sped up their overall app development time.
  • I did not create any back-end data for my prototype, which would require more Developer skills.
  • I found Microsoft’s online resources and support from the Power Apps community extremely helpful. It was comforting to start a search and see results highlighting a particular problem solved.

Extensive and Helpful Microsoft Resources

Form Design and Content Development Best Practices

When I prototyped the new solution based on the existing InfoPath forms, I always considered form design best practices and tried to improve form usability whenever possible. When we met with stakeholders to get their approval of the prototype and requirements, we would point out such improvements in the prototype, making sure that they were aware and comfortable with our recommendations.

Some of the form design best practices that we implemented included:

  • Follow digital content development best practices for instructions and labels
    • Rewrite content to be more usable and accessible, including removing all those Click Here or Here standalone links
    • Shorten or eliminate form instructions whenever possible
    • Use numbered lists for sequential steps and bulleted lists to support user scan, instead of long paragraphs
    • Spell out acronyms when they are used the very first time
    • Consistently use words and phrases and eliminate inconsistencies, such as up-grade vs. upgrade
  • Create new form sections with clear section labels, if needed, and logically group similar questions together
  • Ensure a clear visual distinction between primary and secondary action buttons, such as Save and Go Back, and align primary actions with input fields/user flow
  • Never use colors alone to convey information to meet accessibility guidelines

Dropdown lists were common form components. For app consistency, at the beginning of the project, our team agreed that:

  • Higher numbers or more favorable options should be placed at the top of all options instead of the bottom. This is to support natural conceptual mapping. For example: With dropdown options showing risk, we would display the options as:
    • 5 – High Risk (on the top)
    • 4 – Medium to High Risk
    • 3 – Medium Risk
    • 2 – Low Risk
    • 1 – No Risk (at the bottom)
  • Options should be displayed in a certain order: alphabetically or by priority/frequency.
  • Radio buttons should be used for two to three options instead of a dropdown.
    • Radio buttons should always have a default value when used.
    • The default value will be displayed first.

Project Updates and More Information

Our project that lasted from August 2020 to this February was a success, which led to two additional projects starting within the same insurance company. Since February, I have been working in a project team that requires Microsoft Dataverse and model-driven apps to modernize InfoPath forms related to an important product. In this project, I function as a BA, UX Researcher, and Organizational Change Manager. This has presented exciting new learning opportunities, as well as challenges. I may write another blog post depicting my experience afterward.

To learn more:

Project Background

From August 2020 to this February, I worked as a Business Analyst (BA) on a project team to help a major insurance company modernize thousands of InfoPath forms into the Microsoft Power Platform. Our client needed to retain critical business functionality and workflows of these forms before Microsoft ends their extended InfoPath support in July 2026. Our efforts included modernizing the InfoPath forms by using Power Apps canvas apps, Power Automate, and some Power BI.

It was a great experience working on this project. First of all, I got to work with a project team with members specializing in different technical areas who were motivated to mentor and learn from each other. I learned about the Power Platform, Power Platform accessibility, Modern SharePoint lists, and some QA testing basics.

At the same time, as a BA with an extensive background in user experience (UX) research, I contributed to the project’s success by sharing and implementing UX best practices and helping improve the overall usability of our applications. Throughout the project, I had opportunities to:

  • Lead project discovery that followed a user-centered design process involved multiple activities and steps within our internal AIS team and with our client stakeholders.
  • Prototype the new solution first in Axure and later on directly in the Power Platform – the low-code/no-code, connected, and secure platform, which empowers citizen developers like me to solve business problems.
  • Work with our team to improve overall form design for better usability, including improving form labels, instructions, and controls.

I describe my overall project experience in a two-part blog post:

  • Part 1 (this post) focuses on how we followed a user-centered design process to conduct InfoPath form discovery.
  • Part 2 compares prototyping in Axure and Power Apps and illustrates how we improved form design from InfoPath to Power Apps.

User-Centered Design/Discovery Process

Our project included ten members: 1 Project Manager, 1 Power Platform Solution Architect, 3 Power Platform Developers, 2 Accessibility Specialists, 1 UX Architect, 1 QA Test Engineer, and me as the BA. The Power Platform Solution Architect, UX Architect, and I formed the discovery team, with constant support and participation from our Project Manager.

Our project followed an Agile process with two-week sprints, and our discovery team of three worked on the target InfoPath forms a sprint ahead of the rest of the team members. When our Developers and Test Engineer were ready to start developing and testing the new app, we had already completed the needed discovery. We received the client’s approval on the app requirements. Figure 1 below depicts our simplified discovery process.

Design Discovery for Agile Process

Detailed Discovery Steps

In reality, multiple activities and meetings could occur in each step, and below are more details of how we conducted discovery.

  1. While familiarizing ourselves with the target InfoPath form(s), our discovery team focused on forms themselves and reviewed relevant
    • SharePoint site(s), different SharePoint list views, and workflows.
    • It was helpful for us to understand the form context, which was necessary for our conversations with stakeholders.
    • I created a Stakeholder Interview Guide Template at the beginning of the Project and constantly updated the Template with tailored questions.
    • We might hold an internal meeting about the initial findings before we met with client stakeholders.
  2. Regarding our initial meeting with key stakeholders/form owners:
    • To ensure their attendance, I always tried to schedule meetings at least one week in advance.
    • During the meeting, I followed the Interview Guide, focusing on their existing use of the InfoPath forms and workflows, what worked well, what pain points they experienced, and what wish lists they wanted.
    • I would schedule follow-up meetings if needed, especially if multiple InfoPath forms would be modernized together.
  3. Armed with a good understanding of the target forms, we would meet internally to debrief and propose a new solution.
    • Sometimes a modern SharePoint list would suffice, but most frequently, a canvas app would be required to replace existing forms, especially when multiple or similar InfoPath forms needed to be modernized.
    • Our Solution Architect would also check data integration or connection with other systems outside the form(s), ensuring that such integration would continue to work in the new solution.
    • Power Automate would be used for associated workflows, such as email notifications, permission/role-based access control, and user profile fields.
  4. After our discovery team agreed that a canvas app should be used, I would create an Excel spreadsheet to document app requirements, while our UX Architect would start to create a prototype.
    • The prototype would illustrate our design ideas, provide a visual representation, and include some interactions of the new solution.
    • I always created at least three worksheets in the Excel spreadsheet:
      • Background: Summary of what we learned in client meetings, such as the purpose of the existing form(s), description of form users, and form owners’ contact info.
      • URLs: Links to the existing form(s) and SharePoint site(s).
      • Acceptance Criteria: Detailed requirements of the canvas app.
    • During this step, the UX Architect and I would meet multiple times to ensure that the documented requirements and prototype would match.
    • When needed, we would consult our Solution Architect to ensure that the requirements and prototype took full advantage of the Power Platform capabilities.
    • I acted as both a BA and UX Architect for several forms, documenting requirements and creating prototypes, which simplified this step.
  5. When we met with stakeholders again, we showed them both the prototype and requirements and emphasized that no actual coding had occurred. Doing so would encourage them to provide any additional suggestions if needed so that the new solution would meet their business needs.
    • The Excel file and prototype complemented each other well, especially in areas where the prototype did not cover. For example, instead of making workflows work in the prototype, which would require a lot of coding, I would specify that in a requirement explaining when and who would be notified when a form was submitted.
    • Sometimes we needed to go back and adjust our prototype and requirements before we met with the stakeholders again to get their final approval to our proposed solution.
  6. As the last discovery step, we would meet with our Developers and QA Test Engineer, walking through the prototype and detailed requirements accessible from a SharePoint document library.
    • The meeting acted as a knowledge transfer session from the Discovery team to all other members.
    • Based on the information, Developers would create tasks in the Azure DevOps (ADO) to restructure data, estimate needed screens or forms, report data in Excel or Power Bi, and create flows.
    • Test Engineer would create the necessary test plan, cases, and steps in ADO.

Ideally, our Discovery team could answer all questions from our Developers and Test Engineer at this step. However, from time to time, they would ask us a few questions or details that we could not answer, which required us to go back to client stakeholders for further clarification. When that happened, I would update the Stakeholder Interview Template to cover such questions in future discovery.

Examples of such questions included:

  • Will form submitters be allowed to edit their submissions?
  • Should they be allowed to save a draft before submission, or should they fill out the entire form in one sitting?
  • Should there be an app Administrator screen so that stakeholders could make future updates easily within the app, or will they be comfortable enough to make updates directly from the back-end, such as a SharePoint list?

In Summary

As described above, having a designated Discovery team in a project with members specializing in UX and technology solutions worked well and significantly contributed to our project success. In general:

  • Following a user-centered design/discovery process helped the project teamwork efficiently, avoided surprises in later development and testing, and saved overall project time.
  • It was important for project discovery to start at least a couple of weeks ahead of the rest of the team.
  • Involving client stakeholders early and throughout discovery was crucial in ensuring that the new solution would meet the client’s business needs.
  • Discovery artifacts, such as the prototype and requirements, should be available at a central location so that all team members could easily refer to them and clearly understand how the new solution should function.

In Part 2 of this blog series, I will compare my experience prototyping in Axure and the Power Platform. I will also share a few form design and content development best practices that we implemented when we modernized InfoPath forms to Power Apps.

In this blog post, I’d like to share:

  • What I have learned about OCM and its importance
  • The ADKAR® Model for successful OCM
  • How UX and OCM are closely related and connected
  • A case study of implementing UX and OCM together

I enjoy being a User Experience (UX) Researcher. I like working with diverse user groups, learning about their needs, understanding their frustrations and challenges, coming up with solutions to address their pain points, and usually making corresponding design recommendations to improve various products that they use. It is rewarding to know that I can help improve people’s lives.

UX is an umbrella of multiple career pathways and skillsets, as Cory Lebson and other book collaborations described in The UX Careers Handbook. Therefore, UX is also a fascinating field, providing me with continuous learning and professional growth opportunities. Over the years of working on numerous projects, I’ve focused on user research and evaluation, information architecture, interaction design, content strategy, content writing/information design, technical communication, human factors, and accessibility.

Getting into OCM

AIS values continued learning, sharing, and technical excellence and the leadership encourages employees to be life-long students. Since I joined AIS in 2018, I have had many opportunities to grow professionally, which has helped me take more job roles and responsibilities that are beyond the traditional UX pathways and skillsets.

One of the new disciplines that I have learned, through internal and external projects, training, and learning, is OCM. As I learn more about it, I see more relevance and connections between UX and OCM. I increasingly believe becoming proficient with OCM not only benefits me as a UX Researcher to gain a new skill set, but also helps the users I work with, contributes to overall project success, and better serves my clients.

Importance of OCM

The Greek philosopher Heraclitus said, “change is the only constant in life.” Constant change is true not only in people’s personal lives but also in organizations where digital transformation (DX) continually occurs. International Data Corporation (IDC) stated that “spending on the DX of business practices, products, and organizations will continue at a solid pace despite the challenges presented by the COVID-19 pandemic” (Research Press Release, May 20, 2020).

According to Prosci, the leading change management research and development company, every organizational change includes the technical and people sides. Changes can fail, even though they meet technical requirements and milestones. Organizations must implement change management, which Prosci defines as “the process, tools, and techniques to manage the people side of change to achieve a required business outcome.” It’s worth mentioning that change management is not only crucial in a business environment but also in people’s personal lives.

According to Prosci research, compared with initiatives with poor change management, efforts with excellent change management are:

  • Six times more likely to achieve project objectives
  • Five times more likely to stay on or ahead of schedule
  • Twice more likely to stay on or under budget

(Learn more: An Introduction to Change Management – download required)

Prosci ADKAR Model

Prosci specified that successful OCM is rooted in the change of individuals in the organization, one person at a time. To guide people to embrace, adopt, and sustain any change, Prosci founder Jeff Hiatt created the simple, but robust and effective ADKAR Model. ADKAR represents five building blocks for successful OCM:

  • A: Awareness of the need for change – “I get what is happening and why.”
  • D: Desire to support and participate in the change – “I choose to participate.”
  • K: Knowledge of how to change – “I know what to do and how to do this.”
  • A: Ability to implement required skills and behaviors – “I can do this.”
  • R: Reinforcement to sustain the change – “I will continue to do this.”

All these five elements must be in place before people change, and a change succeeds.

Relevance and Connection between UX and OCM

The ADKAR model focuses on the people side of change. UX centers around people, process, and technology. Both UX and OCM involve closely working with people. Through self-learning but primarily through collaborating on internal and external projects with my colleague Tacy Holliday, who specializes in OCM, I have learned about OCM basics and realized the relevance and connection between the UX and OCM disciplines.

I have found my UX background and skills help me understand OCM and its importance, which has led me to take advantage of my UX knowledge to OCM implementation. Equipped with both UX and OCM knowledge, UX practitioners can not only help improve the UX of a product but also help individuals adopt the product that they have helped evaluate and progress, which benefits these users and their organizations.

Some advantageous UX skills that I have found useful in OCM implementation include:

  • Using various user research methodologies, such as surveys, interviews, and focus groups will collect people’s feedback and understand their needs, pain points, concerns, and challenges
  • Practicing active listening and empathy with various user groups to improve people’s overall experiences while minimizing bias
  • Clear communication and frequent engagement with people, including using typical UX artifacts, such as wireframes, diagrams, or other graphics
  • Problem-solving skills to timely address people’s concerns, provide support and make recommendations

Case Study: Implementing UX and OCM Together

UX and OCM are naturally connected, and some activities in both areas can be carried out without additional efforts. This was proven successful when we helped a client, ACA Compliance Group, adopt Microsoft Teams (Teams) across their offices in various states of the US, the UK, and China. Our project team included a Project Manager, Cloud Engineer, Change Manager, UX researcher, and Business Analyst. During our 16-week engagement, we helped ACA achieve a 90% adoption rate of Teams, and ACA was well-positioned to achieve a 100% adoption rate by the target date.

At the beginning of the project, we conducted interviews and focus groups. We asked not only typical UX questions that focused on people’s needs, pain points, and challenges, but also requested typical OCM questions that assessed people’s readiness, awareness, and desire for change. The first two letters in the ADKAR model. We also collaborated around the other three ADKAR building blocks:

  • K: Knowledge: Conducting in-person and online training sessions to help individuals learn about Teams
  • A: Ability: Holding office hours to share Teams tricks and tips and answer people’s questions about using Teams in real situations
  • R: Reinforcement: Working with key stakeholders and making recommendations to reinforce and sustain Teams adoption and use

As a project team, our collaboration and having a shared understanding of the individuals that we worked with was crucial for us to support each other and ensure the overall project success.

We also used artifacts that came out of UX to illustrate the ideal change outcome and increase an individual’s desire for the change. For example, through user research, we learned and documented the existing difficult process for ACA employees to organize, schedule, and attend meetings, which involved various web conference tools, specific people, and high incurred costs (Figure 1). Then we illustrated how Teams could streamline and simplify this process (Figure 2). UX artifacts like these helped ACA employees see how Teams could help with their daily work, which increased their desire to adopt Teams. Individuals became excited with Teams’ features and capabilities and looked forward to using it. They no longer felt that Teams was another “cool tool” that they were forced to use, and that took time to learn.

Figure 1: Meetings before Teams

Figure 1: Organizing and Scheduling Meetings Before Adopting Teams

Figure 2: Meetings after Teams

Figure 2: Organizing and Scheduling Meetings After Adopting Teams

In summary, implementing both UX and OCM benefits both end-users and organizations that we work with. OCM is also a relevant and crucial discipline for UX practitioners to learn about and become more proficient with, helping us grow professionally. This is especially the case for those who have been in the UX field for years and are looking for new ideas and adventures beyond traditional UX pathways and skillsets.

For More Information

If you are interested in learning more:

A variety of screens displaying Power Platform capabilities
Microsoft recently released a lot of new capabilities in their business applications, including the Microsoft Power Platform, which combines Flow, Power BI, Power Apps, the Common Data Service for apps, and Dynamics 365. To help people gain insights into the power of these applications, the Microsoft Technology Center in Reston, VA offered a Microsoft Business Applications Workshop for Federal Government, which I attended with two AIS colleagues.

As a User Experience (UX) Researcher who joined AIS earlier this year, I am new to Microsoft business applications. In addition, code writing is not my job responsibility and expertise, unlike my two colleagues. However, I found the workshop intriguing and registered for it right away because it was designed to:

  • Help people gain an understanding of the business applications
  • Be “interactive,” with hands-on opportunity for attendees to build a working application
  • Include topics like “solution envisioning and planning” and “no-code business workflow deployment” (Note that the workshop did offer coding exercises for developers on the last day of the workshop, which I did not attend.)

Indeed, attending the workshop allowed me to see the possibilities of these Microsoft applications, which is very relevant to what I do as a UX Researcher. It motivated me to further explore resources on this topic to better meet the needs of our current and future clients.

The User-Centered Design Process

The first project that I worked on after joining AIS was to help a client understand their employees’ needs and collect user requirements for a new intranet to be built on Office 365. In addition, the key stakeholders wanted to:

  • Streamline and automate their business processes, workflows, and document management
  • Drive overall collaboration and communication within the organization

I had extensive experience conducting user research for websites and web applications. To collect employee insights for this new intranet, we followed a user-centered design process:

  1. We started by interviewing stakeholders, content owners, and general employees to understand:
    • Their existing intranet use, areas that worked well, and areas that needed to improve
    • Intranet content that is important to them
    • Existing business processes, workflows, document management, internal collaboration, and communication
  2. Based on the interview findings, we then:
    • Compiled a list of important content pieces that the new intranet should include
    • Set up an online card sorting study for the employees to participate to inform the information architecture (IA) of the new intranet
    • Documented employees’ needs and expectations in other business areas
  3. Proposed a draft IA for the new intranet based on card sorting findings
  4. Developed a wireframe intranet prototype (using Axure), which reflected the draft IA, contained employee desired content, and mimicked the Office 365 structure and capabilities
  5. Conducted remote usability testing sessions with stakeholders and general employees to evaluate the wireframe prototype
  6. Finalized the intranet prototype and documented UX findings and recommendations to help developers build the new intranet using Office 365 in the next phase

As shown above, we made sure that the Intranet would meet the needs and expectations of the stakeholders and general employees, before it was coded and developed. However, as a UX researcher who does not code, I did not develop our solutions using the Microsoft business applications. I was curious to see how my technical colleagues would apply the capabilities of these applications to improve, streamline, and automate business processes and workflows.

Our user research showed that employees experienced a lot of frustration and pain points during their daily work. For example, both managers and general employees complained that their business processes heavily relied on emails, email attachments, and even hand-written notes, which were easy to miss or misplace and hard to locate. They described how difficult it was for them to keep track of project progresses and updates, especially when people from multiple departments were involved. Some of them also mentioned they had to manually enter or re-enter data during a workflow, which was error-prone. All these were real and common business process problems.

The Power of the Power Platform

This workshop provided me with a starting point and a glimpse into the power of the business applications. I’m still learning about their full power, the technical descriptions or details, and the rationale or logic behind each step that we went through when we built the model-driven app during the workshop. However, I was excited to walk away knowing about:

  • The use of a single, connected, and secure application platform to help organizations break down silos and improve their business outcomes
  • The availability of hundreds of out-of-box templates, connectors, and apps, including those that our client can take advantage of and easily customize, such as for onboarding tasks, leave requests, expense reimbursements, and shout-outs to co-workers
  • Building solutions and applications quickly and easily with simple drag-and-drop user interface, without the need to write a single line of code
  • Higher work efficiency of business people and non-developers to achieve what they want to do independently, relying less on IT support or developers, reducing overall cost, and saving time

After the workshop, I found a wealth of online resources and videos on Microsoft Business Applications. Below are some Microsoft webpages that describe the similar content or steps that we went through during the workshop:

I look forward to more in-depth learning about this topic to better understand the power of Microsoft business applications. With this knowledge and together with my colleagues, we will propose and build the best business solutions based on user research, helping our clients achieve desired outcomes by improving their employee experience.