I'm Andrew Lilja, a user researcher in Minneapolis.

I work at Gomoll Research and Design, where I've done projects for Medtronic, Bio-Rad, Modern Hire, and others. You can email me at .

Recent Work

Unfortunately, all of my recent work is currently under NDA. I can provide specific details on request.

Since 2015, I’ve been working in medical devices. This highly regulated industry involves a broad range of skills and activities for UX professionals from user interviews and research to all steps of the design process to communication with internal and external groups. Because medical devices are a highly regulated industry, every step in the process is documented — any decision made without evidence is heavily scrutinized and may result in the regulatory bodies rejecting your product. All data must be recorded, all choices documented, and all UI designs rationalized.

Modern medical devices are incredibly powerful and complex — a pacemaker can tell the difference between a dangerous heart rate and the normal change in rate associated with exercise and respond accordingly, for example — and as a result no single person or team can be wholly responsible for developing one. Collaboration between groups within an organization is essential, and sometimes this means that groups with clear business cases — like software development — can get more recognition than the UX teams. Advocating for design and demonstrating its importance early in the development process is a critical responsibility for a human factors practitioner.

An essential part of the design process is testing to ensure that the tools built are not only effective and easy to use, but easy to use safely and hard to cause harm with. This is done in two phases: first, the formative process, where the initial design is created, tested, and iterated on; second, the summative, where you do rigorous testing to demonstrate to a regulatory body (like the FDA in the USA or TUV in Europe) that your design is safe and all potential sources of harm have been minimized as much as possible.

I like to think of the two processes as building what users need and proving you made it safe. I have been extensively involved in both.

A large medical device manufacturer needed to replace an aging fleet of clinician-operated tools used to program lifesaving implantable devices. The existing tool was no longer being manufactured, and the company wanted to move away from custom-made hardware towards more flexible, off-the-shelf devices like the iPad. The new programmer needed to work with all currently implanted devices, and be future-proofed to work with new devices with an unknown range of features and improvements.

I was brought onboard after the initial version was completed. My job was to develop, execute, and document the summative testing studies needed to prove to the FDA that the new programmer was a safe and effective replacement. The timeline for the project was highly accelerated, with six studies in 15 months.

Designing a summative study is challenging in both its rigor and its breadth. Features that have been defined as safety-critical need to be thoroughly tested in environments that are as close to real-world settings as possible. Poorly designed tasks can lead to bad data, an FDA rejection, and a development timeline set back by six months or more.

The first thing I needed to do with each study was understand what features I was using. Without knowing how a feature worked, what it was used for, and what could commonly go wrong with it, I wouldn’t be capable of writing an effective task that actually measured a user’s ability to safely and correctly use that feature. I reached out to existing users of a range of skill levels to get a baseline understanding of how it was being used in the field1 and used that information to begin developing a protocol.

Each task required a unique, carefully-described success criteria. In order to work with as many users as we needed, studies were often carried out by multiple moderators at a time. This meant that the protocols had to be clear and usable by someone without my level of knowledge, and critically, that the moderator could correctly assess whether or not a user had correctly performed the task. This meant identifying what the intended outcome of a task should be and describing what it meant to accomplish that task safely — if the user had the right result but did it in an unsafe way, that was a failure of the task.

After each study had concluded, the data needed to be analyzed and summarized into two forms: one in an official document submitted to the FDA, and one for internal usage about any usability or safety issues that needed to be fixed. In order to meet development timelines, I needed to analyze and summarize data from 30 to 45 participants in order to develop design recommendations. Sometimes, the turnaround on this process was as short as a week.

The results of our studies were submitted to the FDA in phases, ensuring that if there were any rejections, the entire product would not have to be re-tested. All parts of the submissions I worked on were approved without issues or requests from the FDA. In early 2019, the new tool was competely approved for usage, sixth months ahead of schedule. That same year, I worked on formative studies preparing for the next round of validation testing to take place in 2020.

  1. As we would learn, there could be a large gap between how a feature was used in the field and how it was supposed to be used. 

A medical robotics start-up approached Gomoll Research and Design about developing their next-generation cancer treatment system user interfaces. I worked with a small team of Gomoll coworkers to translate existing wireframes and UI concepts into high-fidelity, interactive prototpes in Axure1. Though the design and most of the interactions were already defined, I was responsible for ensuring that the prototypes worked correctly and robustly, identifying any issues in interaction design, and deploying them for formative testing.

The client was eager to make changes as testing went along, and occasionally I would be responsible for making changes to the prototype in the evening before one session, or even between morning and afternoon test sessions. This kind of short-term work required constant collaboration in the Gomoll team to make sure we were all on the same page and making the right choices.

The studies were executed through the latter half of 2019, and the product is expected to be released in 2020.

  1. An incredibly powerful and generally underloved prototyping tool. 

A large medical device manufacturer purchased a smaller company and wanted to incorporate their product line into their new software and hardware platform. This involved taking existing software running on very old hardware and updating it for a modern touchscreen interface. In order to do this correctly, we needed to understand the current limitations and problems and how well the old software solved them. As we learned more about what works and what does not, we updated our designs to better serve the end user’s needs.

In 2019, I ran a number of formative studies for fact-finding and prototype testing, presented the results to the larger project team, designed UI prototypes, and worked with the development and systems teams to work within organizational constraints to successfully integrate the product into the existing platform.

A therapy is useless if the patient can’t use it — and despite this, many medical manuals are complex and hard to understand. User populations have a wide range of proficiency and knowledge with computers, so documentation must be clear and concise with little room for misinterpretation — what counts as a small change for one patient may be catastrophic for another.

In 2017, I was brought into an existing rewrite of two medical device manuals, one for the clinician’s usage that described implantation and initial setup, and one for the user that described how the system worked and how to use it safely and effectively.

In 2015, I was brought onboard at a large medical device company to help them design their next-generation therapy controller used by patients. The company was replacing their outdated, custom hardware with off-the-shelf touchscreen devices, and needed all the functionality of their existing controller ported to their new touchscreen application.

The nature of the patient population required specialized design considerations to make up for physical and cognitive limitations. I designed and executed seven studies that took place in the United States and Europe, meeting with more than fifty patients over the course of two years. The studies were casual but rigorous — I wanted to see the prototypes being used to find any problems, as well as listen to what users needed and what they liked or disliked. Success metrics could range from a simple task completion to something more complex like knowledge of a system state and how to use that information to make a correct decision.

After each study, my fellow UX teammates and I worked with the systems and software developers to figure out the best solution to our patients’ problems and what the right user interface would look like. I wrote presentations for the core development team to communicate general trends as well as specific results that were important to our users. These presentations were given to a cross-disciplinary core team. It was important that everyone working on the project understood not only what our users needed, but why so we could make good, user-focused choices together. This approach meant that when problems arose with proposed designs, the team could collaborate to find new solutions that met all the stakeholder’s needs. This collaborative approach led to a constantly-evolving application that met the user’s needs and worked within our own development constraints.

UI designs began as wireframes and shifted into high-fidelity prototypes as key features were nailed down. Paper prototypes, click-through PDFs, InVision prototypes, affinity diagrams, and ranked choices were some of the methods I used to understand our users’ mental models of the system and where the problems in our designs were.

My contract was completed at the end of the formative research studies, and I handed the project off to another UX engineer responsible for assembling documents for submission to the FDA. In mid-2019, the project was approved for use.

Older Work »