ACUITY DATA SOLUTIONS

As Pharmaceutical companies search for more effective and efficient ways to manage collaboration with the physicians, relationship management becomes an essential component in their business.

Physicians must choose from a myriad of drug options for their patients, they often turn to leading physicians for their knowledge and advice on specific drugs.

These individuals are known as Key Opinion Leaders (KOL). These KOLs are relied on to help establish the drug's knowledge base to expand their markets.

To comply with my non-disclosure agreement, I have obfuscated or removed confidential information in this case study. The information here is my own and does not necessarily reflect the views of Medical Knowledge Group.

Problem

81QD, a company with ties to Visual Alchemy needed an redesign of an existing application that pharma companies used to research individual physicians. This application needed to have this major functionality:

  • This application needs to be web-based, and used on a web browser.
  • Needs to track individual KOLs and all their information.
  • Needs to be customizable by the client, this customization needs to happen in an Admin application.
  • Needs to accomidate existing data, and accept new data fields.
  • Needs to be able to create user accounts, user classes, and set permissions on those classes.
  • Regulatory compliance. Certain users will only have access to certain individuals and data. This is needs to be set up in the admin.
  • User need to be able to narrow down the individuals that fit their intentions. This needs to be configured on first sign in, and not again unless they so choose.
  • Needs to allow for users to create groups of users, which can be saved and shared with other users in their department.
  • Needs to to allow a user to create Activities, which needs calendar that can be shared with other users.

The Audience

The users are employees of pharma companies. They might be in marketing, sales, managers, etc... Anyone needing access to this information. The age range is 21-65. We were able to meet a few on a daily basis during our discovery and user testing sessions.

The Team

The team expanded and contracted depending on how busy the work got. There was 1 Project Manager, from 1-3 Business Analysts, 1 Development lead, 1 Database administrator, 1 UX Designer (me) and the Medical Director who was our daily resource for user requirements. When needed users would come in and go through a series of tasks for the new build of the application.

The Constraints

The biggest constraints was the growing complexity of the project. As we were building out the different sections and functionality, the business stakeholders wanted more functionality not discussed during the discovery process.

This is not totally unexpected. I understand that as a tool is becoming clearer to them, new requirements rise up. Because of this, time became a big constraint and hitting our deadlines.

The development team was building the front-end of the site was off-shore. They begin their work day at about 9pm. Screens that have been approved need to be handed off to them before then. This means, wireframes, annotations and any additional annotations.

The Constraints

The biggest constraints was the growing complexity of the project. As we were building out the different sections and functionality, the business stakeholders wanted more functionality not discussed during the discovery process.

This is not totally unexpected. I understand that as a tool is becoming clearer to them, new requirements rise up. Because of this, time became a big constraint and hitting our deadlines.

The development team building the front-end of the site was off-shore. They begin their work day at about 9pm. Screens that have been approved need to be handed off to them before then. This means, wireframes, annotations and any additional annotations.

Frequent changes to the requirements had rippling effects on other parts of the application.

Lessons Learned

  • The importance of locking down user requirements.
  • The importance of thoroughly understanding the fundamental functionality of a project.
  • The importance of finding redundencies.
  • The importance of listening and empathizing with other team members. Everyone was shoulder deep in their part of the project, their documents, responsibilities and deliverables. If I can understand their perspective, their needs, the factors they have to deal with, I can understand how my work affects theirs.
  • The importance of getting ahead of potencial problems, conflicts, inconsistencies, etc... Creating a few logic diagrams helps when going into meetings and sharing these concerns.
  • The importance of taxonomy, and vocabulary. Everyone has to be using the same words and the same words in the same way. For example, at one point we had Activities as section. Later on 'interactions' were added. This caused a lot of confusion initially. I examined what was going on and updated the sitemap to communicate that 'Activities' is a section, 'Events' were a specific kind of activity, and 'Interactions' were another kind. This seems like a subtle small point, but if a team member starts referring to an Activity, it needs to be known which they're talking about. When you add 10 people in a room, it can get confusing. So using the right words is critical.

Tools used

  • Axure for the wireframes. Axure for creating prototypes. There were about 200 wireframe screens. It was not practical to have these as individual pages in Axure, so I relied heavily on the user of Masters and Dynamic Panels.
  • InDesign for managing all the wireframe screens. Annotations were done in InDesign.
  • Photoshop was used for creation of any graphics or mockups.
  • A lot of whiteboard sessions with the team members daily.