Overview & users 

M6Connect is an enterprise class SaaS platform with integrated asset management modules for contract, application and vendor management. The platform was designed in partnership with Sharp HealthCare, who provided a small team of analysts to gather requirements and complete testing. 

Sharp HealthCare’s IT staff and management use M6Connect’s platform for contract, application and vendor management.

Problem space

The M6Connect landing page took an average of 15+ seconds to load, a major complaint of all the enterprise users at Sharp HealthCare. The load time was especially frustrating because the landing page displayed a native messaging feature that hadn’t been adopted by the Sharp HealthCare users.

Furthermore, the path to an asset search was perceived as long (4 clicks) and the navigation was difficult to discover.

My role

The short answer

UX research, synthesis, ideation, wireframes, usability testing.

The longer answer

After hearing IT directors complain about the M6Connect platform, I took the initiative to present a user research proposal to IT leadership. It was accepted and this case study discusses my self-led work to conduct in-house user experience research for the first time in Sharp HealthCare’s IT department. I conducted the research and analysis, ideated solutions, sketched, designed and tested prototypes and provided the final recommendations to M6Connect’s leadership team.

Scope & constraints

I did not have direct access to the development team at M6Connect so my research and recommendations were handed off to my contact, the CTO.

Process

I had heard anecdotally—in the hallways, in committee meetings and on support calls—about how directors were frustrated with accessing contract records in M6Connect. To ensure my research would be focused and uncover actionable insights, I wrote a research plan to learn about the top tasks of all users. This would best inform what the landing page should feature, plus provide insight into possible navigation, information architecture or functionality improvements.

Because the landing page for the contracts module is the same for all M6Connect users, my research plan included interviewing IT staff who used the application module as well.

M6 research plan

User interviews & survey

• Identify all current user roles (director, application analyst, site support analyst, etc).

• Recruit interviewees from each group.

• Conduct user interviews.

• Send survey to application module users for additional details.

Synthesize research

• Analyze interview and survey results.

• Create user personas or other artifacts, as appropriate.

• Write How Might We statements to guide next phase.

Competitive analysis

• Complete competitive analysis of top contract management software to identify homepage designs, including key features, layout, navigation style, etc.

User interviews

I scheduled in-person meetings with each of the 6 directors. I used my interview script as a guide for the conversation, though I allowed the conversation to flow naturally. I recorded each conversation after receiving permission to do so.

I also interviewed 3 analysts over the phone to understand their top tasks and associated workflows.

After each interview, I “downloaded” the interview notes into a master table while the conversation was fresh in my mind.

User survey 

To supplement my interviews with the 3 analysts, I also administered a survey to IT analyst staff. Though there are ~500 potential IT staff users, I only targeted those who had logged into the application management module in the last 3 days. Out of the 86 staff members, 8 responded to the survey. 

Survey questions

1. How often do you access M6? 

2. Why do you log into M6 most often? In other words, what task(s) are you usually trying to do? 

3. Do you typically visit the same apps or contracts repeatedly? 

4. Please describe your experience and perception of the M6 homepage. 

5. What would be helpful to find on the homepage? 

Competitive analysis 

To conclude the Discover phase, I investigated how leading asset management platforms designed their landing pages. I found that the majority showed dashboards with data visualization elements (some customizable by the user, some not) and only one other leading platform displayed a messaging modal on the landing page.

In the Define phase, I analyzed and synthesized the data I had collected. Rather than creating an affinity map, I used the table to tally how often the same top tasks, pain points or other feedback was shared.

Most frequent tasks for contract management in general

Most frequent tasks for contract management inside M6Connect

Insights

From the research, I learned that all users need to access the search functionality in almost every session (it is an asset database, after all). The pain points were similar across all user types.

To summarize:

User personas

Three user personas emerged from the research. These were closely correlated with the users’ functional job duties.

Ideation direction

At the end of synthesizing my research, I framed my learnings as How Might We questions that would guide my solution brainstorming and sketching.

How Might We?

1. How might we design a homepage that will allow for quick access to the “Quick Search” functionality for both the Applications and Contracts modules?   

2. How might we design a homepage that will allow for quick access to specific records that a single user is interested in?   

3. How might we design a homepage that allows users to quickly access their “frequently viewed” records?  

4. How might we design a homepage solution that will load quickly?  

5. How might we redesign the navigation so that users can navigate confidently and efficiently throughout the modules? 

Sketches

I started the Design phase with sketches of different layouts and features. I ensured the sketches reflected the following changes, based on the research findings:

1. The search function should be featured on the landing page.

2. A customizable list of assets should be available to reduce repetitive searching.

   • However, speed is a top priority so the customized asset lists must be limited to avoid long load times.

3. Menu should be labeled

   • Note: A permanent navigation pane could be problematic. Screen width is important to display dynamic search results as the search results have long strings.

Rapid prototype: Speed above all else

I first created simple prototypes in Figma with a design that prioritized speed above all else. No customized views would load, reducing initial load time, though the views would be expandable with one click.

To avoid confusion, I nestled the search bar for each module underneath a button. I was concerned users might accidentally try searching in the wrong search bar if both were simultaneously displayed on the screen. (Unfortunately, I knew the development team would not be able to create a combined search bar until much further down the road.) I figured the benefit of avoiding confusion would be worth the extra click.

I intentionally did not design a lot of detailed functionality in these wireframes; I wanted to rapidly prototype and test a page that had both a search and customized views.

Usability testing

I recruited two users from each of the personas for testing. I asked them to do a quick walk through of the prototype and provide their feedback.

Positive feedback

1. Users appreciated that the search functionality was available with just 1 click instead of 4. 

2. Users were very excited about the prospect of customized views.

3. Users appreciated that the menu was labeled "Menu" instead of being a hamburger icon.

Opportunities

1. Users requested the ability to display multiple custom views at once and to be able to sequence them.

2. Users asked why the custom views couldn’t just display on the page upon initial launch.

3. Some users did not notice the ability to edit icon (pencil) in the header of the custom view table.

Iterated prototype: A compromise

In the second iteration of prototypes, I designed a solution that automatically loaded some of the user’s custom views onto the screen upon login. To reduce long loading times, I limited the initial load of each table to 8 rows of data.

I also allowed for multiple custom views to be displayed at once and to be resequenced by dragging and dropping.

Usability testing

I recruited two users from each of the personas for testing again. I asked them to do a quick walk through of the prototype and provide their feedback.

Again, the simple redesign was well received and users couldn't wait to see this in production! Most of the feedback was not around the usability of the wireframes, but about the logistics of maintaining customized views (how many views could be created, how they could be maintained, which would display on the screen upon login, etc). I had already drafted preliminary specs for this, but again, had not built it into the rapid prototypes as I only intended to quickly prototype and test to confirm concepts.

I did record users’ feedback and updated my documentation at the end of usability testing.

To conclude this UX effort, I updated my documentation, finalized my design files and then presented my research, recommendations and wireframes to M6Connect.

M6Connect’s leadership reviewed my work and were pleased with my efforts (see their review of my work on my LinkedIn profile). Their development team made the final design and development decisions.

In their “MVP” of the new home page, they implemented some of the recommendations I made. 

• Search function is on the home page

  • Limited to application module search currently

• Favorites are available on the home page

  • Users can toggle the "Table" view to a "Favorites" view

They have added a table of application asset records on the home page as well, though they have limited the display to 10 rows to control loading times.

In future versions, they plan to implement customizable views and add contract asset records to the home page as well.