Deleting may only require the user to click a button, but looking deeper, deleting can also trigger a ripple effect. In this article, the author talks about his understanding of "deletion" and shares the cases he has encountered in his work, so you might as well take a look.
Deleting often only requires the user to click a button, but as a product manager, you should always have a "system" mentality: deleting an object is not like removing a book from a shelf, but rather playing a game of drawing blocks on top of each other - there are moments when the removed blocks lead to a chain reaction where the requirements that were originally closed are no longer closed when one link is removed.
Some time ago, I summarized the common basic abnormal processes in the article [Beginner Article] Picking Up the Abnormal Process in Product Design (1), and this article can be regarded as its sister article, talking about my recent cognition of [Deleted].
1. Basic design details of [REDACTED].
As one of the four major operations of "adding, deleting, modifying, and querying", everyone should be familiar with the basic design of the deletion operation.
1. Direct deletion
In my experience, it is generally applicable to scenarios that can be restored after deletion, such as deleting photos in an album and retrieving them in the recycle bin. But I haven't encountered such a scenario in the B-side so far.
2. Delete after the user confirms it
It is more common to delete after the second confirmation on the B side, and if there is an irreversible impact after deletion, you need to inform the user through the copy.
When deleting in batches, you can emphasize the total number or list specific deletion items in the copy for further confirmation and avoid errors.
(Image source: Jian Daoyun)
2. The knock-on effects of [REDACTED].
As mentioned earlier, the deletion operation often only requires the user to click a button, and the deletion of a line of records, a card, or an icon may be deleted from the page...... But out of sight, a single deletion can often set off a ripple effect, so design needs to be done with care.
Here are two examples that I have encountered in my work.
1. Whether the deleted object has an association with other elements
In object-oriented design thinking, there are various relationships between classes. For example, when we want to delete an object, we should first consider whether there is an association between the object and other elements.
If there is such an association, should it be considered whether the association should be automatically dissolved when it is deleted?Where is the relationship applied?Will there be other effects after the dissolution?Does the user know that the deletion also produces other "results"?
Example:
1) Scenario: The production equipment is hung on the production line, and there is an n-to-1 relationship between the production equipment and the production line, and one of the verification conditions for the storage of the production line is "at least one production device, otherwise it is not allowed to be saved". Assuming that production line A has and only production equipment A-1, and the user saves the production line, then it is obvious that there is a "paradox" after deleting equipment A-1, and it is logical to deduce that production line A also needs to be deleted at this time.
2) Solution: From my personal point of view, the user just deleted a device, and at the same time there was no production line, this step is a little bigger, that is to say, the impact is a bit big, so at this time I will inform the user in the copywriting of this situation, by the user to remove this association, and then delete the operation, of course, this is also a more common treatment.
2. Whether the deleted object generates relevant business data
When you delete an object, you need to consider whether to discard or retain the historical data generated by the object when the object generates related business data.
Example:
1) Scenario: If product B is currently in existence and the customer reports the output of B every day, if product B is deleted now, what should be done with the historical output data of B?
2) Solution: Thinking from the scene, in what scenario will the user need to delete a product? If the product information is only created incorrectly (such as specifications, models, units, etc.), then it can be modified through [Edit], and there is a high probability that there is no need to delete it.
The only scenario I can think of is when a certain model of the product is discontinued, and the company will never produce this product in the future, so from this point of view, it is clear that the historical production data is not affected, so I tend to keep the historical production data after deleting this product.
The above is the deletion scenario I have encountered in my work recently, limited by work experience, and it is time to throw bricks and stones. So, see you next one.
This article was originally published by @工凡 on Everyone is a Product Manager. Reproduction without permission is prohibited
The title image is from Unsplash and is licensed under CC0
The views in this article only represent the author's own, everyone is a product manager, and the platform only provides information storage space services.