L-B.

The user

Medly oversees its own fleet of delivery drivers and handles delivery logistics through a combination of the internal delivery app, OnFleet, and Slack channels. The latter especially relies heavily on manual updates and is prone to human error.

The capacity for certain delivery zones on specific days and time slots is currently hard coded and too rigid for unpredictable change such as drivers being hired, leaving, or calling out, so there is a great unmet need for a flexible and centralized system to manage such changes.

The role

Because the delivery team is solely internal, the direct line of communication between product and users lends itself to frequent feedback and requested features. We are more easily able to observe issues or pain points and work directly with our teams to resolve them.

Since this process of feature development was less formal than one with multiple rounds of testing and research, most of my efforts were spent on collaborating with the PMs on the requirements and exact scope of the feature, and then later iterating on designs and bouncing ideas back and forth.

Building for today

When the feature was first proposed to me, the PMs on the team had already gathered some feature requirements of the types of actions a user should be able to accomplish through this new feature: basic CRUD for delivery windows, locking out a window as a one-off event, and overriding regular windows in the event of special occasions.

However, there were many unknown factors to consider before design such as what a realistic amount of concurrent windows might be, how often exceptions occur, how far out deliveries are coordinated, and a myriad of other facets.

The role

Through a combination of informally chatting with delivery coordinators, basic wireframing, and reviewing concepts with the PMs we were able to agree on a version which would meet the current needs of delivery coordinators while also leaving room for future optimized operations.

While currently delivery is planned on a more ad-hoc day-to-day basis, in the future we strive to optimize this process, decrease delivery times/delays, and consequently improve the patient experience overall This includes recurring overrides, seeing a weekly view, and adding new delivery zones.

First pass, traditional

After receiving the document with the basic requirements, I devised two different ideas for the basic interface.

The first was similar to our existing app and heavily used existing library components such as tables. The benefit of this version was that it would require little front-end development , and would therefore be faster to develop. On the other hand, the table data structure was potentially not the most appropriate form.

First pass, no constraints

For the second concept, I wanted to rethink how to best portray information to a user. After considering the grouping of data and the scope or pattern of common actions, I devised a tile-based approach where each date had a tile which presented all window capacities and used color to differentiate states of capacity.

Second pass

After sharing my first rough concepts with the PMs, we came to the agreement that the table version was a sub-optimal representation of the information, but that the tile designs were trying to achieve too much in too small and cramped a space.

We also further determined that additional time slots may be added, and that delivery coordinators would probably only set overriding capacities on the day-of, or at most a couple days out.

To take both of these points into account, I further iterated on the experimental design and began taking inspiration from the Google calendar layout of overlapping time-based events.

Refining the calendar view

The second pass improved immensely on the original aim of the tiles to condense information, but the colors were not color-blindness accessible. Additionally, the business and difficulty of allowing for the creation of an indeterminate amount of overlapping windows would be immensely difficult to develop.

I revised the color schema to be more accessible and also more aligned with Medly’s color palette. I also limited the view to 3-4 days depending on the screen resolution, and the number of concurrent windows to 2 (all-day and individual slots), which was a realistic amount for the capacities we had at the time.

Supplemental tables

Rather than trying to pack too many small buttons and condensed text into the calendar view, I opted to use a separate secondary page for editing window capacity information.

On the top right of the page, the user can toggle between recurring values and override values. From the calendar perspective, only the specific capacity for a given date is shown regardless of whether it’s an override or not. Contrastingly a user would be able to see the separate values in the editing state. One additional benefit is that the developers could easily reuse prebuilt table components from the library.

Results

The delivery app is internal to Medly employees, which presents certain advantages and challenges. On one hand, the proximity to our users provides a close channel for feedback. On the other hand, pharmacy employees are so busy that scheduling dedicated research or testing time is extremely difficult.

To work with their schedule, it was easier to simply begin with a set of basic requirements and then iteratively determine further details throughout the process. Sometimes this leads to inefficiencies or an “imperfect” end result, but the compromises are integral to timely development.

Reflections

Looking back on my process, I would definitely try to better integrate even informal research or testing in order to have a better understanding of the full scope and breadth of requirements for the feature. However, I think that the nature of some internal projects ends up being somewhat more ad hoc and that going with the flow also works, as long as everyone is on the same page.

I am satisfied that I was able to advocate for a new view and brand new components that fit well within the current library style, and I believe such time-based elements can be used in future internal products.