Project Brief

As the first and only FDA approved treatment for generalized pustular psoriasis (GPP), SPEVIGO needed to launch a branded website to capture interest, provide GPP diagnosis information, and inform how SPEVIGO can help. As the product becomes more readily available to the general public, this site aims to guide patients and their caregivers along their GPP treatment journey.

Deliverables

Design an 8-10 page product website that acts as a hub for information about the branded product – adhering to the client-developed design system, Global Design System (GDS). The website will be delivered in stages:

• Day 0 At-approval (9/2022): single-page site to inform interested parties that SPEVIGO has been approved, with basic information on what it does and who it’s for

• Day 1 Website (1/2023): full website to provide the GPP patient community with access to information regarding their diagnosis and their SPEVIGO treatment option

• Optimizations (6/2023): additional features and offerings to enhance the patient journey, such as an interactive doctor discussion guide

For each stage, we were tasked to deliver detailed sitemaps and GDS-approved layouts prior to handoff to the client development team.

Audience

SPEVIGO.com aims to provide diagnosis and treatment information to people recently diagnosed or undiagnosed with GPP, and/or their care partners. We are also considering that healthcare professionals (HCPs) may also view the website.

Introduction to GDS

Sitemaps

As with any project, we started by drafting a sitemap of what content needed to exist on both the Day 0 and Day 1 websites, with consideration towards ensuring that the launch transition would remain familiar to users keeping track of the product’s progress.

Diving Into GDS

As one of my colleagues began drafting up an initial layout of what the Day 0 site would look like, I focused on understanding and customizing the Global Design System (GDS) to fit our specific brand. The way the files were set up in Sketch was interesting - by working with three distinct files, I was able to utilize the main library components, adjust for brand typography and theme, and create designs without modifying the components themselves.

My role at this time was to ensure that my colleague’s work converted similarly to GDS components - this is where we first discovered the rigidity of GDS did not meet our design expectations: 

Though we wanted to argue for further flexibility on GDS component usage guidelines, we also recognized that with the Day 1 full site to be further designed, we had to choose our battles by compromising on minor design decisions with the Day 0 site and instead focusing our efforts (and negotiations) on the full site. 

Day 1 Designs

At this point in time, I had become well-versed with GDS’s library organization and component structure and taken over the role of creating layouts. My colleagues were responsible for drafting up copy and creating image assets that would both help further our goal of creating an information hub for patients of this rare disease. 

Working with any well-established design system has its pro’s and con’s:

As I designed the Day 1 site layout, I requested multiple calls per week with the GDS development team. During these calls, we discussed the validity of existing designs, clarified various component usage guidelines, and challenged the rationale behind component inflexibility. I got to understand in more detail how GDS is developed and executed behind-the-scenes, and gained reasonable concessions or exceptions that would allow us to ensure our designs were focused on the users’ information consumption needs:

Design Iteration

Our brief included additional information updates and user interactivity capabilities that were not available at the time of the Day 1 site launch. More specifically, we were tasked with creating an interactive doctor discussion guide that would boost user engagement and allow users to generate a pre-filled PDF to bring to their doctor appointments, as opposed to a static document they would have to print and fill out.

To create and propose new components, we needed to justify its necessity - that current designs could not fulfill the identified need and that it provided value to use cases outside of our specific brand.

For Spevigo, our goal was to encourage action among our audience for a severe and rare disease that is often misdiagnosed - an interactive walk-through of the discussion guide would provide mental guidance towards that goal, helping them get started on the journey towards improving their quality of life.

*Up until this point, collaboration between designers had been difficult; even with Abstract, checking files in/out led to multiple points of confusion due to differing Sketch versions and GDS compatibility. It’s worth noting that by this time, the development team had fully made the transition to Figma; re-learning GDS in Figma and recreating the full file was a fun and educational endeavor!

• Consistency and organization is key - having a cheat sheet on spacing, typography, and responsive component sizes is better than relying on mental memory and risk additional rounds of review

• Multiple rounds of developer verification meant recreating identical and minute design details in a way that changes how it’d be developed; collaborating with developers to understand their process helped me become a better, more efficient designer

• Challenging an established design system to expand on additional components and functionality allows it to accommodate more use cases; even the most well-established design systems can be improved on