In, 2016 I worked with life sciences enterprise product when I was working with YUJ Designs. I led the UX team to work on the first MVP of the product. Fast forward to 2018, this products gets acquired by Deloitte, and I have been asked to build and lead team for the future releases.
I have been working on this product from past few years and there are few other things in pipeline to view other related work with regards to this product. Click on the following links.
(To comply with my non-disclosure agreement, I have omitted and obfuscated confidential information in this case study. All information in this case study is my own and does not necessarily reflect the views of client or product.)
Since I worked on the MVP in 2016 a lot has changed in the platform. We started with a solid foundational roles and tasks while evolved into more complex and powerful features. The platform could handle project/system level validation efficiently.
The platform was powerful tool for handling individual system validation, documentation, testing, version controlling and auditing. Though lacked the capability of scaling up when you consider hundreds of projects spread across countries and regions.
Responsible for end to end delivery of design. I closely worked with clients, multiple stakeholders to define overall product strategy and feature road-map. I was involved in creating concepts, interaction design and visual design.
Later half of the project I worked with development lead to understand and resolve technical constraints.
Helped developed first DesignOps model and Design system for the product.
We started with the design workshop with end users, leadership, SMEs, validation team, product owners, development team, project managers and end users.
The goal was to understand the vision and need for the strategic layer. I was surprised to see the amount of non-standard practices among different project owners and quality teams.
We looked at hundreds of scenarios and use cases which had painful and frustrating experiences. We understood in-spite of the best intentions the regulatory and compliance rules are being violated. We looked at the inefficiency between teams and process.
Even though we had multiple teams and stakeholders involved in design workshop, it did not solve our problem. The good thing was that we got clear picture of the task ahead in terms of 30,000 feet view.
Though, we needed to translate that vision into actionable insights. Every validation team, every life sciences organization follows the SDLC (Software Development Life Cycle), but every team, every region and project will go through different workflow and journey in achieving that.
As we wanted to build an universal platform which can cater to every use case and every possible scenario while doing computer system validation. Although it was not an easy task, we kept on finding variations in processes and frameworks.
Most the applications has two layers / User interfaces. For example : Uber will have driver side app and rider side app. Although the our solution (application) was far more complex system than that. It has two primary layers applications configuration or system administration and Project side.
Each of the below mentioned roles will have different User interface (UI)/ Each of these interfaces are highly interconnected in terms of workflows module and entities.
What strategic layer users needed more control the project/system layer. They wanted to bring standardization amount projects and people so they can measure effectively.
Example: E-Sign ON, Mandatory Workflow etc.
Each entity within the ecosystem will go through series of series of reviews and approvals/rejections. Based on the project type, category and severity the workflows are defined. The quality managers executing these workflows should not have permission to change it.
Project require multiple entity forms to capture the details. Although each region and process area will have different fields. Managing, updating and communicating these changes was big challenge for process owners.
Compliance is all about deliverables, the authors needs to fill out long, tedious documents repeatedly with little change it. It takes too much toll on productivity.
We learned based on the process areas the roles and their definitions changes even within single organization.The role titles and what each user can and can not do is sometimes determined at process area/department layer.
We realized there were too many configurations, controls and scenarios we needed to design for. If we organically design independent feature for each configuration, it would look like some over complicated admin layer of server configuration.
Our end users are process owners and C-level business owners who run serious businesses. They manage large global teams of thousands and generate revenues in millions. If we are going to build a platform, it has to be simple, require less effort to control and provide holistic view of their businesses and quality.
To solve this issues, we took all configurations into a bucket call process packages. These packages are assigned to individual process owners and business owners. Business owners can go to their individual packages to configure forms, workflows, roles & permissions and much more.
The primary goal of the process packages is to drive behaviors of systems/projects below at system/project level. These behaviors are controlled and managed by set of tools at package level.
These tools (Master controls, Forms, Workflows, templates and role permissions) will help business owners streamline processes within organizations.
For example: Once package has “e-Signature” functionality turned ON. All the systems/projects using that package will have mandatory “e-signature” requirement every time someone is trying to approve/reject an entity.
There are many more task flows and signature journeys process owners can perform, which are more complex in nature.
To make this case study less cumbersome and readable i have committed many details and task flows here.
We worked with users to figure out the best way to group the features/tasks and workflows. We looked at various parameters like mental models, frequency and sequence of use, connection with other objects and entities and context. We tried various frameworks for grouping and selected OBJECT BASED INFORMATION ARCHITECTURE.
We worked with users to figure out the best way to group the features/tasks and workflows. We looked at various parameters like mental models, frequency and sequence of use, connection with other objects and entities and context. We tried various frameworks for grouping and selected OBJECT BASED INFORMATION ARCHITECTURE.
This is was Release 2.0 for the product. Learn about how we helped design and build first release back in 2016.
View Case Study for Release 1.0I am currently working on the building “Design System” for above product. Get a sneak peak into the work.
How we build first Design system for our teamAs mentioned earlier we faced many challenges while building a product team from scratch where our processes and frameworks were not robust. Currently I am working towards building Design Ops model for our product team.
DesignOps Model ** Coming Soon