Intro

At the beginning of the United States' mass administration of vaccines, I joined SpringML as a UX engineer to help deliver software solutions to the public sector in their mission to deliver vaccines. Because of the dire situations that these public sectors were in, products shipped fast and sprints were only 2-3 days long thanks to SpringML's amazing global team. The company stepped up to this daunting challenge and has been recognized as a Google Cloud Public Sector Partner of the Year as a result of its work.

My time with SpringML and on these vaccine projects will shape the rest of my design career. This is in large part due to just how challenging these projects proved to be. I worked with an awesome internal team and our stakeholders were ready and willing to go out of their way to ensure that we were delivering apps that were going to help hundreds of thousands of people. I will forever be grateful for the experiences I had, the lessons I learned, and the folks I had the privilege of working with. That being said, COVID sent all of us on a wild ride.

Team

We were an international team working in opposite time zones. Locally, we had our stakeholders, one TPM, a few data engineers, and a sole designer. Globally, we had an additional 4-7 data engineers. We would perform hand-offs to one another every day at 8 pm and 9 am.

The team structure was consistent across most projects. On all of the projects I worked on, I was always the sole designer. Depending on the TPM's design experience, I could sometimes lean on them for design support.

Scope & Constraints

Timeline

As fast as possible was the motto. There was a time when the government was making more vaccinations than were being administered because of the logistical nightmare of figuring out who was eligible for vaccines and getting them to where they needed to be. For every feature we released, we were lessening the waste of vaccines and increasing the number of people being vaccinated who were demanding them. For the most part, we stood up all 4 apps that I worked on, from scratch, in about 3 months.

CDC Policy Updates

As we all know, dealing with COVID and mass vaccine administration was new for everyone. Guidelines, rules, and laws were constantly changing and presenting us with new challenges to overcome.

Complexity of Features

For the app that I will be discussing the most, the base of the app was a public-facing website where citizens (100s of 1,000s of them) filled out eligibility questionnaires and then entered their contact info. Additionally, there were apps that allowed state officials and providers to send out notifications to eligible citizens about nearby events. The header of this page gives an idea of the complexity of the app as it is the Figma file of the Administrator portal that I spent most of my time on. This complexity was heightened due to the timeline.

Agile Methodology

For our sprints, we had deployments scheduled every Tuesday and Friday. Most days, I worked with our TPM and other engineers to assist with testing the deployed app and collecting requirements from stakeholders. Mainly, I was creating designs for new features and standing them up for the nightly handoff. These handoffs were every night and we would receive updates from them the following morning.

Our planned deployments were sometimes interrupted, delayed, or halted by CDC updates, governor announcements, changes to copy (as a result of the former), and concerns from testers.

The shortest sprints I had previously worked in were all one week long. Doing 2-3 day sprints was something that took some adjustment.

Obstacles

Late Start

When I entered the project, much of the prep work and initial requirements gathering had already been done. In the absence of a designer, they had used logic flow diagrams to understand the interactions of the app. Unfortunately, with how complex the app was, the logic diagrams weren't enough to expose flow issues within the UI that stakeholders were proposing. It was two days before launch when I understood what the stakeholder was asking for versus what they had proposed to the developers via their logic diagrams. The backend at this point was nearing completion and the frontend was halfway done. Because of the number of screens to make, developers wouldn't have seen the problem for another couple of days when they tried to tie it all together. If it had been a minor flow issue, we could have gone forward with the original plan and patched it in future releases. However, I brought my concerns to my TPM with some wireframes to back them up and I was taken seriously enough that we hopped on a call with stakeholders at 7 pm and didn't leave the call until we had a new UI flow to hand off to developers.

In short, account holders couldn't register until they answered questions but they couldn't answer questions until they registered. It sounds obvious, but it was hidden because of another flow that involved adding registrants to an existing account. Additionally, it was all wrapped up in a lot of legal jargon.

Some previously developed screens had to be scrapped or redone but, two days later, the app made it to the weekend UAT. The first deployment was launched on Monday, right on time.

What I learned

• Speak up. To somebody. I didn't have to ring a bell and shout to the whole world that I found a problem that might delay deployment. I simply elevated what I discovered to the right person and then together we were able to pull in stakeholders, address it, and fix it.

• Always create interactive prototypes before sending screens to development - it helps you catch issues with interaction logic that are hard to catch otherwise

• Always, always, ALWAYS at least create static wireframes before sending screens to development - a downside of joining a project late

30+ Sources of Content

The sources

• 20ish Word Docs from the customer (with titles of "Master Copy Edit Doc V.19", "Master Copy Edit Doc V.20", ....)

• Live website

• Screenshots from old versions of the website

• An in-development website

• Wireframes on Figma

• Wireframes on Zepplin

• Screenshots of old, current, and proposed wireframes with annotations from clients

• Tasks in Asana (project management site) that described changes to copy edit

• A copy edit spreadsheet (I stood this up in hopes of centralizing copy)

• 'Tickets' made by the stakeholder to their communication department (the tickets included English copy and the requested languages to be translated).

• Emails about changes in copy

• Verbal discussion about changes in copy

• About 10 stakeholders who had the power to request copy changes

Main issues

• Their translations were costing extra because they would request a translation, copy edit would change and then they'd have to send a new ticket to translations.

• Developers working on opposite time zones didn't always know what the current copy was. The new 'button' text could be on one document but then header text on that same page could be in an email from the stakeholder that they aren't included in. They had to make assumptions and hope for the best in the morning.

• Because it was a government site, we needed extensive approval. From supervisors to lawyers to everyone in between. Using the wrong copy could put our stakeholders in a tough spot

• Testers couldn't properly test if they didn't know which copy to use for comparison.

• Because nobody spoke all 12 languages, it was very easy to put an entire block of text on the wrong screen because nobody could verify what that text said outside of the communication department. This meant that some citizens could have had misleading information that caused them to use the site incorrectly.

• Ultimately, we had a 'chicken or the egg' problem because altered copy edits could change the functionality which could further change more copy which could change the...

There were times where I felt extremely overwhelmed by the copy that surrounded me and worse, as the lead frontend liaison between stakeholders and global developers, it was something that I was continuously at fault for when something went amiss. I used my design skills to improve our process from within.

Solution

I established contact with a couple of key stakeholders. Namely, the woman who sent translations to the comms dept. and the woman who was the final stamp of approval for copy edits. We agreed on the dependencies and sequence that copy-edit was moved around. I created a spreadsheet with roughly 10 columns, repeated on 12 tabs for each language, and populated it with every single line of copy edit I could find (700 rows per language). With buy-in from my team and stakeholders, I laid out a process of who touched copy, when, and where. Developers only referred to Zepplin and the spreadsheet which had tags that corresponded to their code (and which could update a JSON file). The translator kept the spreadsheet up to date. I would add copy edit that I received from word Docs but only after showing the stakeholder how that copy edit was interpreted on the Figma wireframe and she approved. Upon approval, I had to notify the translator by creating a task in Asana for her to review and pass it on to the next person.

The process brought about massive improvements and efficiencies.

Time Zone

One of the first designs I gave to the designers was for a screen with a form that required 12 input fields to be filled by the state admin (one for each language). I designed two of the input fields on the form (English/Spanish) then wrote at the bottom "remaining language form fields here". The developers, relying on this design as their source of truth, deployed the site, verbatim, with only two form fields and the text reading "remaining language form fields here".

Working in opposite time zones was a new experience for me at the time. I quickly learned that my redlining skills were not up to speed. In the past, my redlining had relied on developers being able to ask me questions about the wireframes whenever those questions would arise. In opposite time zones, this is not possible. What is handed off to developers has to contain everything they need as well as predict what they might need.

What I learned

• It's not enough to redline a static page. I also have to redline in a way where developers know how things shrink, grow, or move if the screen changes sizes.

• Lorem Ipsum is not always good. Without the ability to talk to me, every context clue can help. With enough context clues in the content itself, developers were always able to figure things out, but I had to give that information for it to be useful.

• Because I was changing designs as they were developing them, I had to be very explicit about what had changed from the previous day when they were working off a design file. One of my PMs demonstrated a great way to do this. In his project, Zepplin files were uploaded as new files even if there was just one change. The files would have the exact same name except they would have different 'phase' tags. Developers could then see all the changes side by side.

• Try to have a single source of truth. As mentioned previously, there were, at one point, 30 sources of truth. Developers could easily mix up current copy with copy that had been changed days earlier. I made sure that anytime the copy had changed, I circled it in red and would leave a note of what row/column that copy could be found on the spreadsheet

CDC Updates

While this was an intense obstacle in the project, it was mitigated by the stakeholders' preparedness. On day one, they had laid out what they knew and tried their best to outline everywhere that they could foresee changes. Some guesses were easier than others. In multiple places, for example, we left room for a future J&J vaccine. This had quite the impact on our UI because it turned some input fields and filtering options from binary options into multiple options.

Other times, nobody could predict the changes, and this made design really hard. At one point, we were looking at their admin portal and how to implement a content management system so that they could add eligibility criteria in the future. The conversation looked something like this:

Me: How does a nested dropdown sound?

Stakeholder: We don't know, legally, whether the vaccine eligibility conditions will be "or conditions" or "and conditions" so TBD.

Me: No worries, and what if we left it freeform?

Stakeholder: We don't know which healthcare providers the state is going to allow access to this site so... TBD.

...

Me to engineers: Can you start development for all 8 of these possible functionalities since we don't know what the governor will announce tomorrow?

Engineers: No way

Wash. Rinse. Repeat. Every feature and functionality mirrored this conversation in some way. What we ultimately ended up doing for each feature was agreeing with the stakeholders on what we all believed to be the most likely next update. From there, we would begin development. On multiple occasions, days before deploying, the CDC or governor would make an announcement and I would have to redesign entire pages of content in just a day. We were fortunate to not only have understanding stakeholders but stakeholders who also made themselves available to answer these urgent questions. Communication was constant.

What I learned

• Communication will make or break projects

• Stay aligned with stakeholders about pointing our problem solving towards the common problem and not toward each other. Sometimes this means refocusing conversation away from the negative and towards a solution, other times it can mean just listening (like really, really listening).

• Sometimes this work is just plain hard. Not every day is my dream job. I just have to brave the hard stuff and know that it will pass.

Language Barrier

There were many ways that not knowing the 12 languages associated with the application, made design more complex. I am very grateful to our stakeholders for deciding that a vaccine app needed to be navigable by all citizens of their state and not just English speakers. I think it is easy for production apps to count on APIs to translate their site or only accommodate for a couple of commonly spoken languages. Our stakeholders went above and beyond advocating for the implementation of all of their states' used languages and I commend their priorities.

Difficulties

• The available fonts and characters to accommodate the languages weren't always available in design. This created an extra step of communication with the developers to make sure they knew to refer somewhere else for the correct translations.

• Knowing how certain things are justified. Specifically, with Arabic, we knew the copy should be right-aligned but for things like numbers we weren't sure if it was wording-then-numbers or numbers-then-wording. Worse, these weren't usually revealed until we tried to develop the screens and the translator had already finished for the day.

• We weren't sure the ways in which things like italics, underline, or bolding could change the semantics of a word or sentence.

What I learned

• Develop a strong relationship with the right people, early. In this case, it was their communication department. We had to rely on them for all the answers to our translation questions, and remain patient even when the pending answer had big effects on our designs.

• Since there isn't always time to be thorough on everything, I need to gauge what's most important and plan ahead. For example, in one translation, we were worried the content of the questions could vary from "16 and older" to "16 and younger" just based on what we decided. The consequences were too big to be decided on our own so we had to hold off on implementing it, causing delays, until we got answers. Looking back, because I knew we were getting translations for the age-related eligibility questions that week, I could have foreseen the importance of this content. I should have reviewed it with comms before taking it to the developers.

Conclusion

Ironically, while these were the least aesthetically pleasing projects I have worked on, they were by far the most rewarding projects I have worked on. It was more than just the importance of the work though. I have never faced such an onslaught of obstacles in such a short period of time, nor have I ever stood up so many products as quickly as I did.

I'm not sure how many other front-end projects that SpringML will take on in the future, (ML is for machine learning) but I will forever be grateful for the time I spent with them and the lessons that I learned.