Healthwise by WebMD Ignite
Automating B2B Provisioning
Streamlining Organization Setup with the Healthwise Administrative Platform
Contribution
User research & testing
UX/UI design
Design system foundation
Information architecture
Meeting facilitation with stakeholders
Tools
Adobe XD
UserTesting
Jira & Confluence
Mural
Microsoft Teams
Duration
2 years
Project Background
Provisioning Platform
Healthwise is a healthcare content and solutions provider that serves hospital systems, providers, payers, and patients. In 2020, my team was assigned the task of creating a new B2B2C platform to unify internal and external tools. The goal was to provide healthcare providers with a comprehensive ecosystem where they could manage Healthwise applications, patient consumers, and patient education content all in one place. The platform also supports omnichannel communications within Healthwise solutions, captures utilization data, and provides centralized configuration and branding across all applications.
What is Provisioning?
Provisioning at Healthwise involves setting up client organizations, assigning user roles, and configuring access to Healthwise products. Improving this process is crucial for efficiency, user experience, compliance, scalability, and cost-effectiveness. It streamlines client onboarding, reduces errors, enhances satisfaction, ensures compliance, supports scalability, and lowers operational costs. Provisioning is the recording, in structured data, of what a client is delivered. It includes the product database, the input capability to record exactly what a client implements and the reporting to know at anytime what applications, components and features a client has licensed, implemented, is actively using, intends to use in the future, does not intend to implement or has discontinued use of. Provisioning refers to what we do that enables the use of platform foundations. Delivery of established products is not supported by platform provisioning.
Platform Objectives
A new unified client model focused on identifying and managing HW clients and their business models.
A new user model with enhanced security authentication and authorization of users at every level of the client organization and applications.
A new unified licensing model to support selling, accounting and provisioning HW products.
A new content and delivery model to deliver, manage and discover content and associated metadata.
Who is impacted the most?
Administrators
Goal: Perform tasks necessary for organization's license and use of HW products/ content
Analysts
Goal: Access reports about use of organization’s licensed products and content
IT Specialists
Goal: Configure and launch Healthwise products in their organization’s system as quickly and easily as possible.
Integration Engineers
WHY? “because how we provision our products and content is the first domino”
”if we can’t satisfy the internal users, whether or not we can get this out to external clients – we are dying under the debt and all the non-value added things that they have to do to satisfy client, AM, AE requests “
Platform Personas:
Client Services Manager
Internal HW only (2-3 only). Likely manager of IEs
Grant access to Integration Engineers
Integration Engineer
Internal HW only
HW Super Users - Can do everything except create themselves
Create Client orgs, Associate Accounts, Create Subscriptions, Associate Apps.
Organization Admin
External Client Superuser (1-2 created by IE)
Resource exists in HW directory
Create Sub Admins
Key take away
Impossible to tackle all of the business problems all at once. It was important to prioritize personas and use casesas it allowed for our team to keep a limited scopein the development process.
BUSINESS CASE
Business Case
Licensing is what the client has purchased. Provisioning is what has been made available to the client to use. Providing intelligence to HW and our clients with reliable real-time data to know what applications, components and features a client has licensed, implemented, is actively using, intends to use in the future, does not intend to implement or has discontinued use of.
Business Problem
Today what a client has licensed and been delivered is reflected largely in manual and unstructured data. It is not possible for us to liberate this data in its current form. Meaning, we can't use it to make business decisions and we can't expose it to clients for them to manage users and make their own decisions based on product and usage analytics.
The system has become very complex and if actions are not taken in the proper order it makes it impossible to provision clients correctly, ever.
Internally few people can fully understand client implementations. Often to answer simple questions client services must refer to contracts, Salesforce, key manager etc to connect the dots and determine the answer. Occasionally in these research activities they discover errors in client records because maintenance is completely manual. Every question accounts for minutes sometimes an hour or more in non-value added time.
We work to shield clients from these problems in time consuming and unsustainable ways. We can no longer afford to do this. We have already seen direct costs when we've had to credit clients for failing to deliver something they had purchased and paid for. With our desire to acquire and maintain larger healthcare systems, and our intent to allow clients to share custom content, analytics and users across various HW applications, we can no longer continue to patch and defer the investment in a proper delivery management system.
Why Now?
Provisioning is critically important because it binds what a client has licensed to what we've delivered to them and what they are invoiced for. It will enable us over time to bring the benefit of the platform to clients and HW internally by providing a means for client services to record exactly what a client has been given as well as what they have. It begins with a solution that improves the recording and delivery of products built on the platform and will enable HW to see data across all products a client license.
What are the artifacts subject to licensing?
Content: a collection of content assets, from simple Structured Content Libraries to composited documents like Programs and Patient Instructions.
Applications: the software that the clients interact with to search, access and deliver the Content Library. Only application features that have an impact on provisioning and pricing are relevant for the scope of Provisioning.
Their problem
A suite of siloed products
Too many passwords - Each application requires its own login, causing frustration for clients.
No communication between products - Clients are unable to connect data and share content between applications.
Inconsistent look and feel - Lack of a shared design library made it difficult to align the products with the Healthwise brand.
No communication between products
Clients were unable to connect data and share content between applications.
No idea who has access to what
Clients and HW didn’t have a good way to know what they have access to.
Too many passwords
Each application requires it's own login leaving clients frustrated.
Large Hospital Systems are demanding enterprise solutions that scale to support users, configurations and business models, offer SSO and Active Directory integration. New clients like Christiana Care, Trinity and others are demanding we deliver a holistic solution, not a patchwork of disconnected products. We either must commit to meeting this need from the ground up or accept the loss of existing clients and prospects. We have accepted that we cannot retrofit this into existing products and have committed to build the platform on which all evolving product will be built.
In creating the "established and evolving" product lifecycle stages, we purposefully decided to invest less in established products, and focus development resources on new platform solutions. But because we'll have clients contracting, licensing and receiving our established products for several more years, we must ensure we can control and audit how we contract, invoice and deliver all our products. In addition, this vital business information is needed to assess both client and product health to optimize usage, prioritize replacement work. sunset established product, and more.
Today we have two guiding principles:
To build innovative, future products enabling single sign on, with unified client and user management capabilities, and to be provisioned based on what has been quoted and contracted.
To maintain our existing revenue from products not built to talk to one another, cannot support SSO and are costly to retrofit.
We cannot solve the first and ignore the second. Therefore, we must thoughtfully and systematically build for the future while maintaining client satisfaction, accurate accounting and value-adding client services.
Internal Benefits
Internal benefits will include structured, reportable data both for what clients are entitled to have and have been provisioned, for established product and on the new platform, as well as a reporting service to get this info.
This project will deliver incremental internal benefits:
"Client Management" to support various client "archetypes" allowing us to model clients' actual business model that in time will support better data and better analytics.
Support of "Identity Providers" will allow clients to either use our SSO or eventually to integrate into their active directories. Eliminating HW management of users by enabling clients to be responsible to terminate access when employees leave.
Provisioning interface allowing client services to have more control over what can and can't be delivered to clients.
A standard data model for packages, applications, and content for all products. To be used across all products, enterprise reporting and in platform provisioning.
A process of auditing and recording existing agreement and deliveries in structured data bringing HW closer to our goal of tracking and reporting client entitlement.
The platform doesn't make anything better for the delivery or management of existing clients and users, but we can make the data better. Better controls, better information and better support for all client and all products.
For engineering there should be significant internal benefit by iteratively reducing the amount of technical debt from established product. Our new platform will support building and releasing product and features more quickly.
External Factors
In addition to the large hospital systems driving us to provide a more sophisticated enterprise solution, we have lost confidence with some existing clients because as they increase the number of HW products in their portfolio, they are frustrated by the lack of basic interconnectedness of our products. Branding and user admin do not span applications. Separate logins and inability to manage user access frustrates IT and clinical admins.
We want to attract and delight healthcare systems like Trinity and Christiana care and we need to be able to do it without massive workarounds and complexity for them. We know that integration is a key to our successful adoption, so we have to make this easier for the IT and clinical teams to implement and use our solutions. We also want to provide them analytics to show improvements in patient health and outcomes. All of this will be easier with a platform and data accuracy and reporting.
Additionally, when we discovered St Luke's paid for content they never received, our auditors took a hard look at our repayment and recommended improved internal controls. At that time (2017) we committed to improve internal controls that would allow us to catch mistakes more quickly.
While auditors cared less about revenue we did not receive, during the migration from blue folders to electronic billing, we found we'd failed to charge a client close to $500,000. of which we were only able to recoup about half.
Intangible Benefits
Nearly everyone at HW has experienced some aspect of this problem firsthand. It's the inability to know what a client has. It's the inability to aggregate data across applications and clients. It's frustration because our products do not easily talk to one another and in some cases not at all. The platform will make this interconnectedness possible. The platform will also improve client satisfaction and security with the introduction of single-sign-on. Clients will be able to manage applications, users and configurations from a centralized location. As more products are built on the platform, clients will see more and more of the benefits. The user and client management consoles have an updated look and feel consistent with the upcoming HRC refresh and recent .Org refresh. We expect all of this to please customers and improve our brand continuity.
Internally, the ability for client services to provision new products from a provisioning console that is integrated with what they are permitted to be delivered is a game changer. We expect that over time our client services will have increased bandwidth to perform value added activities because they are free from the cumbersome and complex activities around translating the contract into assets, configurations and skus that represent what we have sold and delivered, but without any constraints or controls.
Imagine in the future all of Client Services, Professional Services, and Account Managers could share in the delivery of product to clients because the system constrains what can be delivered to what has been licensed.
Cost of NOT Doing This
We have delayed doing this work for several years. We have implemented workarounds with unintended consequences to avoid this work because it's complicated and has no direct tie to revenue. The cost of not doing anything is great because we spend ever-increasing time supporting a system that no longer meets our business needs and limits our ability to evolve and innovate. Today a significant portion of time spent by client services is in non-value add activities such as answering questions as simple as, "what has a client licensed and how are they using it?". Often IEs, not account managers are the only people capable of answering this, and as often it takes multiple IEs to accurately answer this for clients with a breadth of HW products.
It would be a mistake and a fallacy to assume that building a platform for evolving products without also implementing some constraints between what we license, invoice and deliver will result in a system free of these problems. HW must invest in both the future and the present.
Healthwise’s suite of products
Provisioning is the translation of the legal contracts to deployable products.
Pain points:
Manual Setup & Delivery
Client org structures are not simple these days (mergers & acquisitions)
Not machine consumable
Error prone
One of the first things we heard was that our Ies is how painful it is to do the very first step of setting up an organization. the contract didn’t specify in any machine consumable way, the exact systems, credentials, messages, and general workflow necessary to allow a Client access to Healthwise systems.
What's available to be provisioned to a client within a subscription is defined by the entitlement packet.
Clients can have multiple subscriptions and organizational structures
Introduction:
Brief overview of the HealthwiseAdmin Platform project.
Mention the client (Healthwise) and the problem statement addressed by the project.
Highlight the key objectives and goals of the project.
Project Overview:
Provide more context about Healthwise as a healthcare content and solutions provider.
Describe the scope and scale of the project, including its duration and the team's role.
Key Outcomes:
Summarize the main achievements and deliverables of the project, such as the launch of the new consumer app and the implementation of a user management system.
Highlight any significant impacts or benefits resulting from the project's outcomes.
Problem Statement:
Describe the challenges or pain points faced by Healthwise prior to the project.
Discuss the limitations of the existing systems and the specific problems that needed to be addressed.
Solution Overview:
Outline the solutions proposed and implemented to address the identified problems.
Highlight the key features and functionalities introduced in the HealthwiseAdmin Platform.
Discuss how the solutions align with the project goals and objectives.
User-Centric Approach:
Detail the user research methods employed, including user interviews, personas, and user testing.
Explain how user feedback informed the design decisions and iterations throughout the project.
Technical Architecture:
Provide an overview of the technical architecture of the HealthwiseAdmin Platform.
Describe the high-level components and technologies used in building the platform.
Design Process:
Describe the design process followed, including activities such as wireframing, prototyping, and user interface (UI) design.
Discuss any challenges encountered during the design process and how they were overcome.
Development and Implementation:
Explain the development process, including any iterations or adjustments made during implementation.
Highlight any collaboration with developers, engineers, or other stakeholders during the development phase.
User Testing and Validation:
Discuss the methods used for user testing and validation, including internal and external testing.
Present key findings from user testing sessions and how they influenced the final design.
Results and Impact:
Quantify the impact of the project in terms of improved user experience, efficiency gains, or other measurable outcomes.
Share any positive feedback or testimonials received from stakeholders or users.
Lessons Learned and Reflection:
Reflect on lessons learned from the project, including successes and areas for improvement.
Discuss any insights gained that could be applied to future projects or initiatives.
Conclusion:
Summarize the overall achievements of the HealthwiseAdmin Platform project.
Reiterate the key benefits and impacts of the project on Healthwise and its stakeholders.
Objective
Develop a single tool to be used to create, view, and manage all client user accounts and licensing for Healthwise resources
Goal: Make it easier to create & manage organizations.
Goal is to make it easier for engineers to add a new or migrate an existing client to the platform.
Process
Academic and Industry Insight
Intent: Develop a comprehensive understanding of how academic and industry experts value and define a platform.
Objectives:
Define context and common terminology
Answer the questions: Why would any company/organization/group establish a platform model?
Process:
Individuals on the team (or anyone else) identify articles/media that contribute to the conversation and fills out a review sheet for each. They make a copy of Sample Review document and fill it out so that others can benefit from the knowledge gained.
Periodically, team members will meet together to discuss the articles that were identified, and the relative merits and interesting points of each
Duration: 1.5 weeks
Note:
It is intended that team members will refrain from forming opinions about the Healthwise platform during this stage. Certainly, judgment must be used to identify worthwhile articles and formulate opinions about the relative merits of the claims made in them, but those opinions will relate to the article itself or the system defined within the article and not yet towards the Healthwise platform.
Input from Stakeholders
Intent: Learn how others within Healthwise value the concept of a new platform, and what is must do to be successful.
Objectives:
Understand what a platform is intended to do specifically for Healthwise. Is there value to Healthwise in a platform approach? What is it?
All available ideas/angles are explored and understood.
Insight from all interested parties at Healthwise is added to the growing body of knowledge
Process:
Lots o' meetings with various groups or individuals at Healthwise. These meetings are organized with the assistance of others (John Baisch, Jason Hessing, etc.) A dedicated note taker is present at each meeting and fully documents the contents of the meeting, including the recommendations, suggestions, concerns, and opinions of the participants.
Potential partner clients are explored and engaged in the same way as internal groups/individuals.
Potential expert consultants are explored to evaluate whether their insight could be valuable.
Follow ups may be scheduled with participants on an as-needed or as-desired basis to make sure that all perspectives are properly understood.
Duration: 2-3 weeks
Note:
Once again, it is intended that team members will refrain from forming opinions about the Healthwise platform or about the relative merits of received input during this stage.
Coalescing of Knowledge and Ideas
Intent: Group learnings into common themes that help define what Healthwise should do with a platform and how it should work.
Objectives:
Defined guidelines/criteria for what the Healthwise platform will provide. This is not the definition of the platform yet, but the creation of guiding principles that will help inform the definition and decision later about what it does or doesn't have.
Answer: "What is the Healthwise Platform?" Not necessarily, "What is in the Healthwise Platform?" The definition, but not the specification, of the platform.
Define language used to describe the platform. Make the external and internal terminology and other language artifacts consistent (i.e., Market Solutions, Product, Content, Technology, Finance, etc., to all understand and discuss it the same way).
Process: TBD
Duration: 1-1.5 weeks
Platform Description
Intent: Communicate a definition for what is part of a new platform, what capabilities it supports, and what it doesn't.
Objectives:
Identify specific capabilities that should be provided by the platform (i.e., the platform specifications)
Identify capabilities/features/services that will not be provided by the platform, and address how they will be supported or provided instead.
Address concerns, incongruities, opinions, recommendations, or suggestions from all stakeholder meetings. Make sure everyone feels like their needs are met somehow, or explain why we will not be meeting those needs yet.
Process: TBD
Duration: 1 week
Technical Architecture
Intent: Deliver a forward-looking, high-level technical architecture that provides a map for how the platform will take shape.
Objectives:
A high-level technical architecture is in place. This will serve as a guide for all who are contributing to build the platform.
High-level work planning is organized (i.e., who will be building which parts of the platform, sequence, etc.)
Process: TBD
Duration: 2 weeks
Note: Much of this work may fall to a sub- or super-set of this team, including architectural representatives from other teams, including teams outside of engineering.
Platform Development
Intent: Begin to develop the platform. Establish milestones. Prepare communication models.
1.0 Solution
Facilitated meetings & discovery sessions to understand Admin users
Conducted discovery sessions with Marketing, Product leads, and Customer Success team.
Analyzed customer journeys of admins, analysts, clinical champions, and IT personas to understand pain points and opportunities.
Collaborated with customer success and marketing leads to reorganize customer success and marketing pages based on user needs and data analysis.
Redesigned Client Success Center.
Service Blueprint Activity
As a team we examined various personas, including the IT persona, to learn about their Healthwise touch points, their goals, their pain points, and objectives in different phases of the product journey.
Golden Journey activity
Leveraging the insights gained from client interviews and the analysis of existing site information, we identified the most critical tasks for our clients. With this understanding, I prompted stakeholders to reimagine the complex administrative hierarchy as a "Golden Journey." This envisioned journey would offer a more direct and efficient path for users, enabling them to access the desired information quickly and effortlessly.
1.0 Interim Solution
Redesigned existing Client Success Center to provide clients and admins with the ability to see what they license
The Client Success Center was one of the places that users accessed to set up their organization with Healthwise products.
Redesigned Healthwise Client Success Center
2.0 Solution
Conducted discovery sessions to learn what Admins need in a new platform
Following the 1.0 solution mentioned above, I then conducted additional discovery sessions with a specific focus on building the Healthwise platform, a new product aimed at addressing some of the issues identified during the client success discovery sessions. Our goal was to unify the Healthwise product experience into a cohesive and streamlined delivery for our clients. Leveraging the insights gained from the early discovery sessions, we engaged stakeholders in further discussions to narrow down the scope and gain a deeper understanding of the problem. These sessions allowed us to refine our approach, align our goals, and lay a strong foundation for developing a successful Healthwise platform that meets the needs of our clients and provides a seamless user experience.
Unique individuals who mentioned what they would need and like to see in the new platform experience.
Research
Identified key individuals' needs and preferences for the new platform experience.
Interviewed 17 teams - Conducted robust and extensive interviews with stakeholders and clients.
Researched competitors to gather insights and ideas.
Narrowing Down to Core Capabilities
We narrowed the scope of the platform to the following key capabilities:
Single Sign-On
Multi-Tenancy (AKA Client Model)
Change Reporting
User Management
Analytics
Provisioning
Unified Licensing Model
A set of services and tools to support the selling, accounting, and provisioning of Healthwise products to
partners and clients. This model will be highly flexible, allowing Healthwise to easily combine subsets of content and capabilities in new packages to meet the specific needs of each client, while also allowing those packages to be modified later as the client’s needs evolve. The licensing model will also support clear visibility into what each client has licensed and their implementation life cycle.
Why
The need for a consistent and common vocabulary around the definition of our products was discussed throughout many interviews. The lack of clarity and details of what a client has licensed has led to confusion throughout the organization. By developing a unified licensing model, we can bring a clear understanding to the full life cycle from sales, contracting, provisioning, implementing, monitoring, and support.
Client Model
Working with the data architect & client services (the people who were in SF regularly), we were able to understand better how SF information can influence product delivery and determined that SF is the SOT
Within Salesforce there are relationships between accounts and multiple accounts may be used to represent what we consider a single client. The Platform depends on relationships between Salesforce accounts to be managed in Salesforce and not the Platform. When determining what assets can be provisioned for an Organization it is the set of all related Salesforce accounts that determines what has been licensed by the Organization.
An Organization is a client’s identity within the Platform. Every client that directly licenses Healthwise products from us is represented as an Organization. The Organization serves as a bridge to link our runtime environment to our business systems such as Salesforce.
1:1 association between SF & an Organization on the platform
Relationships are managed in SF NOT the Platform
Let SF be the source of truth
A subscription is a container for managing and isolating a set of Healthwise resources. Resources are defined as users, assets, and data. An Organization can have 1 or more Subscriptions.
Subscriptions are necessary to enable a client to separate entities within their own organization. This could be based on environments such as Test and Production or something with business meaning, e.g. Clinic A or Clinic B.
What goes into a Subscription?
All assets that are provisioned for a client are contained within a Subscription.
The permissions that an individual user has are contained within a Subscription.
The data generated by assets provisioned in the Subscription are contained with the Subscription.
2.0 Solution
Identified core goals for Healthwise Admin Portal
Our solution involved building a platform within a unified ecosystem, enabling the following:
Sign-on with one username
All new applications can authenticate with Okta and be accessed centrally.
Centralized tools for admins
Patient users, clients, and tools can be managed from a central location.
Unified design system
Designers and front-end developers rely on the new design system for developing new products.
Healthwise Administrative Portal
Using Personas to Prioritize Features
Key take aways:
After meeting with all the different teams, we uncovered a lot of additional problems for the team to solve. However, it would be impossible to tackle all of the problems all at once. It was important to prioritize personas and use cases as it allowed for our team to keep a limited scope in the development process.
2.0 - Personas & Use Cases
Identified the critical tasks for each persona for MVP
By working with the customer success, sales, marketing, & content teams, we were able to identify the main personas that will be using the MyHealthwise interface. Once personas were generated, we then wrote out use cases and key interaction points
Prioritized user requirements
Created efficient user flows
User flows were presented with the team and altered over the course of the discovery to meet the key requirements of the project. Objectives of the flow were to maintain minimal functionality and optimize the admins tasks.
Requirements were prioritized by being labeled as must haves, nice to have, and future ideas.
2.0 - Prototypes & Iterations
Created wireframes & prototypes focusing on User Management
April 2019
Created wireframes to present and discuss with Healthwise teams, focusing on common tasks, FAQs, and resources.
The feedback from stakeholders identified issues with stacked navigation and undefined information within the user table management table which needed to be addressed.
July 2019
Iterated wireframes with a focus on filtering and searching the table, defining columns and actions.
Tested designs with clients and internally, simplifying the interface by removing stacked navigation and extraneous information to allow for more horizontal space to accommodate the growing user management table.
August 2019
Redesigned the space to accommodate changes in back-end data architecture and present complex hierarchy of organizations.
Addressed the need for data visualization for quick insights.
March 2020
Added data visualization elements to provide users with scannable information about product usage.
Continued to refine the prototype with design system components.
2.0 - Final
The current
First pass based on information that was given to me about the existing system. I worked with the Archi to figure it out. I validated internally with HW users familiar to figure out the most natural steps - create an org first, then link to SF then add users and subscriptions. highly manual entry. Due to nature of our modern world of mergers and acquisitions - orgs can have multiple sub orgs under a parent and their relationships can be totally different. We may have existing contracts with an acquired org. Etc etc. Need to specify how they connect
Validation
Internally tested XD and production prototypes with Healthwise users.
Conducted client testing and external testing with non-users.
Limited product analytics data available so needed to rely on user testing & feedback to make decisions.
UX testing
Prototypes tested with internal and external users for navigation, comprehension, and task completion.
tested with 6 internal HW users . Tested this design with 2 integration engineers & 2 account managers
moderated sessions
Tested with 5 external users to test for general flow and navigation - recruited administrators who work in healthcare . unmoderated. simulate the role of a brand new client using the system to try to catch any flow issues upfront
Tested
time on tasks - create a new organization, add a new user, identify which products your organization had access to,
Findings:
Users skipped the salesforce association
Users weren’t familiar with the terms used leading to confusion
High cognitive load checking between SF documents and the platform
Still a manual process, frustrating
Problems:
No supportive text to explain to the users what each part means
Unclear what is considered a complete organization
Direct/indirect accounts are required but can easily be skipped over
Hiding options behind drop downs reduce findability
Screenshot of usertesting.com test of prototype
UX in-application copy documentation
UX documentation for developers and PMs
UX Copy & Documentation
I worked with the client services team to make sure that we use a language that our clients would understand within the application. I also created UX documentation to help communicate with the developers and PMs how each portion of the prototype would function.
Key take aways:
Working on in-app copy with people outside of the development team opened up our work to the company. As a result, we identified gaps and inconsistencies in internal knowledge which we were able to address moving forward. Also, by writing out documentation for developers before code was written, we were able to review things like error messages and validations as a team. This practice created consistent behavior across the product and identified edge case behaviors.
UI kit - XD
Research & documentation for component best practices.
Design system
In addition to creating a unified ecosystem, it was also necessary to create a unified design language that could be shared across our teams. Working closely with designers and developers, we were able to start the development of a UI kit. Additionally, I wrote extensive documentation to outline guidelines and best practices of components based on research.
Process, weekly work sessions worksessions with stakeholders including devs, content team, engineerings, & pms
Month 1 :Gather documented knowledge about the current state of the design language at Healthwise.
Month 2: Catalog the user interface use cases and specific needs of Healthwise applications.
Month 3: Make an engineering decision about the specific implementation technology of the Component Library.
Month 4: Create the backlogs and designate specific responsibilities for the execution and completion of the work.
Key take aways:
Working with back-end and front-end developers helped narrow the scope of design components when working in a green-field territory. It was best to design the most commonly used components first. That way, all teams were invested in the solution and were able to identify design tokens that would be used in edge cases.
Reflection
Key Outcomes
Integrated and launched a new consumer app using the platform user management system.
Created a user and organization management system with single-sign.
Laid the foundation for a company wide design system.
Limitations & Constraints
Lack of product vision
Use cases and business cases were broad & unclear at first. We made educated guesses on what was needed. We tested and validated internally as we proceeded.
Lack of front-end skills
Dev team mostly composed of backend engineers. Prioritized architecture, accessibility, and flow over visual design.
Time
We needed to launch the platform quickly alongside a beta release.