Summary

With an emphasis on generative user research and collaborative design techniques, designed a task list system (think, Todoist, Asana, etc.) inside a SAAS claims processing tool. Served as the sole designer responsible for research and UI / UX design. Timeline: 1.5 months

Methods & Techniques

Assumption declaration, hypothesis creation, survey, focus groups, user interviews, wireframing, prototyping, first click testing

---

The Problem to be Solved

Discussions with claims adjusters (our target users) over the course of building v1 of the BriteClaims system revealed that one of the most important things for them to do their job effectively is the ability to keep track of the different tasks they needed to complete to work on the insurance claims their customers would submit.

Incorporating task tracking functionality directly into the BriteClaims system would empower our users to do their jobs more efficiently and with less error.

Assumption Declaration

To kick off the project, I got our product team (consisting of product owner, engineers and designer -me) together to do an assumption declaration session. This helped our team move forward on the same page about the definition of our fledgling feature and gave us a baseline of ideas to validate with users.

Hypothesis Creation

Once all our assumptions were declared, we collaboratively distilled those assumptions into a hypothesis statement.

After using stickies on Miro to collaborate on the hypothesis creation, our hypothesis was distilled into:

We believe claims adjusters need a way to track tasks so that they can ensure proper protocol has been followed and claims get closed

To support this need, we will build task tracking functionality into the claims system with features like:
- The ability to add tasks
- A filterable list of tasks

We will know this hypothesis is correct if end users workflow is enhanced by this feature and made more efficient and less error prone

Survey

With hypothesis in hand, we wanted to validate these ideas with users.

We sent out a survey to target users with a focus on laying out the assumptions we had declared collaboratively and seeing if users agreed that those were things they were interested in seeing in a future task management feature or not.

This survey gave us a view into which of our assumed functionality would be most important to potential users (Due dates, tagging tasks, task priority) which would be extremely helpful for me in knowing what to prioritize when moving into the design phase.

Interviews

While collecting survey responses we were simultaneously conducting user interviews. With the interviews, we were focused on understanding how users currently tracked the tasks associated with their work, what pain points they were experiencing and what they desired out of a future task tracking solution.

From these interviews, we had a handful of participants mention how helpful it would be to have a calendar integrated into a future task solution. This would inform a large focus of how we would end up designing the feature.

"I'd like to be able select a task on my calendar and drill down directly into the claim." 

"I want a task list with a calendar to live entirely in the claims sytem. If it overlaps with my Outlook / Gmail, then that's ok, but mostly I want it in the claims system." 

Wireframing

When beginning wireframing, I invited the product owner and engineers into some collaborative wireframing sessions. These sessions were great because they allowed us as a team to continue building shared understanding on how we wanted to build this feature.

A technique I used for these sessions was to encourage my team to use screenshots of other tools / software to build out their rough wireframes for what our tasks feature could be. For example, in the screenshot below a team member was playing with the idea of having a task list alongside a calendar so they just screenshotted Google Calendar and put it alongside another roughed out task list.

Prototyping

After going back and forth on some wireframes for a while, we got our ideas to a point where we were ready to polish them and start looking into how some interactions might work with our tasks feature.

I used Figma to build out some higher fidelity mockups for how this feature could operate as well as using Figma’s built in prototyping tools to illustrate how the software should interact and behave.

You can see this prototype for yourself here.

Our final design for the tasks feature was made up of three main parts:

• Search bar / header
• Task list
• Filter menu

The task feature itself lives inside a right sidebar that slides over to reveal itself when the tasks icon is clicked. This allowed the tasks function to be accessible anywhere inside a claim file without the user having to lose context of where they were when accessing the tasks list.

Evaluation

Our final phase before feeling ready to start developing our design into live software was to evaluate the polished designs with our end users. For this, we took our design back to our focus group and gave each participant a link to the prototype and asked them some questions about it’s design and if it included all the elements needed to allow them to successfully track their tasks.

Following this we had some tweaks that needed to be made. we reworked our calendar component to be more focused on ranges of dates as opposed to a calendar and also were able to clarify some logic around the completion and cloning of a task.

We also prepped a first click test which was sent out to the same audience as our initial survey to further evaluate the usability and discoverability of the design we created. In one of our first click tasks with users, we asked them to click where they believed would complete an open task. We had ~30% of our users click on the batch selection item, which led us to incorporating a batch completion feature into the design that wasn’t there initially.

Following these evaluations, our team felt ready to start building out our first development version of this feature. I wrote up the stories needed to support its development and put it into our backlog.

Results

Following our design process we had:

• Strong shared understanding across a product team on what we assumed an integrated task tracking functionality needed to be.
• A testable hypothesis to deliver functionality against.
• Validation of our hypothesis from direct conversations and data collected from users.
• A prototype that had been evaluated by users for usability.
• Stories written for development to build the feature.

Summary

Using user interviews to guide direction, designed a robust and reusable eCommerce template for high fashion eCommerce clients.

Methods & Techniques

User interviews, prototyping, usability testing

Continue reading “Case Study: High Fashion eCommerce” →

Summary

Did a full site design and branding refresh for an addiction services center

Methods & Techniques

User story mapping, wireframing, prototyping, logo and asset design

The Problem to be Solved

eXclusive Services provides a handful of vital services to those struggling with addiction in the Cincinnati area. They are also the only group in the Cinci area providing primary care medical services alongside addiction services. The eXs team was wonderful and when they cited their need for a UI/UX designer, I was happy to jump headfirst into helping them build a solution. eXs needed a new, modern website to help communicate the services they offered to their potential clients.

The site would need to be easy to update as the eXs team had no easy way to update their old site in its current state.

The eXs team was also looking to update some of their branding to be more versatile.

Solution

The solution we landed on was to create the eXs team a new WordPress site. WordPress would afford us the flexibility to quickly design and develop a solution that was powerful enough to encompass the full scope of the new site we were designing but also give the eXs team a simplistic CMS to make any changes to the site going forward.

Limitations

Building a full site in a weekend certainly creates a challenge. Every second is vital when running on such a tight timeframe. Our small team size, while advantageous for shared understanding, also required our skill sets to be stretched to create the needed solution.

Team

Having such a delightful and talented team made the pressure of delivering a great solution in the timeframe of a weekend not only possible, but a lot of fun too.

Mac (Myself) – Design

Beverly & Suraj – Developers

Markku – Project Manager

Lakshmi, Erin & Ron – Forms & Additional Dev

Tracy & Sean – eXs Team

Activities Responsible

Getting a whole site off of the ground in the span of a weekend gives an excellent opportunity as a designer to build upon a variety of skills.

My first role as a designer on the project was to work with the eXs team and Markku, the project manager, on understanding the scope of what we were building. The eXs team came to SWOGC prepared and with already validated assumptions of their user base’s needs which helped us quickly get an idea of what exactly we would need to build and (more importantly) what we could put aside and not spend time building. This involved drawing out rough sketches of UI possibilities and charting out a site map.

After turning our story mapping session into a Scrum board, my next task consisted of creating rough wireframes of each view we were looking for. I took these wireframes and turned them into a clickable prototype using Marvel which allowed our team to get a really solid visualization of the solution and get fully aligned before we even wrote a line of code. These wireframes would continue to be tweaked as we revised our solution.

As our developers began working on setting up the backend of the site, I began working with the eXs team on developing some new branding for the site. I am not a logo designer, but I have an eye for consistency and decided to spin up a very simple text based logo using Roboto Slab from Google Fonts. Add in a couple of lines on top and bottom of the text and you’ve got yourself a versatile logo system.

We also determined the site would use the Roboto Slab font for headers and Open Sans for body text. Nothing beats a FREE serif / sans-serif font pairing right? After we grabbed some colors that the eXs team had already been using, we felt we had a solid branding put together. I then pivoted back into working on translating our wireframes into high fidelity mockups.

I built our high fidelity mockups directly on top of the wireframes that had already been made. This allowed me to update our clickable prototype on Marvel in real time. This was my first time using Marvel as prototyping tool and it won’t be the last. I love the snappiness and speed of Marvel’s editor and it’s Sketch plugin works wonderfully.

With high fidelity mockups in hand, the developers went to work coding them into reality. Some difficulties here were encountered in battling our selected WordPress theme, but with all hands on deck testing the site as it came together our team was able to quickly and efficiently tackle bugs and fixes. Getting a refresher on the joys and terrors of WordPress development is always fun.

We also worked with the eXs team to find content to fill the site. The eXs team is working to get a photographer into their facility to get some personalized content onto the site. But until then, we decided upon some great, royalty free stock photography. Thanks Pexels!

With the final hours of our weekend long race to the finish, we squashed bugs, optimized for speed and tested, tested, tested.

Lessons Learned

A website is never technically finished, but we are very proud of the solution we delivered to the eXs team and I’m grateful for the experience of getting to work with them and the lessons I was able to learn.

Givecamp was a crash course in just how valuable time is to the delivery of a digital product. When you have only a few days to deliver a solution, every second matters. However, I am astounded at how much time we saved by NOT cutting any corners.

You would think that when time is so tight, skipping wireframes and going straight to hi-fi mockups would have been the way to go. However, I can’t imagine our team would have landed on as solid of a solution as we did as fast as we did had we not followed a design process that involved low fidelity mockups first.

I was also again reminded that a UX designer’s role involves wearing many hats. It’s just as important to be able to ideate and clarify the scope of a project as it is to be able to build out prototypes at a rapid pace.

Check out our finished site at xservices.org! I’m excited to return to the SWOGC next year and I highly recommend you check it out as well!