Over the years I’ve worked on a wide variety of products with many different methodologies, and I’ve been in a remote-ish SCRUM environment working on an EHR for the last 2 years. Please check out the following work samples to learn more.
Mini case studies
These brief examples give an overview of my experience.
Refactoring language selection
As part of a standardization effort at Iora, my SCRUM team needed to refactor the process for choosing a patient’s preferred language in the web-based EHR. The existing field was free text and contained valuable data, some of which had more to do with how a patient communicated than the language they knew, such as whether they needed a translator.
I worked with the product manager to analyze a report on the data in the current field and identify the most common languages. Then we devised a solution with the development team that leaned on existing patterns to show common selections first, then allow the user to search for other options. We retained the existing field underneath the new one, so that users could refer to it as they updated data in the new field. We piloted the feature briefly before wide release. Much of my work at Iora came in similarly sized chunks, which was an adjustment at first.
Mobile support for building delivery management
A supplier for large prefabricated buildings hired my team to design a mobile manifest app in Xamarin forms. After conducting contextual inquiry and interviews at a job site, I prepared some recommendations in addition to the app that would better address customer complaints about the delivery process. The client declined to move forward with the new recommendations, so as the project lead and sole designer, I designed and delivered mobile wireframes in Invision with a separate annotation document.
To (mostly) satisfy Google’s Material Design and Apple’s Human Interface Guidelines in a single design, I made a cross-platform study of both systems and did my best to match it with the templates available in Xamarin forms. I relied on a good deal of mentorship and feedback from a more experienced mobile designer. With the final deliverables, I provided a guide for how to conduct usability testing as well, after helping the client understand why focus groups were not a good vehicle for usability feedback.
After the project, my mobile mentor and I made a presentation to share learnings with the whole UX team.
Empowering special education teachers with data management and visualization
A startup client brought an existing SAAS system whose original developer had overpromised and underdelivered. In a previous project, my team’s development lead had recommended we start over from scratch. An initial set of visioning and roadmapping workshops I conducted with the client led to an MVP design and development engagement. The responsive, web-based system needed to collect and model special education data, to support teachers as they helped students work toward their goals.
As project lead, I brought on a second designer and mentee to aid with research and definition. After interviews with special education teachers, we sifted through notes to identify a common workflow. Then I worked closely with the development lead to carve out the MVP scope and design a prototype. After two rounds of usability testing and iteration with special education teachers, I was able to gain and implement crucial feedback that transformed the product. We broke down barriers inherent in the existing paper system to define a new standard for data integrity in special education. This was one of my earlier UX projects, and though I was an experienced usability tester, I was still astounded by what we learned in that first round of feedback and how it changed things.
Planning a company-wide research program
When I arrived at Iora, there was no standard process for recruiting research participants. This caused frustration for everyone. Product owners and designers had a hard time identifying participants and ended up returning to the same set of folks over and over. Care team managers and team members found it alternately overwhelming or felt left out. In my design time (30% of each week that I could devote to a project of my choosing) I decided to begin tackling a research program with one of the service designers. The first step was to define a recruiting process for specific needs. Then we planned to develop a process for regular, ongoing research outside of projects, as well as a research repository and training opportunities. For various reasons, the project was cut short, but I learned a lot about the needs and pitfalls of devising such a program.
Bringing audio system design into the future
In my second project with an international commercial and home audio manufacturer, I was tasked with the greenfield redesign of an existing application. The program allowed audio engineers to design sound systems for commercial applications—stadiums, airports, concert venues, etc. The original software had been in development since the 1990s and only supported 2D venue modeling; the new one needed support for 3D. As lead, I brought a second designer onto the project to help untangle what promised to be a complex problem space in a native Windows application.
We began by reviewing a massive requirements document the client had created with their third-party development partner. I pushed early on for as much contact with the developer as possible to get input and establish communication. My colleague and I reviewed competitors and conducted contextual inquiry at a few local venues, to see the existing application at work. We spent the bulk of our time sketching on whiteboards, only moving to Sketch when things started to feel workable and whole. Before delivering final designs, we were able to get two rounds of usability feedback and iteration from audio engineers and implement changes. This project solidified my love for messy IA problems in enterprise software.
Meaty case studies
These examples have more detailed case studies available, password protected due to client agreements. Please email me for access.
Detangling medical billing codes
This endeavor began as a small refactoring task, then blew up over the course of my time at Iora into a problem that impacted the business from several perspectives. This spicy problem space involved mapping medical billing codes to the provider’s clinical mindset and solving for multiple instances of conflicting information and double documentation. Through research and poking at the problem from different angles as I switched SCRUM teams, I began to visualize a single data model to unite codes with clinical conditions and eliminate confusion. Through this effort I began to see myself working in two parallel streams: the immediate, incremental experiments/changes and big picture visioning.
Reimagining retail information management
I joined this enterprise product team after the first release to lead a SCRUM workstream defining how retail item data is managed. Our goal was to protect against errors that could impact retail from start to finish. In this role I worked closely with the product owner and architect to understand the background and chew through iterations on information architecture. Without access to users, the product owner and I leaned on POs in other workstreams who had direct experience working in the field. This experience sparked my interest in complex internal tools and was my first true SCRUM team role.
Helping homeowners choose paint colors
The client hired my team to redesign and scale up a service that could transform the way homeowners choose paint colors. Our award-winning designs started with a creative and lean approach to research. A guerrilla research process carried us through the design and development of 3 MVP products in a few short months. I learned a lot about designing lean research approaches and sunk my teeth into A/B testing, microinteractions, and keyboard navigation.
Blogs and presentations
These examples give insight into how I contribute to professional development and company culture.
Spend failure wisely
This blog post at Intensive Code Unit is about developing a common language for evaluating risk as a team. By understanding types of failure, teams can move from debating whether failure will occur to taking advantage of it.
Building a culture of critique
At Iora, I presented the second iteration of a talk about how to develop a critique mindset and build essential skills for both offering and receiving feedback.