Tana Green
In-house Product Strategist leading IQVIA's Apollo product design team, directing OCE Engage from design-system review through Release 1 GA. Partnered with a developer lead and engagement manager on Engage's foundations, then led three designers through early prototyping for product managers acceptance. As full product features for MVP were defined, I directed four UX designers, two UI designers, and a design project manager through delivery, leading workshops and product-owner handoffs.
My director at IQVIA asked me to lead design for an entirely new class of product: one running a custom "Apollo" design system inside Salesforce Lightning rather than off-the-shelf Lightning patterns.
Event-planning compliance is a category where life sciences companies must document every interaction with a health care professional, from attendee eligibility to expert rates to the approval trail, so audit-readiness within a platform such as Salesforce matters as much as usability.
My role moved deliberately from individual contribution of a concept prototype to leadership across nine months. I spent the first several months as UX lead reviewing Apollo's components and patterns alongside the react developer lead and UI design lead, the groundwork that made me confident the system could carry a shippable product. From there I moved into hands-on prototyping to define the core experiences, then stepped back into direction as the team scaled toward Release 1. My focus was on workshop facilitation, prioritization, and handoff to the business product owners.
OCE Engage sat at the intersection of two IQVIA strategic imperatives: expanding the Salesforce-platform product portfolio and deepening the company's stake in life sciences compliance workflows. Apollo represented IQVIA's investment in a proprietary design language meant to differentiate that portfolio, and Engage was the first web product to prove the system in a SalesForce-platformed production. This meant design decisions carried consequences well beyond this one release. I weighed each pattern choice against reuse across the portfolio, not just fit for Engage.
Engage was not built from a blank sheet. The product consolidated two similar event-planning products IQVIA had acquired, each carrying an installed base of users and managers already living with its strengths and its workarounds.
Stakeholders & users
Accessibility & language needs
Apollo needed to be a true design system, not a one-off skin, so its components could serve Engage and every future Salesforce-platform product at IQVIA. That long-term investment collided with a compressed Release 1 timeline: several components were still in development with the component team at the point we needed them.
I accepted the need to launch on a mix of custom and readily available Lightning components rather than delay for full design-system parity, judging functional completeness for early customers to be worth more than visual consistency. The shipped release looked slightly different from the Apollo UI, but it met every functional requirement defined in the wireframes and user flows approved by the business stakeholders. Given the two global clients who signed shortly after, I would make the same call again, though not without the caveat in Outcomes below.
A UX researcher on our team conducted sentiment interviews with current users and managers of both legacy products, capturing what worked, what people routed around, and where the tools had quietly lost their trust. That study gave us something uncommon at the concept stage: evidence of feature efficacy drawn from real operating history rather than assumption.
I reviewed the findings and translated them into actionable guidance for the UX designers, specifying what to carry forward, what to redesign, and which past performance problems the flows and wireframe prototypes needed to solve. That guidance set the bar for Release 1 and kept it there. Parity with the acquired products was never the goal; measurable improvement for the customers inheriting the consolidation was, and it shaped feature decisions from the dashboard through expert search.
Design ran from early sales-prototype concepts through to 400+ user flows and wireframes and 200+ high-fidelity mockups covering Release 1's critical features.
Three flows carried the product. The homepage dashboard surfaced insights and required actions, so a planner could see what needed attention before opening anything. The engagement-creation flow embedded the compliance checklist directly in the workflow rather than bolting it on as a final gate. The expert search and profile flow handled inviting health care professionals along with the rate and service calculations that make those invitations compliant. Throughout, the team ran a standard user-centered process, moving from research-informed concepts through iterative wireframes to developer-ready mockups.
We built the team in two stages, growing it in response to validated scope rather than pre-hiring to a fixed org chart: a small prototype group first, then a full production team once the concept had earned its charter. The team's demeanor was regularly joyful and rigorous in equal measure, and the productivity showed it.
My stakeholder relationships ran on two levels. During prototyping I worked directly with the program manager and primary Product Owner to align on vision and priorities. Through production I served as the interface between the design team and the business product owners, leading workshops, design critiques, presentations, and formal handoff reviews, while deliberately keeping my own reviews light so I did not become the bottleneck. That posture extended to go-to-market work, where I co-directed design and strategy for a conference video alongside a sales lead and the business PO.
Scope arrived thin: a few wireframes of standard Salesforce patterns plus Product Owner requirements. My first job was converting that into a prototype that doubled as a scope instrument, defining what Release 1 would and would not include while it was still cheap to change.
Through production, scope management became dependency management. My component-requirements analysis mapped standard Salesforce related-list features against what Engage actually needed, giving the engineering team a concrete change-control artifact rather than a verbal request. Handoff meetings and design reviews with Product Owners functioned as approval gates before work moved from UX to UI and on to engineering. The component build ran in parallel with product design rather than ahead of it, so sequencing and readiness were renegotiated continuously, the single largest source of schedule risk on the engagement.
Once the Product Owners approved UX work, wireframes went to the UI designers, who finalized comps for delivery to component and product development. I coordinated directly with the Gemini component development team to scope roughly 60 new Apollo web components, the output of my requirements analysis, for the product engineering team to build. I also provided product design direction and go-to-market strategy, alongside a sales lead and the business product owner, for a promotional video shown belowused at conferences and in customer pitches; a separate IQVIA team produced it using our design team's visuals.
password: MakeItSo
OCE Engage reached general availability in April 2020. Our business product owner reported that customers found it intuitive and that, from the business's perspective, the product was generally available in the fullest sense. Two global clients purchased Engage and began configuring it for their business units, including a signed contract with Novartis in China. By my assessment the product met its ROI on Release 1 alone and continued contributing to IQVIA's organic growth afterward.
What I'd improve next: I would have negotiated a component-readiness gate into the Release 1 schedule rather than absorbing the mismatch at the end. Shipping on stock Lightning components got us to market, but it left the first release visually inconsistent with the design system we had spent months building, and every later release might pay a small remediation tax to close that gap.
