Category Archives: Design

Finalizing Error Management Design

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

Early Bootstrap Mockup
Early Bootstrap Mockup

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

View Error : Helthe
Near Final Mockup

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:

  1. 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.
  2. 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.


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.




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.

Notes on error management design

In my previous post, I described the process I would be taking to continue the development of Helthe. We concluded that the scope of the project that would offer the largest learning opportunity would be the error management piece. The past two days I have been working on design notes for the error details screen that follow partly Ryan Singer’s post on design process. I am editing them and sharing them with you.

What is error management?

One thing that I didn’t do is define what is error management. In the context of Helthe, error management is what allows the user to interact with the collected errors and work with them. The main application screen involved is the error details screen. On the application layer, it involves grouping similar errors together in a useful manner.

Why are they here?

The first thing I did is try to think of all the situation that would lead the user to this part of the system. I came up with the following:

  • Most users will come because they got an alert from the system
    • New Error Alert
    • Error Assignment Alert
  • Some users will come from the dashboard
  • Some users were browsing all the project errors

What are the jobs(s)?

What does the error details screen help with? What is its job? What does it help the user with? This is probably the most important screen for the user. Helthe is supposed to give a lot of value to the user here so what are the jobs that the user expects help with.

I came to the conclusion that when a user comes to this screen, he is here for two different jobs:

  1. 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
  2. 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.

Defining the value for each job

The two jobs are very specific, but there is overlap. I’ll be attempting to define the needs of the user for each job so that product gives the best value possible in each case.

What does job #1 need?

Job #1 describes what is expected of the error details page when some one lands on it. A user that just received an alert needs a good summary with the important information readily available. While the summary needs to be useful to both jobs, users doing job #1 are the ones that need to be 100% satisfied by it.

So a user clicks on the alert email (from desktop or phone), he gets to the error details. What capabilities does he need to do his job? I have tried to order them in order of importance.

  • He needs to be able to see the status of the error (Resolved or Unresolved)
  • He needs to be able to determine the severity of the error
  • He needs to be able to see the error text
  • He needs to be able to determine if this error is new or if it is a regression
  • He needs to be able to ignore the error because it can’t be fixed now
  • 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 know when it happened (First Seen/Last Seen)

This is quite a few items, but the user needs to be able to discern all of them easily at a glance even on a mobile device.

What does job #2 need?

So a user that is looking to solve an error, what does he need to do his job? A lot of what was described in Job #1 is useful initially, but he needs to have additional heavy-duty capabilities to actually resolve the error.

  • He needs to know the URL and HTTP request method that caused the error
  • He needs to know where the error happened (File and Line No)
  • He needs to be able to view and navigate between similar errors
  • He needs to be able to access specific error details
    • Trace
    • Environment Variables
    • Application Context (e.g. User Logged In, Controller, Plugins)
    • Browser Details
  • He needs to be able to mark an error as resolved
  • He needs to be able to comment on the error

Design in the works

I am working on the design of the page. I hope to be able to share the result and how this influenced it soon.

If you’ve liked what I have been writing and want to hear more, you can subscribe to my mailing list here! I have been writing a lot so I am still figuring out how to approach things for the list. You can also keep checking the blog every day if that’s your thing!