IQVIA - Engage
Description: Engage is an event management tool that allows organizers to plan a variety of events globally. Engage ensures that events are compliant and meet the health industry’s rigorous standards.
Engage is built using Salesforce Lightning; the product was one of the first applications to be built completely on the platform. Engage is built using a mix of lightning components as well as custom components built by the IQVIA team.
My Role: UX Designer
The Team: 3 Product Owners, 1 Product Manager, 1 Product Strategist, 3 UX Designers, 1 UX Researcher, 1 UI Designer, and 20 Developers.
My Responsibilities: I worked on scoping the project, creating user flows and wireframes, and designing rapid prototypes for product showcasing and user testing.
Tools: Sketch, Framer X, Omnigraffle, Zeplin, Salesforce Lightning
Basics
Overview
IQVIA is a healthcare technology company that uses analytics and science to help healthcare stakeholders find better solutions for their patients. IQVIA has a number of different products in their portfolio ranging from drug conception applications to clinical trials and pharmaceutical marketing. I worked on the Apollo Design Team which is an in-house design agency for IQVIA. Over the years, IQVIA has acquired a number of different applications and products that have diverse styles and functionality. The Apollo team is working to create a design system that will work across all of IQVIA’s products. Apollo is also working on specific products to update their UX and move the UI to the Apollo Design System.
Engage was built using Salesforce Lightning. This was the first IQVIA product to use the platform therefore we not only had to design components for the product but also for the Gemini Library. The Gemini Library is a sister to the Apollo Design System. Our goal was to create components that could work in Salesforce but also stay true to the Apollo brand.
The Process
Over the course of six months, the team produced over 300 user flows and wireframes, and over 900 high-fidelity mockups for all of the critical features the business product owners requested for Release 1 of Engage.
The image shows the typical user centered design process utilized by the Apollo Engage design team.
Research
User Research & Personas
Our lead researcher gathered information through 45 minute interviews with 14 users, some of which were also SMEs. The research identified three key personas: Organizers, Approvers, and Administrators. We primarily focused on event organizers or engagement specialists.
Engagement specialists have two main concerns:
Engagement specialists manage multiple engagements at once. They need to know what stage each engagement is in and the action items that need to take place in order to move forward.
Engagement specialists need to create feasible events. Feasibility is measured in terms of risk. As the engagement specialist adds new details to the event, they want to make sure that each new component is considered “safe.”
User Flows
The team spent a lot of time with the product owners and mapped out user-flows for our personas. The user-flows helped us not only identify and define each step in creating an engagement, but also gave the team insight into potential pain points for the users journey.
User flows were absolutely essential throughout the end to end process as a tool to identify each step a user could potentially take for each task. User flows were designed and iterated through for each task such as, “I want to invite experts to the engagement”, “I want to manage participant expenses” or “I want to identify the risks related to this engagement.”
Design
Wireframes & Prototyping
We used Sketch app and Framer X to wireframe and build out prototypes rapidly. Our wireframe process focused on each user flow and each screen identified in that user flow. As we fleshed out and ideated, we established a review cadence that included the design team, dev team, and product owners. This provided useful and timely feedback. Our design decisions were based on the feedback from both our internal users through guerrilla testing as well as from stakeholders on the project.
The wireframes below are a small sample of the final approved wireframes.
This wire shows risk analysis for an engagement. The engagement specialist can see the compliance risk displayed in the highlight panel. If they select the score, it opens a detailed report. The gauges in the Risk Assessment component display the two main risk scores: compliance and process. Compliance focuses on rules and regulations while process focuses on details like start date, expert qualifications, etc. The High Risk table shows especially risky pieces that the user should evaluate under further review.
This wireframe shows the peek view specifications set by the Apollo Design Library. While building Engage, we tried to match these specifications as much as possible while also adhering to the Salesforce limitations.
This wire shows the monitoring panel which appears on the engagement overview page. This shows various components related to engagements and their accompanying statuses. An event organizer needs to know the status of the engagement on a day-to-day basis. This panel allows them to see if certain components have been approved or rejected.
Since we were trying to build a product that not only met Salesforce’s design patterns but also those set by the Apollo Design Team, we created many wires that detailed tall the interaction specifications to ensure UI designers and developers knew exactly what to build. You can see the style guide for a peek view in Apollo and Engage below as well as the final product.
This wireframe shows an example of how peek view will be used in the Engage product. I was very thorough with my designs to ensure the engineering team could work quickly and independently.
This wire depicts the warning modal an engagement specialist would see when submitting an engagement for review. This warns the user that some items may not be approved and allows them to access those items for additional detail.
This wireframe shows the peek view specifications created for Engage. We were able to maintain many of the Apollo standards but had to differentiate a little for the unique use cases.
Visual Design
After wireframe approval, we moved onto visual design which included utilizing our Apollo Design System. As mentioned previously, Engage is the first product being built on Salesforce Lightning. We created a Gemini Library to act as a sister library for the Apollo Design System. The Gemini Library is composed of custom lightning components that match the branding developed by Apollo. We continued to work closely with the visual designers including twice weekly design reviews and approvals from not only product, but approval from the UX team.
This is the UI mockup for Risk Assessment. The mockup shows all of the icons and colors that have been approved by the Apollo Design team. The mockup further iterates on the original design and adds more accessibility features. For example. the gauges show color, language and arrows to display high, moderate and low values.
This mockup shows the monitoring panel and the action panel on the overview page along with other components. The UI mockup is using all of Apollo’s colors and charts and graphs that have been approved by the team. This mockup shows exactly where different components should appear on the page and how they interact with one another.
This is a UI mockup for peek view. The mockup shows all of the icons that will be used in the product, the correct colors and spacing. This mockup was placed in Zeplin so engineers could see the exact specifications.
Reflection
Next Steps
Continued Involvement: Engage is an ongoing engagement, so our work continues and as a team we continue to provide support and guidance for both the product team as well as the developers.
Additional Research: Research is continuing and testing is being done on our first releases. With each new test, we learn additional ways to improve the product and iterate on our existing designs. Here are some of the current needs identified by user research:
Graphs: Redesign the graphs to make them easier to understand for the user. Graphs should display less data, look cleaner and be more task-oriented.
Information Architecture: Continue to refine the site’s information architecture. Vertical navigation items can be regrouped and organized to provide the user more specification.
Component Creation: The end result for Release 1 looks slightly different than the Apollo UI. Due to an unreasonable product development timeline, we were unable to create all the custom components necessary for the designs. We instead had to utilize Salesforce Lightning components that were rebranded in Apollo colors. As our development timeline slows, we will have more time to continue to build out the full Apollo UI.
Takeaways
Get the ducks in a row: Engage is being built very rapidly. Research, UX, UI and development is all happening concurrently which can lead to some pretty chaotic situations. If one team decides to change a button, tag or notification, it impacts all of our work.
Knowledge is power: The product owners overseeing this project had not worked with a design team before. They initially expected us to create pixel-perfect comps in minutes and didn’t understand the purpose of user testing, research and data-driven design. Educating the product owners about the design process built trust amongst the different disciplines on our team.