This, my friends, is one of THE most involved and spiciest interaction challenges in the mix. What are we dealing with? Basically every consideration in interaction design happens for a drag and drop interaction. Not only do we have to effectively convey the interaction exists in the first place, the object needs to physically move, the live feedback second to second matters, and there are lots of decisions to make throughout to make it ‘feel’ the right way. Indicating state takes on more nuance than we usually deal with.
Things can get weird and go wrong over different devices, and working out the kinks invariably needs some meaningful collaboration between design and devs.
Any way you slice it 🍕, it’s no joke.
Things to consider when designing drag and drop experiences
When entering into designing a drag and drop interaction, you and your team have a lot of things to consider.
- What are the ways we could solve this problem (in general)?
- Do users need or want a drag and drop interaction?
- What devices and use cases will be involved?
- Is drag and drop an appropriate solution for our interaction problem to solve? Does this match up with familiar patterns out there? Or is it new?
- Is there a JS framework we need to stick to? Or is there freedom to design it in a more specific way? How much control might we have?
- Do we have enough bandwidth to implement this kind of interaction?
- Is this interaction needed on mobile?
- Can we test a framework with people with some dumby data, could we run this as a ‘spike’ type of task?
For the interaction itself
- Are any restrictions necessary here? Restrict movement into any directions
- Do we want a totally flexible or incremental behaviour
- Is there any key logic to convey about what’s allowed and not allowed to be dragged? If so, what’s the logic?
- How precise or sensitive should this be?
Anatomy of drag and drop interactions
The number of components or UI pieces involved in a drag and drop interaction is quite simple, the complexity comes in dealing with the states, feedback and logic of your interaction.
The list item– the thing being dragged, this is usually a list item, a card or another object (for simplicity, we’ll just call them the item or list item for the remainder of this article).
The source– the container that houses the items you’re going to drag.
The drop target– this may be static (there all the time) or it may be a dynamic thing – the purpose of it is to give you real time feedback on the items being dragged – empty state of sorts, and it deserves some time and attention, especially if there is logic that needs to be expressed within the area.
Types of Drag and Drop
Drag and drop UI/UX is quite a varied out there in the world and it’s used (for better or worse), in a lot of contexts. They all have slightly different interaction needs and requirements — as such they have a variety of drag and drop UX patterns. This is especially in enterprise software context, where the use cases can get quite involved, so the UX patterns can get more and more complex. Generally speaking, use cases in drag and drop are moving items, reordering a list, resizing containers and power user drag and drop interactions.
This use case is the ‘classic’ drag and drop example, where we assume there’s a static and distinct dropzone – much of this article will reference this classic example as it’s the most complex and involved.
Examples of common drag and drop ‘move’ patterns:
A file upload pattern depicted on the Mac desktop, a stack of files mid-drag en route to a enterprise software hosted in the browser.
A folder full of excellent ideas being dragged into the trash can on mac.
This use case is very common across OS’ and platforms – this is the act of reordering items in a list or card format. Here the drag target is dynamic on the screen and will show the precise position the item will end up in once the drag is released.
Examples of common drag and drop to reorder patterns:
Reordering elements on Evernote dashboard uses drag and drop.
Reordering sentences in a word processor – example Google Docs.
Resizing is when users can drag containers within a screen within a range of space available (usually it’s limited in most SaaS products). There are a couple of unique aspects to this interaction.
- There’s less of a distinct drop target here – the drop target is not really a thing, but the act of ‘releasing’ the selection is still present
- Confirmation feedback is less pronounced because the size of the object changing itself is the feedback
Common drag to resize interactions
Resizing a container within a software product to optimize space – a drag handle is active and a cursor change is present in this Google Docs example.
🔬 Power user manipulation
This use case is specific to enterprise products which allow for deeply involved drag and drop interactions, where users can manipulate items in the UI in an almost unlimited way. Take for example, drawing a rectangle in a product like Figma (or any in-depth design product). Users, depending on their ‘level’ of selection into the object can resize it while keeping the same ratio (ex. Hold down shift). They can change the height and width, and even drag an anchor point (double click in a few times) to change the object from a rectangle to any other shape.
This level of manipulation is a whole next level of advanced interaction which we’d love to deep dive on, mostly this article doesn’t touch on this complexity level (but we would love to deep dive into this complexity level, so make a request if you’re dying to dive deep).
In many a design software, you can create or manipulate an object by dragging – Figma example shown.
Objects are created in design software, like this rectangle
Drawing applications have a ‘deeper level’ of manipulation, in this state the user can ‘click in’ deeply into the anchor points
A single anchor point can be selected, changing the shape of the item completely.
Drag and drop steps workflow and states
To illustrate each step in the drag and drop interaction, we’re going to use the example of a screen of an app, that allows items in a list (either single or multi-select) to be dragged into a specific dropzone target on the screen itself. This example lets us show each moment in drag and drop as very distinct.
In this state, the list items (and their container) are static and the drop target is in the default state.
Trigger: page load complete
Drop Target: default state, zoom in.
UX microcopy is extremely important for drag targets, make sure you put in effort here.
In the default state, we call out two main opportunities for microcopy, the main text and the supplementary text. The main text tells you the most important information: what to do. In many enterprise or SaaS use cases, there is additional logic that can be explained upfront in the supplementary text.
💡 Bonus UX moment:
If this logic is complex or has upstream/downstream implications, pop a link in there to your knowledge base which will help people understand their actions more deeply. 🤌
Whenever possible, we urge people to communicate things upfront rather than throw an error after the fact, this is kind of a big deal heuristic for usability (error prevention and communicating system status are explained in our UX Heuristics article if you’re curious).
Hover state (on desktop screens)
Trigger: mouse over the drag affordance area
Drag area is ‘grabbed’ or gripped
Trigger: mouse click or press on mobile
Once this first phase is complete, you have your item grabbed, and you’re ready to start moving it. Let’s go!🏃🏻♀️
The act of ‘grabbing’ is successful, now the item(s) are moving in space alongside the cursor – this is the step before the drag target starts to activate.
Trigger: Cursor or finger moves
Multi-select transition (optional)
If multiple items are selected: there is another transition possible which confirms to users that the initiation of the drag was successful WITH the amount of desired items (totals) shown.
☝️👵🏻 Source container – don’t forget the list item container – or ‘source’ of draggable items.
You’ve got options on the behaviour you choose for this. You can simulate that the items have ‘left’ their location or you can apply a specific state to the list items – showing that they are in a transition but keeping them in a static location. (see these options in action in the ‘Reorder interaction patterns for drag and drop’ examples 👇).
Note: the semantics and abstraction can get a little crazy when answering these types of questions: should the items look like they’ve ‘left’ even though they haven’t yet ‘moved’ anywhere real?
Dropzone within range
The dropzone indicates that the items are within range – the visual feedback might intensify as the items get closer and closer to the core of the dropzone.
Trigger: dropzone within range
Drop zone visual feedback
This is a good opportunity to give both visual feedback AND use UX microcopy to ensure that the details of the operation to be completed is ‘foreshadowed’.
More nuanced visual feedback may be necessary when say, there are multiple drop zones so people are differentiating between them, so movement will be more precise. There may be staged feedback within the outer edges of the dropzone – initial feedback to assure users that they are on the right track.
Drop zones might be dynamic and based on their x and y coordinates: take this example of a table hierarchy UI where you’re building parent-child relationships.
The drop target feedback defaults to the connect to the primary ‘parent’ list item, when it’s just within range distance.
Dropzone changing based on physical position on the canvas – in the x and y coordinates. They will have threshold that they ‘snap to’ – this will be determined in collaboration with design and development.
Warnings when within range
Trigger: logic of what is allowed is violated, or ‘will be’ if the items are dropped – we always suggest that you warn people rather than throw errors after the fact whenever possible (see our errors article for more info here!)
🎤 Great success! Or, maybe not. The ‘dropped’ state isn’t necessarily as simple as you might think. In fact, there can be a variety of results, ex: loading states, requiring the user to make another decision, success, or even failure.
Let’s build up our understanding with these other states and top it off with success.
For use cases where files are uploaded for example, you may opt for a very literal UI response, where files are shown going ‘into’ the target. In cases where this drop event has more to it, make sure each item is described properly.
There are lots of cases in enterprise where dragging and dropping actually requires another decision to be made in order to complete the operation. Using the drop target can be a nice place to locate a simple dialog because you know the user is looking there in that precise moment 👀.
This is an opportunity to show people the operation worked and confirm exactly *what* happened. In this example, success feedback is supported with the statement that 4 items were added. Then users know that everything they just tried to do worked for sure. (Success feedback is often forgotten and deserves its moment, we did a pattern article on success feedback to help).
And finally, the error state – this may happen for many reasons, such as:
- List items aren’t allowed to be dropped there
- The operation wasn’t registered on the front end
- The operation ‘tried’ but the backend failed to perform the task
- The item wasn’t actually draggable in the first place, the UI was misleading
Drag and drop is definitely a culprit for ‘passive aggressive’ errors, that is: subtle/non-existent) or even misleading behaviour in the UI when an error happens. Check out our error pattern article if you want to explore more.
This wraps up the phases of your drag and drop operation. Now let’s explore more nuances of drag and drop to become total professionals on the topic.🤜💥🤛
If you’re feeling like: Whoa that was a lot of states and interactions, you might enjoy our article on creating high quality interactions, which gives a nice overview of #allthethings. Cheers 🥂
Reorder interaction patterns for drag and drop
Reordering is special and the perfect place to address a couple of the UX patterns and logic you might want to apply to your drag and drop situation. Let’s take a moment to zoom in on it, so that we can discuss both the drop indicator and the behaviour of the container of the list items.
This example shows a minimal drop indicator – here it doesn’t require movement of items in the list. Instead it slots the item into the list cleanly.
Ghost list item – This shows the list item as ‘still there’ which can be reassuring to the user that the item is not truly displaced. This is more useful when you are moving something of significance, where the stakes are higher in the operation or the context of where the list item ‘started’ is important.
Advantage: less movement could be easier to create, and potentially less jarring, especially if users do this operation a lot. It also allows people to maintain the original context (order) very easily.
Disadvantage: there’s more of a transition required to ease the difference of the ‘before and after’ states of the list, the ‘movement’ aspect would be represented only at the end
This example shows a maximal drop indicator, much more literal than the other example.
Advantage: the item really seems like it’s moving to a new spot, the feedback is very immediate
Disadvantage: it’s not clear how to abort the operation without changing anything. It also requires more smooth movement of list items.
The drag and drop affordance issue
You know what’s hard? Showing on a flat screen that you can ‘physically’ pick something up (you can’t actually because it’s 0’s and 1’s) and ‘move’ it (you’re actually changing values of 0’s and 1’s in the database that surrounds the product). Showing that drag and drop is available is a difficult challenge for designers. We’ve got issues people.
If the interaction was physical, you could easily create a handle which is obviously designed for a hand to fit around it. That handle would be there, out in the open. Our challenge with drag and drop is that the ‘hand’ is either our pointer/cursor on desktop and a finger on mobile (where you can’t detect if it’s close by to the item at all because people don’t ‘look’ around on their mobile screen using their finger). On top of that, drag and drop may be a very occasional action people do, screen real estate and attention is limited, and screens get cluttered very quickly. Always showing the ability to drag and drop makes it more discoverable, but does it pull focus and make other things less discoverable? It’s a balance we’re always trying to come to when we create UIs.
So how do we make things look like you can pick them up and drag? One technique (the most common one) is the use of icons. Iconography, as we know from many other moments (like in navigation, or buttons for example), can be very tricky to get right.
📖 A user testing story – Once upon a time we tested some drag and drop affordances, and let’s just say, it was confusing (this was quite a few years ago), but we wanted to provide a specific affordance that told users precisely what they could do. This is a summary of how it went:
Another visual indicator that a drag is possible happens with the cursor on desktop, specifically upon hovering over a draggable item. We typically see a pointer appear initially, then a grabbing hand once the mouse is being pressed. For move and the re-size cursors, they typically stay the same on hover and while they are active.
Note: grabbing something to drag it, isn’t exactly the same thing as selecting something – when designing this stuff we need to account for the possibility of multi-selection and drag and drop as well.
Affordances of drag and drop aren’t only localized to the list item itself. The drop target (AKA dropzone) is also used to communicate the possibilities – that plus the fact that the technique is used across so many platforms can help people put the pieces together. 🤞
Discoverability will be likely to continue to be a challenge in the UX design world for a while. With enterprise products, we have the context of users being trained and perhaps more motivated to discover things that might make their workflow easier than consumer products. But, as we always say, test early and test often. Also utilize your usage analytics when you can to understand more about user behaviour in reality.
Advantages to drag and drop
Dark mode to UI is what drag and drop is to interaction. It really does illicit strong reactions, either FOR and AGAINST it. For us, we feel that your design rationale and logic is key to justifying your efforts in creating new interactions and functionality overall. There are lots of good reasons and rationale to create a drag and drop interaction.
Efficiency on visual-based interfaces – in cases where the specific view is highly visual, allowing users to directly manipulate the object they are working with, is a strong approach to building interactions that are intuitive.
- Enterprise examples of highly visual tools: a data model visualization, a drawing application, an org chart visualization tool
Reordering lists – Reordering lists using the non drag and drop patterns out there, can be quite onerous and difficult to QA (ex. Adding numeric fields to order them or using a container system with an ‘input’ on the left and ‘output’ on the right) – our crew isn’t convinced these approaches are easier to develop nor are they less confusing than drag and drop.
Logic flow UIs – Enterprise software shoutout here. We actually do a good chunk of UIs which display complex logic in a visual way. There are a ton of use cases around boolean logic (and other logic) out there. To understand them, visualizations are the most efficient way to understand at a glance, the way these systems work. By extension, direct manipulation of the object through drag and drop can be the most intuitive.
Disadvantages or reasons to avoid drag and drop
Drag and drop is a very ‘demo-able’ feature, it certainly brings the razzle dazzle and presents as very easy in that kind of context. When thinking about solving a problem with drag and drop, consider some of the possible disadvantages of using this interaction mechanism.
Accessibility – if there is priority for these interactions to be created/improved, the non-drag and drop version is key to have as well. Accessibility is a big murky question here that could be an issue throughout discovery all the way to execution. When we’re working on enterprise products, we typically start by building the alternative, then build drag and drop as a supporting interaction or ‘power user’ version of the feature.
Team bandwidth – as mentioned when we started this article, drag and drop can be pretty complicated in terms of the interaction design, there are lots of cases and considerations to make. If implementing drag and drop as a solution, it needs to be tested across platforms and devices rigorously. If you don’t have the bandwidth to do this, you risk blockers in your software. Drag and drop really needs to be implemented well to work well.
Long distance movements (scrolling) – if you are required to scroll and drag at the same time, this may be way too onerous and frustrating for your users. This long distance scrolling might pop up when you have screens which may be very long (and this isn’t predictable because it’s user generated data) like screens with infinite scroll.
User needs lacking – drag and drop is slick and cool, but sometimes there isn’t a good enough justification to build with drag and drop, or perhaps the action is quite high stakes, so lowering the barrier of entry and making it super efficient isn’t ideal.
Drag and drop alternatives
In enterprise, we typically always design alternatives to drag and drop, even when the drag and drop interaction is definitely making it to production. Having only drag and drop in place to achieve a goal is fragile, because if it isn’t usable by someone, that’s a blocker. (Other than accessibility, there are other ways drag and drop can fail, including latency of the system (ex. secure systems you have to use a virtual machine or VPN to access, browser updates causing bugs, outdated front end frameworks, even just someone having a wonky mouse — you need contingency.)
Move interaction – on desktop
For moving things, it’s possible that some of the most basic UI mechanisms can do the job for you, perhaps in a more expedient way.
The example above shows two methods, the action bar (this can be contextual or persistent), it offers a way to apply not JUST a move action, but could house a myriad of batch actions at the same time. The menu dropdown is another method you can use, where you can manipulate the item directly, without moving things visually.
Reordering drag and drop alternative pattern – on mobile
Steps of this mobile drag and drop alternative flow are quite simple. This is something worth considering for reordering on mobile. Steps of this interaction:
Enter screen > Chips are populated
Tap to select > Tap in specific order
Hit next > Once >1 are selected
- Reset button let’s people start again from scratch
- If mistake is made, deselect by tapping for the second time, removes from list and numbers adjust themselves
Want more alternatives to drag and drop? Shoot us a request on Twitter, we’re full of ideas!
User testing drag and drop
There’s probably a few articles to write on this topic, as a thorough usability test of drag and drop should ideally involve a mix of user profiles, system states and devices/hardware.
On the practical front, user testing drag and drop is quite difficult on a high fidelity design software, especially if you’ve got some complexity in your drag targets or there are multiple states and scenarios you’d like to test.
Here’s where the design and dev crew can shine together as a team. Since so many frameworks are typically used with drag and drop, we suggest that you create a live code prototype that’s realistic enough to give you some nice usability insights. If you’re able to use something that’s relatively fast to build, you’ll be able to nuance and iterate on the behavior together in a super productive way.
If you want to dig into more topics on collaboration, check out some of our stuff on team collaboration.
Well, we hope your 🧠 is activated by all these drag and drop best practices and UX patterns…and downright nerdy energy we’re servin’ up. Drag and drop is a very rich and interesting interaction pattern that can extend your functionality and give amazing power to your SaaS or enterprise software application. When this functionality is combined with complex operations, workflows and use cases, this can be an excellent tool to give to your power users. Proceed with intention, user data and creativity! 🪐