For this project, I worked with a product owner, several analysts, and developers to redesign obstetrics/gynecology (OB/GYN) nurse staffing software.

Initially, I was tasked with providing guidance on making the user interface of existing OB/GYN software "more user friendly." However, after stakeholder interviews, contextual inquiry, and preliminary usability tests of the existing software, it became apparent that the existing software was not meeting our users' needs.

Through a process of stakeholder interviews, contextual inquiry, affinity diagramming and collaborative design, I was able to guide the foundational research for this project so that we could quickly discover and define our user's needs and frustrations. This allowed our team to rapidly move into a design/iteration phase of the project.

Using a series of paper prototypes and interactive mock-ups we conducted usability tests and refined many different design ideas and patterns over a month and a half. We continued this iterative agile process as portions of the software were released, adding further refinement to our designs and reducing the anticipated development time from nine months to four months.

In addition to reducing development time, this agile UX research and design process provided a much stronger product which exceeded the expectations of our client.

The following details this process.

Photo credit: Katie-Kate. Flickr

The software which my company assigned me to improve had been in place at several major hospital OB/GYN departments for over five years. It was intended to help nurses, midwives, and hospital administrators anticipate patient demand in their obstetrics and gynecology departments so that they could provide appropriate staffing.

However, I soon discovered that in the time the software had been in place there had not been any follow-up for monitoring its use and user reaction.

This led me to pull the program's use logs, which showed the frequency of page visits. In addition, I asked one of our analysts to map out a usage map detailing page hit frequency and the paths users took after visiting each page. The results were shocking, and showed that the program was hardly used at all and that only four out of the fifty pages in the program were used with any frequency.

This indicated to me that there was potentially substantial bloat in the software and that it was either not serving our users' needs, was not designed in a way that facilitated the tasks they needed to perform, or suffered from combination of these two factors.

With this in mind, I started to work with the product owner to define key stakeholders. The product owner had been working with the intended users for a number of years, which allowed him to quickly identify some of our primary stakeholders.

After the product owner had defined these key stakeholders, we conducted a series of semi-structured interviews with questions related to the tasks the software was intended to facilitate. We also asked users their experiences with the software and general questions related to the digital ecosystem in which the software was placed.

Photo credit: Will Murphy. Flickr

At this point, it became apparent that the software needed more than a simple redesign, so I presented the product owner with a timeline showing a series of potential UX research techniques I could use to define the needs of users and refine/redesign our product.

The product owner had not been exposed to these UX techniques before, so I provided a description of the techniques over the course of several PowerPoint sessions. I included time estimates and employee work demand in these descriptions to assist in his planning.

Due to an aggressive timeline and few human resources, the product owner opted to incorporate half of the UX techniques suggested on this timeline.

Due to his experience working with user groups, the product owner was the best positioned to provide input for working personas.

After explaining the general structure for a persona, I worked with him to guide the creation of several distinct primary and secondary personas, outlining the goals, needs, and frustrations of each user group.

These personas were later augmented and refined with additional information from interviews and contextual inquiries as the project progressed.

We used our personas to focus our design process and create empathy among our team for our users. This was especially important because we worked in a distributed team with geographically separated user groups across the United States. This meant that while the product owner and I regularly interacted with our users, the developers and analysts were separated from them by thousands of miles, making our design artifacts crucial in building their understanding.

Over the course of several weeks, the product owner and I conducted a series of Contextual Inquiries, during which we took detailed notes. After a day of Contextual Inquiries, we would debrief and collect the most important concepts and quotes on Post-It notes, which we spread across a wall of our office.

In the downtime between our other work, we would move the Post-Its around into similar groupings, until after weeks of organizing, and reorganizing, native groupings started to emerge. We then arranged these into super groupings, and these super groups into larger groups.

The Affinity Wall which emerged showed us some of the key frustrations and needs for our tool and became another critical artifact for building empathy for our users.

Many of the elements in this Affinity Wall were also fed back into our working personas for further refinement.

An example of one of the Sequence Maps, which were produced during our Contextual Inquiry.

Concurrent with our Contextual Inquiry, I began to sketch out the foundation of what would become the Journey Maps for this project.

Journey Maps are a way to condense a large amount of quantitative data into a touch-point ecosystem. They help designers and developers understand what it's like to "walk a mile in their user's shoes" and see the touch-points where difficulties occur.

Having a general approximation of what a user is thinking and feeling during activities, and the touch-points where this occurs, allows designers to modify or remove touch-points which are causing negative experiences, or create an entirely different experiences altogether.

This is one of the completed Journey Maps for the project. The Journey Maps were focused on the personas we had created and embodied the experiences of individuals approximated by them.

The experiences of real users were brought together for these maps by analyzing the detailed notes from our user interviews and Contextual Inquiries. Through these maps, I laid out the thoughts and emotions of the users at different touch-points.

The Journey Maps were immensely helpful because they showed us where our software was failing, and negative touch-points which could be eliminated by modifying how our software operated (such as transcribing data from paper records or pulling data from multiple records).

I led several internal collaborative sessions with our development and analyst team and two external collaborative design sessions.

Using the output from these sessions, the product owner and I then narrowed our design choices using the personas and journey maps we had created as guides.

The most promising design ideas were then mocked up in Balsamiq and printed out for paper prototype testing.

This allowed us to go through multiple rapid iterations of many different ideas before a line of code was written.

We then conducted usability tests these prototypes and refined our designs.

Above are two different design ideas for the same screen.

I then assisted the product owner in Story Mapping some of the functional elements needed for the product before development began. This included organizing the story map by persona and performing an early prioritization of the backlog based on the highest value elements for our users.

As our product moved into the development phase, I continued to conduct usability tests on functional elements of software as they were completed in Agile sprints. This is an excerpt of a usability session script.

The task analysis in our usability tests were relatively broad and general in their categorical distinction ("completed," "completed with difficulty," etc.), because we were attempting to refine large functional elements. Here, some of the qualitative elements from multiple usability tests are summarized.

During development, I participated in story writing sessions, often working with the team to sketch out and refine ideas on our white board.

I also worked with our product owner to groom our backlog of stories in Jira. Together, we prioritized functional elements that went together so that I could test them with users incrementally.

We were able to deliver the final release of our OB/GYN software four months ahead of schedule by front-loading our user research, and relying on an iterative Agile approach.

In addition, the software not only met, but exceeded our client's expectations.