PLATFORM STATUS/CLIENT
Always be in the loop for your favorite apps.
Role
Product Designer
Product Designer
Team
1 Product Designer
4 Developers
1 Product Designer
4 Developers
Tools
Figma
Notion
Slack
Figma
Notion
Slack
Timeline
September 2023
September 2023
Summary
The Platform Status Page was created to enhance transparency and communication between our products and our 15,000+ active users. This dedicated platform provides real-time updates on the status of our services and applications, ensuring that you're always in the loop about any ongoing maintenance, issues, or improvements. I was the sole designer helping the project go from 0 to 1.
GOAL
An Informational Platform That...
Enhance transparency
We want to provide users with real-time updates on the status of our services and applications and establish a clear channel for notifying users about maintenance, issues, or improvements.
Feedback
Sometimes, we do not catch the issue before our users do, so we want to create a way for our users to report any issues that they are having on our platforms.
PILLARS & VALUES
An User-Centric Approach
Clear Information Hierarchy
Information is organized in a clear hierarchy, with the current status for all applications prominently displayed.
Real-Time Updates
Let the user know that we are always on top of our game. The platform should provide users with the latest information.
Notifications
Make sure that the user can always be in the loop as soon as an update occurs.
Mobile/Tablet Responsiveness
Ensured the status page was accessible and usable on various devices.
LAYOUT & FOUNDATIONS
Structure that Prioritizes What Is Important to Our Users
01 - Overview
In most cases, users get on the status page to view status rather than to report a bug. Therefore, a general overview is essential for quick glance access to our statuses.
02 - Subscribe to Status Update
On the other hand, subscribe to status update is a core goal of ours, as stated above in our user-centric approach. We want to keep users in loop with out updates, therefore that should be a priority as well.
03 - Submit a Bug
If our team did not catch a bug before the users did, then they can use the report form to let us know that there is a problem - ideally, this is the minority of cases.
To prioritize subscribe for updates form, I decided to keep it sticky on scroll. Therefore the user will always have access to it even when the other cards are scrolled out of the screen.
In contrast, people who get on the platform to post about bugs already know that they want to post about bugs, therefore, making the report bugs form sticky is less beneficial compared to the notifications form.
Prioritize by Outage Severity
Most of the time, users will only check the status page if something is wrong. Thus, the first thing that they would want to look at when they get on the platform is whether or not the app that they are using has an outage. If it does, then it should be identifiable immediately.
Prioritize Glanceability Over Details
Overview on Left
The benefit of having Overview on the left side is that in the case multiple apps have outages, the user can immediately know whether or not their app is down without having to scroll through the cards.
Overview on Right
The benefit of having Overview on the right side is that it leaves room on the left for what the user cares about, the detail description of the statuses. In the case of single app outages, the user can immediately identify the cause.
Between the two options, I proceeded with keeping "Overview" on the left side for glanceability, emphasizing the overall health of our apps because most users have multiple AppDev apps. Increasing glanceability in this case will mean that users can quickly identify the status of multiple apps that they use daily.
STATUS CARD DESIGN
The Essential Informations An User Would Need
To Hide Or Not To Hide?
The benefit of having expand/collapse for Cards is to reduce clutter. If each card's timeline and bug reports are hidden, then it will be easier for the user to scroll through the apps. However, the negative is that the user will now have to perform an extra step to view the detailed status.
Ultimately, I decided to save the user an extra step: since AppDev only have around eight apps, and with most functioning at any given time, the primary benefit of reducing clutter is not too useful. On the other hand, we saved users a step to view why the app is down.
Ultimately, I decided to save the user an extra step: since AppDev only have around eight apps, and with most functioning at any given time, the primary benefit of reducing clutter is not too useful. On the other hand, we saved users a step to view why the app is down.
Timeline Base Unit - By The Hour
Having the base unit of timeline as days is simply not enough. For our more popular apps, there are thousands of users relying on our app for time-sensitive issues. Therefore, we will need to be more specific.
Originally, I thought about combining the days and hours unit together in the same timeline, but through user testing, I learned that different bar thickness is confusing when paired with different bar heights. Therefore, I prioritized consistency and detail by choosing the hour unit for Timeline.
Originally, I thought about combining the days and hours unit together in the same timeline, but through user testing, I learned that different bar thickness is confusing when paired with different bar heights. Therefore, I prioritized consistency and detail by choosing the hour unit for Timeline.
INTERACTIONAL DESIGN
Delightful Experiences
Timeline Hover State
Hover state and animation for status cards
Combined hover state for better interaction
Button Hover State
Form Interactions
Selection Highlight
A 2px thick border indicates the selected typable cell.
Safer Warnings
Despite the CTA button being grayed out indicating that it isn't clickable, warning messages gives an explicit message on why the form cannot be submitted.
Shaking Warning Message
Upon clicking submit twice with failed attempt, the warning sign shakes to let the user know that something is wrong. The explicit shake prevents the user from overlooking the message.
Success State & Resubmit
A confirmation state to let the user know that their request did indeed go through, and another entry point to the form for easy access.
Loading States
For better experience in low connection regions.
ACCESSIBILITY
Seamless Experience for Everyone
Multi-size Timeline Blocks
Instead of displaying only color for the timeline blocks, different heights for different statuses provides better context to those who are color blind.
Robust Colors for Any User
By selecting a darker green, medium darkness yellow, and bright red, I ensure that our colors are digestible even for individuals with complete colorblindness. Beyond these design choices, AppDev Platform Status passes AA and AAA contrast tests.
Text + Iconography = Ideal
The combination of text and icons provides a more explicit and easy to understand message.
RESPONSIVENESS
Designing for All Screen Sizes
Responsive Status Card
Status Cards adapt to different width until they reach a certain breakpoint. In this case, the spacing between the Timeline blocks remain the same, while each individual block changes width. As the screen size gets smaller, the displayed time progressively decreases from the past 72 hours to the past 24 hours.
Rethinking Usability on Touch Screens
Instead of displaying all of the Status Cards at once, touch screen devices will only display one at a time. This prevents the user needing to scroll a long time before they find the app that they are looking for.
VISUAL DESIGN
Detail Matters
Border Thickness Variety
Instead of having the same border thickness for both states, selected has an extra boost to indicate that a certain cell is selected.
On the other hand, warning border should not be confused with selected, thus it is covered with a thinner 1px border.
On the other hand, warning border should not be confused with selected, thus it is covered with a thinner 1px border.
Highlight Color
Conventional design pattern uses the organization's brand color for their select highlight, but it does not work here. For AppDev, Ruby (brand) is incredibly close to the color of Failure, therefore I adjusted the highlight color to one that is completely different from Ruby while maintaining a similar value.
Form UI Modifications
Form Submission Textbox color changed from gray to white with border because gray is too close to the CTA button. At the same time, the tag names became darker and the template type became lighter to better enhance visual hierarchy.
Card UI Modifications
The color of the bug information box changed from gray to off-white to better distinguish the gray from the form CTA's gray. At the same time, I made a trade off to lighten the color of the font to make it look visually seamless while losing AAA accessibility check. Despite the change, the form still adhere to AA standards.
More Stable Status Tags
The status tag changed from a smaller tag on the top left to a filled to width center card to make the card feel more stable and grounded on smaller screen sizes.
Design System
As AppDev’s web design system exists, it would be redundant to create an entirely new design system for this project. Instead, custom components were designed on a per-need basis.
Design System: Spacing
Adaptable spacing changes for different screen sizes to maintain form and consistency.
FINAL EXPERIENCE
Seamless Experience for When It's Needed The Most
The current site is still under construction, come back later to experience it out yourself!
