The Problem

Divemap had grown through iterations — features added as the platform expanded, each one solving an immediate need without reference to a shared design language. The result was a product that worked functionally but asked too much of its users.

Interaction patterns changed from screen to screen. Icons spoke different visual languages depending on which page you were on. Mobile users encountered controls designed for desktop tables — pagination selectors, per-page dropdowns, compound card titles that wrapped across two lines before showing the information being looked for. A first-time visitor couldn't be confident that what they'd learned on one screen would transfer to the next.

The friction wasn't catastrophic. But a platform built around community and discovery — one that depends on users coming back regularly to log dives, find sites, and browse trips — can't afford an interface that gets in the way of the thing it's supposed to be doing.

The Solution

The redesign focused on three things: establishing a consistent design system, replacing desktop-web conventions with mobile-native ones, and creating a clear visual hierarchy on every screen.

Rather than redesigning for visual novelty, every change was grounded in a specific usability problem identified in the audit or confirmed in conversation. The goal wasn't a different-looking Divemap — it was a more coherent one.

Key Concept - A Unified Design System

The most impactful decision was not a single screen change but a system-level one: establishing a consistent color, icon, typography, and component language that applies across every page. This was also the first decision made, because without it every subsequent screen change would have been solving a symptom rather than the cause.

One primary blue. A single brand blue (#1677FF) is used for all primary actions, active states, links, and key UI elements — replacing the scattered use of multiple blues, navys, and teals that coexisted without logic.

One icon style. All icons use the same outlined stroke style at the same weight, replacing a mix of filled, outlined, emoji-based, and multi-colored icons that gave each page a different visual personality.

One card pattern. Every list card — dive trip, dive site, diving center, or dive log entry — follows the same structure: title on the left, status badge on the right, metadata in a labeled grid below, "View Details →" in the footer. Users learn the pattern once and can scan every list in the platform.

One mobile navigation pattern. Load more replaces pagination. Segmented controls replace ambiguous status chips. Filter icons replace emoji rows. These patterns are applied consistently across all six list screens.

These four rules resolved more individual design questions than any other single decision in the project.

What Success Looks Like

Since this is a live product, the impact of these changes should be measurable. The metrics I'd prioritize to evaluate the redesign are:

Task completion rate for core flows: finding a dive site by location, and logging a dive from the dive log screen. Both are primary jobs-to-be-done that the original interface complicated unnecessarily.

Time on task for first-time users navigating the hamburger menu to find a specific section. The original flat list with no hierarchy made this a scanning exercise; the restructured version should reduce it significantly.

Bounce rate on the homepage, as an indicator of whether the single primary CTA successfully directs new visitors into the product rather than losing them to indecision.

Rating submission rate, as a proxy for whether the five-star system is more approachable than the shell emoji system it replaced.

The User

Two user types, one platform.

The primary user is a diver — recreational or technical — who uses Divemap to discover new sites, log their dives, browse community content, and find upcoming trips. They're often on mobile, before or after time in the water, and expect an interface that gets out of their way quickly.

The secondary user is the diving center operator, who lists services, creates trips, and connects with the community. For them, clarity of administrative actions matters as much as the browsing experience does for divers.

Both share one expectation: an app that works as fluently as the activity it supports.

Accessibility

Accessibility was treated as a design constraint, not an afterthought.

The primary blue (#1677FF) was evaluated for contrast ratios against white and against all companion colors in the interface. A secondary sky blue (#69B1FF) was selected specifically for its contrast against the primary blue, ensuring the two-tone palette remains distinguishable for users with deuteranopia, protanopia, and tritanopia.

The multi-color icon system — where each icon had an arbitrary background color with no semantic logic — was identified as a direct accessibility barrier and replaced with a single unified style throughout.

Star ratings replaced shell emoji ratings, removing reliance on a symbol with no universally understood meaning. Changing from a 10-point to a 5-point scale also reduced the cognitive precision required to assign a rating — which lowers the barrier for users with cognitive differences, not just those with visual impairments.

Homepage - Before

No clear primary action on the homepage meant users arrived without a natural next step. Three equal-weight buttons created a decision before users had formed an intent, and feature cards with arbitrary icon colors provided no visual cue that they were interactive.

Homepage - After

A single "Browse Map" CTA establishes a primary path. Feature cards are unified in color and carry explicit text links, signaling interactivity. The statistics section moves from an off-brand navy to the primary brand blue, integrating it into the visual system for the first time.

Navigation Menu - Before

A flat list of 8+ items with no visual distinction between parent categories and sub-pages required users to scan every item on every visit. Login and Register appeared at equal weight with no hierarchy between them.

Navigation Menu - After

Five top-level items with collapsible sub-sections. Child items are visually anchored to their parent through background contrast and indentation. Chevrons communicate open and closed states. Register is the filled primary button; Login is the secondary outline — hierarchy reflects the desired action.

Map - Before

A title row and a selector row consumed the top of the screen before the map began. Seven unlabeled icons with arbitrary orange and green backgrounds gave users no way to predict what each control would do.

Map - After

Title and selector rows removed. Four labeled toolbar items replace seven unlabeled icons. Wind and location controls float over the map as dedicated buttons, following established map interaction conventions.

Dive Trips - Before

Card titles led with the diving center's name rather than the destination, meaning users had to read to the second line before finding the information they were actually scanning for. FUTURE and ARCHIVE status chips borrowed from desktop table conventions that carry no meaning on mobile. Desktop pagination interrupted the browsing flow.

Dive Trips - After

Cards lead with the dive destination. Upcoming and Past trips are separated by a segmented control. "Load More Trips" replaces pagination. Metadata icons are unified to primary blue.

Diving Centers - Before

Inconsistent title casing across center names (some all-caps, some title case) created an impression of unmanaged data. Contact buttons in three different background colors added visual noise with no semantic meaning.

Diving Centers - After

All center names in consistent title case. Contact icons unified to the outlined style. A single "+ New Center" button replaces the competing double-button layout. A circular image with the center's logo was added.

Dive Log - Before

Three action buttons stacked in the header with no clear priority meant every return visit to the dive log required the same visual parsing. Emoji-based filter icons rendered differently across devices and carried no labeled meaning.

Dive Log - After

One primary "+ Log New Dive" button and one secondary "Import Dives" link replace the three-button header. A single filter icon replaces the emoji row. Certification level appears as colored badge for quicker iteration. The Filters screen was redesigned in a way that allows the user to read and understand the different filters more intuitively rather than making choices on dropdown menus.

Dive Sites - Before

Cards mixed site name and location on the same line with an "@" separator, making both harder to read. Tags used arbitrary multi-color pills with no consistent system. The shell emoji rating with no scale reference asked users to interpret a symbol before reading a number.

Dive Sites - After

Site name and location are clearly separated into distinct visual roles. Tags use a consistent outlined pill style. Ratings display as ★ 4.2 on a universally understood five-point scale.

Reflection

Working on a live product is a different discipline from designing from scratch. The constraints are real — existing data structures, an established user base, a developer whose priorities don't always align with design ideals, and a codebase that can't be thrown away because the design system has changed.

The navigation is the clearest example of this. I identified it as a high-friction area and proposed a restructure that I believe would meaningfully improve the experience for new users especially. The stakeholder chose to retain the current structure. That's a legitimate outcome — design recommendations aren't always implemented, and knowing how to make a case, accept a decision, and move on is part of the job. The screens reflect my proposed direction, and the conversation about navigation remains open.

The breadcrumb situation taught me something more nuanced: not every desktop convention that appears on mobile is a mistake. Sometimes it's a trade-off. SEO value for a platform that lives or dies by discovery is not an aesthetic concern — it's a business concern that a designer working on a real product has to weigh. The right answer wasn't "remove the breadcrumbs because mobile convention says so" — it was "keep them, acknowledge the tension, and make sure they're as visually quiet as possible."

What comes next: the design system established here is intended to scale. New screens, new features, and new content types should slot into the existing patterns without requiring another audit. The immediate priority I'd recommend is applying the same system review to the authenticated screens — account, profile, and messaging — which weren't in scope for this phase but carry the same inconsistencies the six redesigned screens had before this work.

This is an ongoing project. Screens shown reflect the redesign as of August 2026.

Research & Audit

I conducted a screen-by-screen audit of the existing experience — homepage, navigation, map, dive sites, dive trips, diving centers, and dive log — cataloguing every instance where the interface contradicted itself or borrowed conventions that didn't belong on mobile.

To complement this, I ran four short informal interviews (20–30 minutes each) with people in my network with diving experience: two recreational divers who use similar platforms, one diving instructor, and one diving center employee. These weren't formal research sessions but structured conversations focused on how they currently discover dive sites, plan trips, and log their dives.

Key things I heard:

"I just scroll through until something looks interesting — there's no obvious starting point." — No clear hierarchy of actions meant users defaulted to passive browsing rather than directed discovery.

"I can never remember if I need to tap the icon or the text — they don't always both work." — Inconsistent interactive affordances eroded trust in the interface over repeated use.

"I close the app and Google it instead." — When the friction of navigating a list exceeded the effort of leaving the platform entirely, users left. The most telling feedback isn't what people say about the interface — it's what they do instead.

Design Principles

Three principles shaped every decision in the redesign:

Mobile-native over desktop-adapted. The platform is a website experienced as a mobile app. Every convention borrowed from desktop — pagination, compound card titles, search bars dominating the nav — was evaluated against how it would perform at 390px width and replaced with a mobile-appropriate equivalent.

One semantic system over many decorative choices. Color, icon style, and card structure are not aesthetic preferences in this product — they are communication tools. Every divergence from the system creates a question in the user's mind about whether the divergence means something. It shouldn't.

Familiar over invented. Where a universal convention exists — star ratings, load more patterns, floating map controls — it was used rather than replaced with something original. Cognitive load spent learning a custom pattern is cognitive load not spent on discovering a dive site.

Design Decisions

Homepage: removing the competition

Three equal-weight buttons below the hero meant users landing on the homepage faced a decision before they'd formed an intent. There was no clear answer to "what should I do first?" — and when everything is equally important, nothing is. The redesign reduced this to one primary CTA ("Browse Map") with feature cards below serving as a navigable secondary layer. Users with a specific goal can act immediately; users who are exploring have a clear invitation to do so.

Navigation: a stakeholder constraint

The hamburger menu held 8+ items in a flat list with no hierarchy between parent and child levels. I proposed restructuring it into five top-level items with collapsible sub-sections, rotating chevrons to communicate state, and visual anchoring of sub-items to their parent through indentation and background contrast. This was implemented in the redesigned screens. However, the platform owner and developer preferred to retain the current navigation structure — so this remains a proposed direction that may be revisited in a future collaboration, rather than a confirmed change.

Breadcrumbs: a deliberate exception

Breadcrumbs are unusual on mobile — they create visual noise and are rarely how mobile users navigate back. However, Divemap is a website experienced as a mobile app, not a native application. Removing breadcrumbs would have cost the platform meaningful SEO value for its dive site pages, which are indexed individually by country and region. They were kept as a conscious trade-off between mobile UX convention and a legitimate business need.

Map: give the map the screen

A title row and a selector row consumed screen real estate before the map even began — the product's most spatially distinctive feature was competing with its own UI chrome for space. Removing both rows and consolidating controls into a labeled four-item toolbar gave the map the screen it needed. Wind and location controls moved to floating buttons overlaid on the map itself, following the convention established by Google Maps and Apple Maps so users didn't have to learn a new pattern.

Cards: lead with what users are looking for

Dive trip cards titled "Diving Center Name — Date" put the organizer before the destination — but users browsing trips are primarily asking "where can I dive?" not "who is running it?" Restructuring the card hierarchy to lead with the dive destination immediately answered the question users were actually asking before they had to read further.

Rating system: universal over custom

A shell emoji with an unlabeled number required users to understand two things simultaneously: what the shell represents and what scale the number is on. A five-star rating with the score (★ 4.2) communicates both through a single universally understood convention. The scale also changed from 10-point to 5-point — a 10-point scale implies a granularity of judgment that users don't actually apply, and numbers like 6.5 read as negative to anyone conditioned by school grading systems.

Pagination: scrolling is native, page-jumping isn't

Desktop-style pagination with per-page selectors on a mobile list asked users to think about data management rather than content discovery. "Load More" is native to how mobile users expect to consume lists — it requires no decision, no mental model of pages, and keeps the user in the flow of browsing rather than pulling them out of it.