Pause or Deactivate?
Turning critical choices into predictable and reliable experiences
Company: QuintoAndar
Role: Senior Product Designer
Scope: End-to-end
Squad: House & Listing
Timeline: 40 days
context
QuintoAndar is a real estate marketplace that connects landlords and tenants through a digital platform. In this context, listings (ads of properties available for rent or sale) represent the main unit of supply.
Each listing contains information such as price, photos, location, and property features, serving as the digital representation of these units within the platform.
The availability and state of these listings (active, paused, or deactivated) directly impact:
Platform liquidity
User experience
Operational efficiency of the ecosystem
problem
Although listings are the foundation of the supply, the management of their states was inconsistent and unclear.
Different flows handled statuses differently, without a unified logic, causing unpredictable behavior for both users and internal systems.
Impacts
Users did not clearly understand the difference between pausing and deactivating a listing.
Decisions were made without understanding the impacts, lacking context on deactivation reasons.
The user journey had high friction.
Efficient supply management was compromised.
Relevant data
70% of product bugs were related to listing status management.
Behavioral inconsistencies across flows and touchpoints.
Users perceived lack of clarity about states.
Increased support demand related to activation/deactivation actions.
How can we make listing statuses clear and reliable, so users make informed decisions and supply stays healthy?
Hypotheses
Clarity drives better decisions
Clearer statuses → users make more informed decisions.
↓ Improper deactivations
↓ Immediate reversals (reactivate after deactivation)
↓ Errors in listing management flows
Consistency reduces complexity
Unified logic → fewer inconsistencies and bugs.
↓ Bug volume (70% baseline)
↓ Flow inconsistencies
↓ Technical rework
Context builds confidence
Explicit communication of consequences → reduced uncertainty.
↓ Support tickets
↑ Flow completion
↑ Satisfaction in critical journey steps
Strategic friction protects supply
Introducing friction in critical actions → prevents impulsive decisions.
↓ Unintentional permanent deactivations
↑ Rate of paused vs deactivated listings
↑ Retention of active listings
discovery
system understanding
The first step in the discovery phase was to map how listing status management worked structurally within QuintoAndar.
We analyzed the current state logic and its transitions across different product flows, identifying variations in behavior and inconsistencies between touchpoints. At the same time, we followed the engineering initiative to implement a State Machine, aiming to centralize status logic as a single source of truth.
This deep dive revealed that many of the issues were not just interface-related, but also stemmed from the absence of a consistent structure connecting user actions to the resulting listing states, affecting both user experience and operational efficiency.
✸ Insight: Lack of unified logic → same action produces different outcomes → unpredictable system behavior.
Data analysis
In parallel, we explored product data to measure the impact of the problem.
We observed that approximately 70% of bugs were related to listing status management, highlighting high complexity and fragility in this layer of the product. We also identified inconsistencies across flows and touchpoints, as well as indirect signals of friction, such as increased support tickets and recurring difficulties in managing listings.
These insights confirmed that the lack of standardization and clarity was not an isolated issue, but rather a systemic challenge requiring a structured solution.
✸ Insight: Structural problem, not isolated → impacts product stability.
INTERNAL TEAMS
To complement the analysis, we conducted discussions with operations and support teams, who deal directly with user questions and issues on a daily basis.
These conversations helped identify the main reasons why listings were deactivated, uncover behavior patterns, and reveal recurring difficulties in interpreting statuses. They also highlighted the lack of context users faced when making decisions about their listings.
This alignment was essential to connect quantitative data with operational realities, deepening our understanding of the problem from both the business and customer support perspectives.
✸ Insight: Users often deactivated listings without fully understanding consequences.
Heuristics Adopted
✸
Clarity of states and actions
Users must understand Pause vs Deactivate.
✸
Safe control
Users maintain autonomy with mechanisms to prevent critical mistakes.
✸
Consistency across the experience
Predictable behavior in all flows and touchpoints.
✸
System alignment
Interface reflects state machine logic.
✸
Transparency of consequences
Each action communicates its impact.
PROBLEM REFINEMENT
Lack of unified logic + missing context turned a simple action into a complex decision, directly impacting experience and supply health.
product strategy
✸
Defined states
Pause (temporary): reversible, ideal for momentary situations.
Deactivation (permanent): removes listing from the platform, requiring a deliberate decision.
✸
Guiding principles
Transparency: make the outcomes of actions explicit.
Reversibility: allow temporary decisions to be undone.
Guidance: support user decision-making, reducing uncertainty.
✸
Trade-offs considered
Complexity vs. clarity: two states increase understanding and reduce ambiguity.
Strategic friction in critical actions: confirmations prevent impulsive decisions.
State Structure (Macro Flow)
We defined three main listing states: Active, Paused, and Deactivated. Each state clearly reflects the property’s availability on the platform and has well-defined transitions aligned with the state machine, ensuring that any user action results in predictable and consistent behavior. This structure serves as the foundation for the entire experience, reducing ambiguity and preventing inconsistencies across flows and touchpoints.
FLOWS
Pause vs Deactivate Choice
To simplify critical decisions, we introduced a clear choice between Pause (temporary) and Deactivate (permanent). Each action is presented with explanations of its impact:
Pause: ideal for momentary situations, reversible, and does not compromise supply metrics.
Deactivate: a permanent action with explicit consequences for the listing’s visibility and availability.
This differentiation not only guides users to make the right choice but also increases safety and predictability, reducing errors and impulsive decisions.
Pause Flow
The pause flow was designed to be fast and reversible, with minimal friction. Users can quickly pause a listing and reactivate it easily when needed. The interface prioritizes simplicity, highlighting the benefits of the action while avoiding cognitive overload, allowing temporary decisions to be made without unnecessary barriers.
Deactivate Flow
The deactivate flow was structured for high-impact decisions, focusing on clarity, context, and supply protection. It includes:
Explanations of the consequences of deactivation, ensuring conscious decision-making.
Collection of the deactivation reason, enabling future insights into user behavior and product improvement opportunities.
Strategic friction through additional confirmations, reducing the likelihood of impulsive actions and reinforcing the importance of the decision.
This approach ensures that even in high-stakes actions, users fully understand the consequences, while the platform maintains a healthy balance between supply, experience, and business metrics.
REASONS
Macro reasons for deactivating
To define the deactivation reasons, we aligned with internal operations and customer support teams. From these discussions, we identified the most frequent reasons reported by users. Together with these teams, we structured the reasons into macro categories to improve organization and discoverability within the flow.
The reason “I have already sold the property” was not included, as the platform already has an endpoint that automatically deactivates listings once a property is sold.
Sub-reasons for deactivating a rental listing
Deactivation reasons in the rental context were grouped into three macro categories: no longer interested in renting, already rented, and unavailability to manage the property.
In the latter, related to availability, users are guided to a pause flow, a temporary solution that allows the listing to be retained on the platform while they are unable to proceed.
Sub-reasons for deactivating a sale listing
In the sale context, reasons were grouped into two macro categories: no longer interested in selling and owner unavailability to proceed with the process.
In the latter case, users are guided to a pause flow, following the same approach defined for the rental context.
Bad experience sub-reasons for deactivating
We identified, based on recurring support interactions, that reasons related to negative experiences with QuintoAndar apply to both rental and sale contexts.
deactivation
pause
design decisions
Intentional Friction
Deactivation is a high-impact action.
We use a double confirmation step to validate this destructive action before completing the deactivation or pause.
The system guides the user based on the selected reason. The guided flow increases predictability of decisions.
Cognitive Load Reduction
This approach helps reduce errors, increase active listing retention, and maintain overall marketplace balance.
UX as a Supply Metrics Lever
Deactivation Reason Structure
Clear grouping → better data quality and more accurate decisions.
Pause vs Deactivate Differentiation
Scenarios guide the correct choice → aligns user behavior with product goals.
validation
Information architecture
Card sorting → Validated grouping of reasons.
The study was distributed via Maze to our user base by email, and the feedback validated our proposed solution—especially regarding the grouping and discoverability of deactivation reasons.
This was essential for moving forward confidently to the solution handoff.
Pause & Deactivate flows
Measured task completion and friction.
Pause → easy
Deactivate → intentionally higher friction
In the same Maze test, we evaluated both pause and deactivation flows. We were able to analyze the funnel, identifying drop-off points and completion rates. Based on these insights, we concluded that the proposed solution met our expectations.
✸
Behavior (leading)
Pause vs Deactivate selection rate
Flow completion
Abandonment
Average completion time
Decision switching frequency
Metrics & Impact
✸
System & operations
Status-related bugs
Flow inconsistencie
Support tickets
Resolution time
✸
Decision quality
Improper deactivations
Reactivations
Reason distribution
Consistency reason → executed action
✸
Business (lagging)
Active listings
Listing retention
Pause vs Deactivate ratio
CONCLUSION
Clarity reduces errors and support demand.
Guidance prevents impulsive permanent decisions.
Structure influences behavior.
UX can address backend system issues.
Guidance: full freedom → predictable experiences aligned with product.
Learnings
Complete interface state standardization.
Automated Pause/Deactivate recommendations.
Notifications for long-paused listings.
Evolve reason collection: product insights.
Dashboards for continuous metrics monitoring.