My role in a nutshell
Design system audit and setting up an iterative design system process for the whole team
Internal stakeholder research distilled into a Service Design Blueprint
DesignOps, as in aligning all the different branding materials produced across the organisation
A few words about Clariness
Clariness is a company based in Berlin, specialising in Patient Recruitment for clinical trials. After signing a contract with a sponsor (usually a Pharma company), Clariness is assigned to find a number of patients, eligible and willing to participate in a clinical trial. From the patient’s side, the process runs like this: A patient, who suffers from e.g. asthma, sees an ad for an asthma clinical trial leading to an online screener. Once the patient is found eligible for a study, he is either called by Clariness call center to verify eligibility or he is forwarded directly to the hospital where a set of examinations are conducted. The process might include more or less steps, depending on the contract signed between the sponsor and Clariness. The patient can at any point step out or they can continue until signing up. In addition, Clariness provides consulting to sponsors regarding the feasibility of the study and other success factors, based on their 16-year long experience with clinical trials on a global level.
Because of the above, Clariness serves 3 main actors in different ways: the Sponsors, the investigators who work at the hospitals included in the study (called Site employees) and the patients themselves (sometimes also the patient’s carers, eg. in case of a study for minors).
3 types of tickets and 2 Development teams can create quite a bit of Complexity! :) Click on the image to enlarge it.
Product Archaelogy & Design System Work @Clariness
We joined Clariness during a reorganisation phase for the company: new hires had come in, among which the Head of Product Engineering (my manager), a few had left and the company was preparing the ground for a more efficient handling of their processes and their product development. We were hired to assist with the merging of two separate products and to set the basis for a better and more consistent User Experience.
Our first task was—what I would call— Product Archaeology. We had to dust off the beginnings of a design system, initiated by a designer who left, and bring it to life, build processes around it and make sure it increased the efficiency of the developers. We tackled this by evaluating the existing components in Figma and deciding which stays and which goes. Where each component was used? Were they well designed? Were they based on a system (atomic design)? Could the same components be used across all platforms of the company, both the patient and the B2B facing?
Moreover, we studied the existing interfaces and debated what kind of change we wanted to achieve on the UI: were we aiming for a big change right away or should we follow the existing patterns until the design system is in place and then improve it? We went for the first option, the gradual change, and started building.
After taking the input from several developers, I put in place a Design System process (from requesting a component/component update to releasing it) that included Confluence, Jira, Gitlab, Figma and Storybook that can be seen above and was put in action right away.
The Service Design Blueprint was produced 2x, to showcase the similarities and differences of two different services of Clariness, a premium one and a “regular” and included additionally the patient’s journey and a real case from our marketing funnel, showing how many prospects drop out in each step.
Internal Stakeholder Research & Service Design Blueprint
Early on, we had discovered that we can’t move further on with design before answering some key questions regarding the product and its different types of end-users. Why do user group A uses a specific software to for an X purpose? How does this process, handled by a remote dept in Clariness works in detail? What are the needs/requirements of our colleagues that talk with our end-users? Which features do we need that we don’t have yet and which are obsolete and shall be abandoned?
With many new hires, a new Head of Product Engineering, remote collaboration and a breadth of expertise in the company (medical, legal, funnel marketing, call centers and engineers) there were a lot of knowledge gaps to be covered. Many of the answers to the above questions were to be found inside the company. I proposed a research plan that included interviews with internal stakeholders. The interviews were focused on (1) interviewees’ insights on each target group (2) how they contributed to the Recruitment service and how they collaborated with other depts. (3) which softwares they used (4) drawbacks of these softwares (5) their outlook on existing processes and improvement areas. The interviews were recorded, transcribed in detail and distilled into affinity maps, executive summaries and actionable steps for the product team, maintained in Confluence.
In addition, we took a visual approach and while the interviews were ongoing, we started creating a Service Design Blueprint that included:
our assumptions about the Patient Journey, including feelings, decision moments and a rough description of the attitude of the prospects
the marketing funnel (with numbers), from the amount of prospects noticing an ad, proceeding to the online screening and then agreeing to phone screening, etc. up to the number of people signing up for a trial
the Clariness process: how each employee and each platform is involved, both front stage (user facing actions) and backstage (technical processes that support the front stage actions but are invisible to the users).
The diagrams, along with the insights from the interviews were presented to the whole Product Development Team, communicated through the company’s newsletter and used for strategy workshops, for example for deciding where in our platforms should we gather feedback from the users.