UX Research for Drag and Drop interactions

Through this project, I introduced the concept of UX testing data widgets at the point of production. Through this approach, I refined the widget’s core design based on end-user feedback before it was published in our design system. 

‍
Core team: 1 Developer, Myself as the User Experience Designer and Researcher, 1 Quality engineer, 1 Software Process Engineer.
‍
Timeline: Feb 2019 - Apr 2019

This project is under NDA. The case study shared here is only my viewpoint and doesn't reflect MathWorks or any other person working at MathWorks.

About the Tree widget

MathWorks offers a variety of products under the MATLAB and Simulink umbrellas. These products directly help support Research and Development efforts undertaken in various industries and scientific domains.

A Tree widget is used in many MathWorks product UIs to show a hierarchy to the users visually.
Users may want to select a tree node and view or edit details about it, carry out other operations on it, or even change the tree’s structure. 
‍
As part of providing interactive capabilities for our end-users, we introduced a feature that allows interactive reordering and restructuring of tree nodes. 

A checkbox-tree widget used in Simulink

    While the product’s context dictates why and how users will want to restructure the tree, all end-users will experience the interaction and visual designs that this team bakes into the widget. I wanted to evaluate those specific decisions, keeping the context aside, objectively.

    Why this matters

    One challenging aspect of designing generic widgets that different downstream teams would use is finding the right balance between providing enough flexibility and maintaining consistency.
    Some of the design decisions get baked into the widget to ensure a consistent end-user experience.
    This approach helped us validate those decisions, test the core design quality, and prevent usability issues from creeping into downstream products.

    What did I design?

    I identified the required states in the interactions. Specifically, I created interaction models to disambiguate between users’ intent to drag a few nodes to reorder and the intent to drag-select a series of nodes. 

    A state transition diagram to capture all the interaction states

    I outlined all the requirements for providing the user’s correct feedback before and during a drag operation and after drop operations. I collaborated with the Visual designer and created the required specifications.

    Research Questions

    The proposed design provides the end user feedback both, during and after the drag operation. With this design in mind, I had the following research questions to address :

    • Can users easily reorder nodes in the tree?
    • Do the specific design elements convey the required feedback to the user?
    • Is the feedback provided to them when they are about to drop useful?
    • How is the overall experience using this widget?

    HMW ensure that the design provides the necessary feedback to the user?

    How I sought feedback

    I outlined four tasks, each directed at addressing one or more of the research questions.

    A sample task presented to the user

    For one of the tasks, I simply showed the participants a screen-capture. I asked them to assume the screen-capture represented the state mid-drag. I asked them what they would expect to happen if they were to “drop” at that point.

    I chose this format to collect data because I wanted to specifically collect feedback on the feedback that the visuals provide to the user.

    Sample task where the user is asked to predict the outcome of the drop operation
    Sample task where the user is asked to predict the outcome of the drop operation

    Metrics

    I ran the above study with five users within the company who I had identified as prospective users of this component.
    Each session lasted 30 minutes and I collected the following data for each task.

    • Task Success
    • Ease of Use score (Pre and Post Task)
    • Confidence score (Pre and Post Task)
    • Frustration score ( Post Task) and
    • Qualitative notes from the session

    High Level Findings and Results

    Overall, participants were mostly successful in completing the tasks. The overall design was mostly well-received.

    The icons did not convey the intended meaning.
    The original design used icons to differentiate between two kinds of drag operations; the icons did not convey the intended meaning. Users were able to predict the right outcomes despite not understanding what the icons meant.
    The Blue icon looks like a folder. I assume it is going to change this node's parent.
    Most users preferred a different default for drop position
    In the original design , the default position of a node when it gets dropped into a new parent was at the bottom of the branch. When users encountered this design decision, while they were not surprised by it, most users preferred to see the dropped node at the top of the branch, closer to its new parent.
    Confusion between invalid and no-operation
    In some cases, the original design showed visual feedback, even when the operation would not change the tree structure. This confused the users, and it was evident that the design needed to handle no-ops differently.

    New Design

    Based on the test findings, I made the following design recommendations.

    • Removing the icons from the avatar, since they did not add any additional value and were often misunderstood.
    • Change the default position of a dropped node from being last child to first child. This design would also result in the dropped node appearing closer to the users point of interaction.
    • Handle edge cases gracefully. Specifically, wherever possible, avoid initiating DnD until certain threshold is reached.
      Avoid showing any Visual affordances for no-ops wherever possible
    New design after the feedback was incorporated

    Takeaways

    Concrete design recommendations

    In this project, I learnt that I could come up with concrete design recommendations even with low-cost research solutions. Based on this lightweight testing, we pre-empted a bunch of usability issues before the widget was published to the design system, saving a lot of time and effort.

    Gathering agreement from Stakeholders

    When I first proposed to UX test this feature in a context-agnostic widget level, it was met with some hesitation. I was able to convince the stakeholders of the importance of usability testing and come up with a low-cost solution to achieve this outcome effectively.