The Interaction: Clicking “+ New Bookmark” triggered a downward slide, revealing a URL input field directly above the menu and content area.

The Friction: While it kept the user in context, it caused a significant layout shift. By pushing the entire bookmark gallery downward, it momentarily disoriented the user’s visual anchor point.

Since it is a pretty jarring experience, it was a very easy no for me to take it any further.

The Interaction: This iteration builds on the first by refining the behaviour. Rather than revealing the input field beneath the button, it introduces a popup overlay positioned below it, containing both the input field and the save button.

The Friction: Although this approach does away with the abrupt layout shift from the previous version, the overlay’s placement introduces new issues. Because it obscures both the menu bar and the page title, users may accidentally interact with menu items beneath it. It also removes the ability to quickly verify the page title, which is important for confirming that a bookmark is being added to the correct category.

Overall, this interaction still doesn’t feel right.

The Interaction: This iteration builds on the popup concept from the previous version. Clicking the “+ New Bookmark” button opens a modal that overlays the entire bookmarks area.

The Friction: While this approach feels visually cleaner than the previous hanging overlay – and the dimmed background helps focus attention on the task at hand – it introduces usability concerns given the nature of the app.

Modals are inherently “heavy” – they interrupt user flow, and in a high-productivity tool like MediaPlace, users are unlikely to want to repeatedly open and dismiss windows. Also, because the modal covers nearly the entire content area, it completely hides the user’s existing library of bookmarked cards, removing any useful context.

The Interaction: Clicking the “+ New Bookmark” button reveals an input field that slides out from the right within a fixed container.

What Works Well: Because there’s no modal or page transition, users remain in context. The interaction uses progressive disclosure, revealing the URL field only when needed, and establishes clear cause and effect: clicking the button directly exposes the next required step.

The Friction: While this approach works well overall, some ambiguity remains. The sliding motion may not immediately communicate that this is a new state of the same action, and the slide-out itself can feel temporary – more like a transient UI element than a form that expects completion.

More importantly, the button does not change state: it continues to read “+ New Bookmark” and retains the appearance of a clickable CTA, even though the user is already in that action.

High-contrast state transition: In the final version, I moved away from a static expansion to a dynamic, color-coded workflow. It is a state transformation, not an attachment.

The interaction: When the user clicks “+ New Bookmark” the button expands into a container, with a brand-consistent purple. This draws the user’s attention, as the button morphs itself into an input field and a save button beside it. The focus state and a blinking cursor immediately signal that the system is ready for input.

The “success” state: This is a significant improvement. Upon hitting “Save,” the save button transforms into a green “Saved” state complete with a checkmark.

UX Benefit: This provides instant positive reinforcement. In the previous version, the input just disappeared, leaving the user to look down at the list to verify the save. Now, the confirmation happens exactly where the user’s eyes are already focused. The green checkmark provides “psychological closure” – the user knows the task is 100% complete without needing to scan the list for the new entry.

I decided to finalize this version because:

a) It preserves spatial continuity: The input appears exactly where the button was (not above it, not overlaying it, not offsetting it). The user’s eye doesn’t move from the place.
b) It preserves the visual DNA: The input inherits the visual traits of the main button. It has the same height, same radius, similar padding etc. It expresses that ‘it is the same thing but in a different state’
c) It animates as a morph, not a swap. The main CTA button doesn’t instantly vanish, nor does the input appear from nowhere. The animation morphs itself nicely into an input field.
d) It looks like a stable form container, not a temporary dismissible slide-out UI attachment.
e) It neither obscures the content below, nor does it cause any jarring layout shift.

Layout: Focused on the page title and URL with a small favicon.
The Flaw: I felt the favicon will balance out the text on the card, but it felt too much like the original list. Users still had to read to find what they wanted, which slowed down the discovery process.

Idea discarded.

Layout: Large site preview image with the title overlaid on top.
The Flaw: While it looked beautiful, it lacked context. Users often have multiple bookmarks from the same site, and without a way to categorize them, they couldn’t distinguish between them at a glance.

Layout: I settled on a layout that treats a bookmark like a professional asset. Every element serves a specific purpose for a busy user.
Site Preview Image: Provides instant visual recognition.
Page Title: The primary identifier.
Truncated URL: Offers source verification without cluttering the card.
Date Stamp: A vital reference for users to assess freshness of the cards and maintain them.

Layout: This design amplifies what is previously built in the 3rd iteration. I was overall happy with the previous design but it lacked a few essentials.

Category: I decided to display the category to show where the link is filed (example: Uncategorized or Sports category). It creates a sense of organization and helps users realize if a bookmark is currently “Uncategorized” and needs to be moved to its relevant category.

Status indicator: An indicating dot that comes in 3 colours – green, orange and red – to denote if MediaPlace is able to locate the bookmark at the URL. This is particularly important because a website may change the domain, redirect to someplace else, or either be temporarily unavailable or permanently taken off the web.

Green status: Bookmark is alive at the URL it was fetched from. All’s well.
Orange status: For various reasons, MediaPlace is unable to locate the bookmark at the URL. It could be a temporary glitch, or a soft redirect etc., that’ll provide a heads-up to the user to look into it, if they want.
Red status: Bookmark not available at the URL (such as page not found etc). The user can decide if they want to keep the bookmark, or remove from the system as a maintenance practice.

I did not leave a static card just for viewing – a professional tool needs to be interactive. I designed a ghost overlay that appears on hover to keep the UI clean while providing instant editing capabilities.

On-hover actions:

• Selection Checkbox: allows for bulk actions (moving or deleting multiple cards at once, validating links etc).
• Quick Preview: a time-saver button that lets users peek at a stripped-down version of the content without leaving the manager or opening a new tab.
• Edit Button: the gateway to the right-side panel, where users can dive deeper into tags, notes, and other settings such as moving to a different category, setting up reminder etc.

Design Rationale: By hiding these actions until hover, I reduced visual noise. The user can scan their library peacefully, but the moment they need to act, the tools are right under their cursor.

Since this was a category-wide encryption, it only made sense to make the feature available when a category is clicked. I initially designed a password-protect toggle that sits in the right-side panel – which upon clicking, opens a modal that a user can set their password.

The Friction: A toggle is generally for instant action that take effect immediately. Since the user can’t just turn the security feature on without first creating a password, a toggle did not fit the use case here well.

Also, a modal felt too heavy for a relatively simple action and therefore I dismissed this design iteration after slight deliberation.

In the second iteration, I replaced the toggle with a checkbox and removed the modal in favor of an inline password input field placed directly below it. When users checked the box, they could immediately enter a password to protect the category.

The Friction: While it does work to some extent, there were some layout issues with this design. The password input field need not be visible at all times, as a user may simply not want to password-protect a category all the time. Having a persistent input field when not needed, adds to unnecessary visual noise.

To address the layout concerns, I introduced progressive disclosure. The password input field is hidden by default and only appears when the user checks the “Password Protect” checkbox.

This approach feels balanced because the interface remains clean and uncluttered; and users are guided through the action only when they want to opt into it.

The Friction: While this iteration worked well for enabling protection, it revealed a new issue: there was no clear way for users to remove an existing password. This insight informed the final design iteration.

The final iteration builds directly on the strengths of Iteration 3.

When a user selects the “Password Protect” checkbox, the previously hidden password input field is revealed. As soon as the user enters a password, the Save Password button becomes active. This button includes a downward-facing caret, signaling the presence of additional actions.

Clicking the caret reveals a secondary Delete Password option. This allows users to either:
• Save the newly entered password, or
• Clear/remove the password immediately – or at a later time -without leaving the context of the field settings.

Once the user clicks Save Password, the system provides immediate and reassuring feedback. The button label updates to “Password Saved,” and a green lock icon appears to visually confirm that the category is now secured. A lock icon appears alongside the category in the sidebar, providing visual feedback and helping users quickly distinguish password-protected categories from regular ones.

When a user tries to visit a locked-category, they’re met with the following screen – asking for their password to gain access: