Tag Archives: Product Development

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!

Gearing up for product development

I decided to take a break from the growing an email list course. I have been mulling over some of the issues I had at the end of the Week of Hustle. I think that there is room to improve the concept and make it into a more robust product development framework after you are done.

Let’s review

Blogging and social accountability has been a strong point of the system so I think that should stay. It’s also a good way to share information on how you shape the product and keep things transparent. The issue was really in the planning stage. I had written a roadmap as instructed, but It hadn’t crossed my mind that there would be a design piece at all. That’s because I hadn’t really thought about all the tasks needed for something like “You sign up for an account.”. That sentence doesn’t really reflect all that you needed to do.

So let’s say you want to develop your own software product, what can you do to help with the process? It can be pretty overwhelming as a first timer and you might get bogged down in needless details as well. I still do. All. The. Time. It’s frustrating because you feel like you’re never making progress or not enough.

What are others doing?

Here are two methods I have come across over the past year that I found useful.

Amy Hoy’s doing things backwards

First thing you should do is think of the product in its final state and think of what you need to achieve that. Not in small detail, but in broad strokes. This idea comes from Amy Hoy‘s 30×500 class where she talks about working through a goal backwards starting from the desired goal. She has a great example in her free guide using Frankenstein.

Creating Life

When I first read the guide, I thought that was a very useful mental exercise. I didn’t think about it at the time, but I feel my roadmap actually used that concept pretty well. Needless to say, sometimes we do this naturally, but other times we just drive forward without thinking. You should always try to keep it in mind.

If you follow the guide, she suggest continuing to divide tasks into smaller and smaller pieces. I tried doing that a few months ago and I just thought the result was really overwhelming. You would work your way back after and it was hard to pick which small bit to work on or prioritize.

How Ryan Singer manages products

This bring me to a second useful method. Yesterday, someone posted this video by Ryan Singer on twitter and it wasn’t something quite new to me since he had written a post about it in the past. I just hadn’t thought about it in a while and, even more important, I hadn’t thought about it in the context of Amy’s guide. But I have been looking for a system to help me build Helthe. So I could stay focused and productive.

So to go back to the video, Ryan talks about individual vertically integrated scopes of work… Say what!? All it means that you shouldn’t be dividing your work per role (programming, design, etc.) as we often do, but to think about everything in terms of scopes of work. Scopes could be something sexy like a feature or something less sexy like authentication. I put a screenshot from the video to help illustrate the idea.

Screen Shot 2013-11-20 at 11.55.21 PM

The other important element of the scopes is that they are generally very self-contained. You might have a dependency (like registration depends partially on payment in his example), but what is really nice is that once you have done all the tasks for a scope. It is really done. You don’t have to go back to it. Which is what was missing from Amy’s guide.

Deciding which scope to use is based on learning opportunity. Which scope will force me to ask the most questions about my problem domain and allow me to learn the most about it. As a programmer, we tend to gravitate towards what is the most fun to code or the easiest.

A formal attempt

So let’s try to formalize a system we could use. I would also say that it is probably useful to blog about all of this. Social accountability is a strong motivator. That’s my plan at the very least. I’ll go through my proposed steps using Helthe as an example.

First, I would work backwards from my desired outcome and develop a high level map of what I want to build. Ask yourself what do you need? So Helthe is an application error monitoring service for PHP. What do I need to go in Beta? I came up with this map. You might notice that I don’t have marketing site there. Not sure if it should be or not. It’s not part of the product per say and it’s not something I would want to tackle until I understood your problem domain completely.

Initial Helthe Scope Map

Second, I would find the scope of work that offers the largest learning opportunity. Honestly, I didn’t find this step easy at all. Initially, I thought maybe the dashboard or the project itself, but Helthe is about errors so I decided that the whole error management system (grouping, displaying, etc.) really forces me to ask some tough questions about the domain.

Third, I’d divide your scopes into tasks. They should include everything you need to check off that scope as completed. You can do it without a process, but I would go at it backwards the same way you came up with the map. If you come up with a lot of tasks then it might mean that you need to divide things further at the high level.

Should you do it for every scope right away? I am not sure. It seems to go against the idea that if you are going from the largest learning opportunity, it might impact the task lists for the other scopes as you answer questions about your problem domain. You could probably start with an initial list though.

I purposely left my task list out because I didn’t have time to think it through completely. I also I feel it deserves to be a post by itself (probably my next one). Each scope should be its own post.

All that is left is for you to go through each scope one by one. You’d pick the next scope by continuously asking yourself which one offers the largest learning opportunity.

I’ll be exploring this further

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!

Cooking up a product: The ingredients of success

I’ve been focusing a lot on product development and design lately because I really had no idea what it meant to design and build a product. In a very cliché manner, I went in right with the coding when I started to build my product. Probably a mistake (I have made many so far.), but I think it’s too early to tell. Nothing you can’t recover from, but time was wasted which is always annoying.

What are the ingredients of success?

As I have gathered links and resources on the subject (I keep most of my interesting links curated on Kippt), I found the blog of Amy Hoy a ruby developer who teaches a class on product development. It looks really great, but completely out of my price range at the moment. She has some sample course material online and in it is this gem on the ingredients of success. She defines success when building as product as something that:

  • Sells well
  • Makes your customers happy
  • Feels great to work on
  • Gives you a lot of creative leeway/freedom
  • Fits into your plans to live your life the way you want
  • Produces a good profit
  • Grows in a controlled manner (so you can choose how big to get)
  • Does no harm (to anyone)

Amy Hoy

I have often discussed and pondered on my own motivations for wanting to build a product and I really can’t think of a more concise list of reasons for myself. Any element removed from that list creates a problem.

My first product development book: 4-hour work week

The first book I read that really discussed developing a product was the 4-hour work week by Tim Ferris a few years back. When I read it, the lifestyle he presented resonated a lot with me. Obviously part the appeal of the book is the lifestyle he presents so it’s not exactly surprising.

A friend of mine has several website specializing that does free peer-to-peer apartment marketplaces (think craigslist). He makes some money from Google ads and that has allowed him to travel and not really work in a few years. There’s also plenty of other case studies on the 4-hour blog if you are looking for inspiration.

On a personal note, I never felt comfortable with the idea of selling or making anything just to make money. It didn’t sound like the right way for me to approach this. Eventually, I came to an important conclusion.

As a programmer, craft matters

I never really thought of programmers as craftsmen till I started to read the pragmatic programmer, but it makes of a lot of sense and that’s why this list is probably is more exhaustive than if I made one based on the 4-hour work week for example. In that context, a lot of the elements of that list are relevant only when crafting something where you value the output.

When you take time to craft something, you are always mindful of the end result. This is something that I realized as I programmed more and more. I became increasingly critical of how I did things and making sure I understood conceptually what I was doing. I think this extends to anything really. When I start something, I’m never quite satisfied till I have a solid understanding of the subject.

Do you find yourself putting a bit of extra work just to make sure everything is right and up to your standards? I look back at my time working and I definitely went the extra mile to make sure the level of quality of my work reflected who I was.

So you have a list, where do you start?

So you’re looking at that list, it makes you all warm and fuzzy! Where do you go from here? If you just want to make a product, any product I would look into the Customer Development methodology by Steve Blank. There’s a lot of resources online on it, a lot of books, training products, etc. So much in fact, that it is starting to look a lot like diets. People find unique names to market essentially the same thing (talking to your customers!).

Not a programmer? Intimidated? Understanding your customers does not require programming knowledge. Just empathy. Outsourcing your development is a touchy subject (especially as a developer!) that warrants its own post, but it is possible. My friend with the apartment marketplaces uses an outsourced developer (he’s a business graduate). If you’re looking for a great talk, this one (sorry this is the only ungated link) is an interview with someone who created a profitable product outsourcing development and following the Customer Development methodology.

Got some thoughts on the subject? I’d love to hear them.