At ParkHub, we built an iPad app to enable our clients to manage their parking lot operations while out in the field. Below is a description of the design process Notifications functionality within the app.

The Problem

In our iPad app for managing parking lot operations, we needed to surface timely notifications so that users could take immediate action on those notifications.

The Team

The Product Team consisted of four people; two designers (myself and our Chief Product Officer) as well as two Product Managers. We collaborated closely with our Dev team to find appropriate compromises based on our time constraints.

• 2 Designers (myself and the CPO)

• 2 Product Managers

• 2 iOS engineers

Original Design

Our CPO came up with a first pass at these designs, which was a full-page design which lived alongside the other pages in our tab navigation.

The Pivot to Native

While the above is visually appealing, our iOS devs informed us that building out these custom components would increase the dev time, they recommended that we utilize native iOS components instead.

v2: Using a native iOS “pop-over” component

The first pass of the new native design incorporates blue "unread" dots and a “swipe to mark as read” interaction pattern, as can be found in Apple Mail (2021)

In hopes of discovering the most user-friendly implementation of notifications, I audited other apps similar functionality. Personally I found that the Facebook Mobile (iOS) notification implementation implementation most simple and easy to use; blue highlight means unread, and to mark as read one must click on it or click “mark all as read” in the options menu.

v3: Simplified elements and no swipe action to mark as read, user must click to mark as read.

Additionally, this simplified design reduced the height of each individual notification element, since the previous swipe-out pane was a limiting factor for minimum height.

Comparison between the v2 and v3

Before → After

Here’s a comparison between our first and our final iteration which ended up being built by our devs.

Moving the notifications into a smaller pane allows the user to view their notifications without leaving their current view, which is especially helpful for operators in the field who are trying to keep a close eye on patterns such as parking peak times.

This also resulted in a simplification of our main menu (previously on the left side, now on the bottom) which allows users to more easily switch between data views (in the tabs) whereas the non-data views (or the tools) live in the top right toolbar.

Outcomes

Our close collaboration with engineering allowed us to build and ship the notification feature in a fraction of the time as it would’ve taken had we kept the original design. This is an example of how collaboration resulted in a better outcome than if design had dictated to devs without any feedback.

Drawn in Notability for iPad

Considerations for the future

In the spirit of continuous iteration, below are a few thoughts of how this feature could be further extended.

These would need to be validated with user research, to determine if these actually meet our users' needs.

• "Snooze" or "Remind me in x minutes" functionality to help users avoid in-the-moment distractions but circle back to the notification at a later time

• Extendable "done" statuses for specific notification types

  • For example: "Resolved" vs "Cancelled"

• Do more complex notifications necessitate the need for an "expand notification" pattern?

  • Would this take the use