Quickly Access Recent and Frequent Contacts from Search
Coordinators frequently access the same small set of active contacts and peer mentors during periods of intensive coordination. Displaying a 'recent contacts' or 'frequent contacts' section at the top of the search screen before any query is entered reduces navigation time for repeat access patterns. This section is populated from client-side interaction history stored locally, respecting the same privacy and encryption constraints as the offline cache. Tapping a recent contact navigates directly to the contact detail screen, bypassing the search results list entirely. This interaction pattern aligns with the project's core design principle of minimizing cognitive load and reducing the number of steps to accomplish common tasks.
User Story
Audience Summaries
This story delivers measurable efficiency gains for coordinators managing high-volume contact interactions. For organisations like HLF — where a single peer mentor may accumulate hundreds of activity registrations annually — reducing the steps to reach a frequently-accessed contact from three or more to a single tap compounds into significant time savings across a coordinator's workday. By surfacing recent contacts before any query is entered, the platform reduces cognitive load and friction, directly supporting the core design principle of minimising unnecessary navigation. This translates to faster coordinator response times, higher satisfaction with the platform, and stronger adoption rates among the most active users of the system.
This medium-priority story has a well-scoped, self-contained delivery footprint with a dependency on the base contact search story (story-contact-and-notes-search-coordinator-001). Effort is primarily frontend-focused: local interaction history tracking, a 'Recent' section UI component, and settings integration for history clearing. No backend changes are expected since data is stored client-side. Acceptance criteria are clearly defined with five scenarios covering empty state, tap navigation, partial history, clear history, and query transition — all testable in isolation.
The main delivery risk is ensuring the local storage mechanism respects the same encryption and privacy constraints as the offline cache. QA should verify behaviour across app restarts and low-storage conditions.
Implementation involves adding a client-side interaction tracking layer that records contact view events (contact ID + timestamp) in local encrypted storage, capped at the 5 most recent unique entries. The search screen component needs conditional rendering: when the query input is empty, display the 'Recent' section populated from local history; when a query is active, replace it with live search results. Tapping a recent contact must trigger direct navigation to the contact detail screen via the existing navigation stack, bypassing search result intermediary screens. The settings screen needs a 'Clear recent contacts' action that wipes the local history store.
Key technical considerations: deduplication of repeated views of the same contact (only most-recent timestamp kept), graceful handling of contacts deleted from the database (stale entries should be filtered), and ensuring the encryption key lifecycle matches the offline cache implementation.
Acceptance Criteria
- Given the coordinator opens the search screen with no query entered, when the screen renders, then up to 5 recently viewed contacts are shown in a 'Recent' section
- Given a recent contact is tapped, when navigating, then the contact detail screen opens directly without requiring a search query
- Given the coordinator has viewed fewer than 5 contacts, when the recent section is shown, then only the contacts actually viewed are listed (no placeholder entries)
- Given the coordinator clears their recent history (via settings), when the search screen is opened, then the recent section is empty or hidden
- Given the coordinator types a query, when search results appear, then the recent contacts section is replaced by live search results
Business Value
Reducing the number of interactions needed to reach a frequently-used contact directly reduces cognitive load and time spent on navigation — a key design principle identified across all three organizations. For HLF, where a single peer mentor may have had 380 activity registrations in a year, coordinators managing active peer mentors benefit significantly from instant access to recent contacts without re-entering a query each session.