How long does it take me to come up with a design? Well, as you can see in the gap in posts, the answer seems to be a week. I started the week with the totally wrong assumption that designing the error management page would take me two days tops.
Design is not a quick process
After two days, I hadn’t even wrapped my head around the direction I wanted to go with the design. I was still exploring patterns, how other products used them and which ones were relevant to Helthe.
While I had some hand drawn sketches to work with, transforming those sketches into mockups was not easy at all in the end. I am not a quick with CSS as I am with regular code.
False needs
In my previous post, I discussed the needs of the user. After some reflection, I concluded that there were three needs that were not needed currently. So I made some additional cuts to simplify things. Those were:
- He needs to be able to see if that error is assigned to anyone.
- He needs to be able to assign the error to a team member.
- He needs to be able to comment on the error.
All these features are collaborative in nature, but as I sketched and mocked them I had difficulty seeing their need in the current product state. I had a friend do a quick review of an early sketch and he also told me that they were not needed at the moment.
The main issue is that collaboration needs like commenting and assignment are only useful to the user if they integrate with the tools that the user is using. The user does not need another application to check for comments, assignments, etc. It needs to integrate with the tools the user is already using.
Could I be that tool? Maybe, but it seems premature to think so. It can be added to the product at a later date.
So I decided to cut the features till I could think of them in the context of the 3rd party integrations.
Navigation requires its own scope
This is something else I realized along the way. I was working on mocking up the navigation (like a breadcrumb), but I found it really hard to do so without having multiple pieces to put together.
You have to really think about the user flow and how users will be moving from screen to screen. With just the error screen, I had a really hard time visualizing it.
This might also be due to inexperience on my part, but I felt better moving it into its own scope to be dealt with later.
Current Design
As of this afternoon, this is the current design of the error management page. I want to share some of the design decisions that I took. As I mentioned in my notes previously, there’s two jobs that this screen needs to accomplish. Those were:
- He got a new alert and wants to get further details so that he can properly evaluate its severity and possibly assign it to a team member.
- He got assigned the error (or came on his own) and is here to solve it. He needs to have all the information required to reproduce it so that it can be fixed.
Header
The header section is dedicated almost exclusively to the first job. At a quick glance, the user is able to see all the important information about the error.
The user can do the quick operations that I had highlighted in my notes and he also has access to the big picture details.
Using colours
The most important design challenge for me was that I wanted the user to be able to determine the error severity very quickly. Early on in the design process, I decided to use a colour scheme to communicate that.
When a user lands on the page, he immediately sees the coloured border next to the error text. The error text is the first thing the user will read, but the eye is quickly drawn to the coloured label right underneath the error text. That label tells the user the error type.
As I was iterating, I wanted to reinforce this colour scheme further and I thought that the tabs was a place to do it. This adds a reminder as the user is scanning down to the different sections. It also keeps the whole palette consistent for the page.
The result is that, when the user lands on the page, he will immediately know the severity of the error in question.
Snooze
I renamed the ignore error button to snooze. That was suggested to me by a friend during an initial review. I liked the term a lot. Snooze implies a temporary respite before you become alerted again which is really what users want to do usually.
What I also liked was that snooze is based on rules which can be very open-ended. As the product involves, it could be a timeframe (a week), till the next deploy (once I track deploys) or indefinitely.
Overall, it’s a small detail, but one that I felt brought a lot of clarity to the user.
Recent activity
Sentry has this and I thought it was very important to incorporate it. When someone comes here, they need to know what has been happening quickly. Recent activity is a pattern that allows for this. On top of that, it is very flexible. Since anything can be an activity.
Bottom section
I did some work on the bottom section. The summary has roughly all the information you would need, but will probably need a bit more polish once I started wiring the application code. I am not 100% sure that the “reported at” timestamp should just be in the table.
I didn’t style the trace or any of the other tabs yet which might require a bit of time, but I am going to wait a see what the data and the output looks like to begin.
Off to the lower layers
Now that the majority of the design is wrapped off, I am moving on to the lower layers to finish off the error management scope.