    
|
|
|
|
|
Today we're going to look at New Relic custom dashboards. Specifically, I will show you three ways that I tend to use custom dashboards:
This content was commissioned by New Relic and was written and/or edited by the Tuts+ team. Our aim with sponsored content is to publish relevant and objective tutorials, case studies, and inspirational interviews that offer genuine educational value to our readers and enable us to fund the creation of more useful content.
But, before we get into any of that, we must first ask ourselves a question, why should we use custom dashboards at all? New Relic does a pretty good job of presenting your application performance data. Just using the regular UI, you can glean way more information about the performance of your app than you ever could have before you started using New Relic. So, before I show you how to use custom dashboards, I'll explain why I think anyone using New Relic should look at them sooner rather than later.
It's true, most people happily use New Relic without ever looking at the custom dashboard functionality that it provides. It's not until you're a fairly advanced user that you may decide to look at custom dashboards and see what they have to offer you. I think this is a shame, playing around with custom dashboards can not only allow you to slice and dice your app performance data in different ways, but can also:
You can learn all those things by reading the documentation, but playing around with custom dashboards, allows us to begin to understand some of these things by example (on a more intuitive level), rather than just knowing it as a bunch of dot points. As is often the case with technology, tinkering with an unrelated area of a tool, will sometimes give you more insight and understanding into how the more commonly used areas of the same tool work. Using custom dashboards will make you a more savvy New Relic user, and if you've read the other New Relic posts that I've written, you'll know how I feel about knowing your tools.
The one custom dashboard I always like to build is what I call '24 hours at a glance'. I take a bunch of existing charts that I consider important for a single application, lock the time period to the last 24 hours and put them all together on one dashboard. Whenever I am looking at a specific application in New Relic, this will be the first screen I look at to see if there is anything particularly bad that jumps out at me from the last 24 hours. Let's see how we can build this kind of dashboard.
Firstly, we need to create a new custom dashboard. In the New Relic UI click on Dashboards->Create custom dashboard. On the next screen, we give our dashboard a name (you could use "24 hours at a glance", or your own name) and pick the grid layout. Essentially, grid layout is a collection of charts all the same size and overview layout is one big chart surrounded by a bunch of smaller charts (we will use overview layout in the next section).
Now we need to select the app for which we want to create our dashboard and then find some relevant charts to add. I like to add the following:
Depending on your application you may want to add some others, but I find this gives me a fairly good snapshot of what's happening with the application and what to investigate if anything is wrong. Let's find one of these charts and add them to our new dashboard. The server average response time is an easy one, as it's the big chart in the Overview section of the Monitoring tab for an application. Each chart in the New Relic UI has a little New Relic logo in the bottom right corner, when you hover your mouse over this logo it turns into a plus sign, clicking on the plus will allow you to add this chart to a dashboard:
But before we add our chart, we need to change the time window for the New Relic UI to be 24 hours. We need to do this in order to give ourselves the ability to 'lock' the chart to the last 24 hours when we actually add it to the dashboard (this is awkward UX in my opinion, but at least we have a way to do what we need):
We can now go ahead and add the chart:
Don't forget to tick the Lock to span checkbox. When we now visit our new dashboard, the chart we've just added should be there:
We can rinse and repeat the above process until we've added all the charts that we want. In the end, it should look something like this:
You can click the Edit dashboard button in the top right corner which will let you drag the charts around and arrange them in the order you want. The only thing to note is that you can't modify the individual charts in any way (for example, you may have wanted to have a more descriptive chart title, but you can't change it) since they are standard New Relic charts.
The other custom dashboard I always like to build from existing charts is the 'All applications at a glance'. This is only applicable if you have multiple applications you're looking after. Here we pick one or two of the most important charts for every relevant application and put them together. It's usually a safe bet to use the 'Response Time' chart from each application. The actual process of putting the dashboards together is the same as described above, you'll just need to switch applications to get the relevant charts from each. In the end, you should end up with something like this:
This is the screen I'll tend to look at first, when I log in to New Relic. It may be useful to lock the time of each chart to 24 hours just like we did for our '24 hours at a glance' dashboard, but that's up to you. Of course, this is only relevant if you're supporting multiple applications. Having said that, if you have multiple pre-production environments for your application (for staging or load test), you may want to put them all together into a dashboard similar to this one, it may help you catch changes that degrade performance before the code ends up in production.
The New Relic UI suffers from some necessary limitations. It needs to be all things to all people, so they can only group together charts and tables that would make sense for all web applications. Most of the time the UI screens will limit you to looking at one transaction at a time and one or two sets of metrics at a time, if you need to access others you have to click around. The good news is, with custom dashboards, this limitation no longer applies. We know which transactions are related within our domain, we also know which metrics are important to us on a per transaction basis. We can build a dashboard that groups together several related transactions with all the important metrics for each and look at it on the one screen.
Let's say we have a particularly important transaction in our application, it might make sense to have a dashboard where we can see most of the important information about this transaction at a glance. Here on Tuts+ we have a concept of articles (obviously) and articles are pretty important to us, let's build a dashboard to keep an eye on them.
Once again we need to create a new dashboard just like before, we'll call it 'Article overview', but this time we'll use an overview layout. We don't have to go hunting for charts as we'll be creating our own custom charts, so click the big button to create the main chart for our dashboard:
It will ask you if you want to add a chart or a table, we will add a table later, for now choose chart. You will see a screen that looks like this:
The main thing to look at here is the metric that you want to display. When you click inside the metrics text-box it will drop down a list of top level metrics that you can select. The metrics in New Relic are named as prefix/category/label. In the case of a Rails app, the prefix might be Controller or ActiveRecord (if you're not using Rails, the prefix for transactions will be WebTransactions). For Controller, the category would be the name of the controller and the label will be the action name. If you explore some of the metrics while you're playing around with your first chart, you will start to have a feel for the kind of metrics you have access to and where to find them. If you don't see the metrics you expect, make sure that you have the right application selected within New Relic, this always trips me up.
Back to our main chart. The metric we're after will be tied to our ArticlesController, so its name is Controller/articles/show. Once we've picked the metric, the contents of the Value drop-down will change to contain all the values that make sense for this metric. It's worth once again exploring all the various values and seeing what the resulting chart actually contains. In our case, "Average response time" seems like a good thing to have as our main chart.
At this point, if we give our chart a title and click the preview button we can see what it looks like:
This looks OK, but I want the Y axis to be in milliseconds and I want the units on the axis as well. So, let's drop down the advanced options for the chart and change the number format to be 'To Milliseconds', we will also set the Y-axis unit label as 'ms':
Our chart now looks good on the preview. The only thing of note that we haven't talked about is the Chart click-through drop-down. This essentially allows your chart to be a link to another custom dashboard, when you click on the chart, that dashboard will be displayed. We don't need this functionality, so we leave the drop-down alone. We'll now go ahead and save our chart.
We can now add the various sub-charts. In our case, I happen to know that Tuts+ has a concept of tutorials (also, obviously) which is closely related to articles, so if I am going to keep an eye on article average response time, it's probably a good idea to have a tutorial average response time close by as a comparison, so I will create a chart for that. We'll follow the same steps as above, in the end our dashboard will look like this:
Hmm, it looks like the average response time for articles is much higher than tutorials, but I happen to know that both of them share a significant amount of code, strange. But it's also an indication that our custom dashboard is already paying dividends and we haven't even finished constructing it yet. I could have found this information by looking it up in the regular New Relic UI, but having the charts side by side like this helps to really bring home the fact that there might be an issue.
It might also be good to see where our ArticlesController sits compared to other controllers, as far as their maximum response time goes, this is a job for a table. We add another chart just like before, but this time pick table instead of chart. To create tables with multiple rows, we need to use wildcards in our metric name. In our case, I will set the metric to be Controller/, this will select all the metrics under the *Controller prefix, I will now set the limit text-box to be 10 which will do exactly as you expect and set the number of rows in our table to ten. In the end, we should have something that looks like this, right before we save:
Our custom dashboard will now be:
It seems that ArticlesController#show has the longest maximum response time out of all the controller actions, including TutorialsController#show, this is very curious and I should probably make a note to look into this.
We can continue adding a bunch of other charts such as end user average response time or calls per minute. However, some things you just can't construct using a custom chart, such as historical throughput or response time. Luckily we can always fall back on finding the charts that we want somewhere else in New Relic and simply adding those ones to our custom dashboard.
The only limitation with using a dashboard which has custom charts is that you have to have the correct app selected within New Relic, otherwise all the custom charts on your dashboard will be blank.
If you read my last article on custom metrics, you might remember me mentioning that the only way for you to view the custom metric data that you've collected is to create a custom dashboard in New Relic, this is the third reason to use custom dashboards. If you collect a lot of custom metrics, this might be the best reason of all.
On Tuts+ we have a concept of categories (yet again, obviously), I just happen to know that we have a few custom metrics floating around for categories. Let's see if we can put these on a dashboard and actually get an idea of what's happening. We'll create another dashboard and call it 'Categories Custom Metrics'. All custom metrics in New Relic should live under the Custom prefix and this is where we find the metrics we're looking for:
We'll create a couple of charts, one to see how long building presenters in CategoriesController takes and the other to see how long it takes to get a link hash from the presenters. The key thing to know with custom metrics, is what kind of data you're actually sending to New Relic. In this case I happen to know that we're measuring time, so I can pick 'Average value' as my metric value and set the Number format to milliseconds to get a reasonable looking chart. After creating both charts, our custom dashboard looks like this:
It looks like getting the link hash from the presenters is very quick and doesn't fluctuate too much, there is no need to optimize anything here and I can probably stop collecting this metric completely (no need to capture unnecessary data). However, building the presenters takes significantly more time, we can look into this further to see if it can be optimized. We can also keep an eye on the chart (by looking at the custom dashboard occasionally) to make sure the performance doesn't degrade as we continue to work on the application.
Custom dashboards are not a panacea. Aside from creating charts for custom metrics, you can do everything that custom dashboards can do with the regular New Relic UI. However playing with custom dashboards will definitely help you become more of a power user of New Relic, with a deeper understanding of how it works under the hood. In addition, the ability to look at your performance metrics in different ways can be an invaluable tool to help you surface potential performance problems before they have a significant impact on your application.
If you have any questions about New Relic custom dashboards, don't be afraid to leave a comment and I'll do my best to answer. Also, if you've used custom dashboards to good effect in the past, please share any tips you might have, it's always interesting to see how other people use their tools.
]]>Today we’re going to look at New Relic custom dashboards. Specifically, I will show you three ways that I tend to use custom dashboards:
But, before we get into any of that, we must first ask ourselves a question, why should we use custom dashboards at all? New Relic does a pretty good job of presenting your application performance data. Just using the regular UI, you can glean way more information about the performance of your app than you ever could have before you started using New Relic. So, before I show you how to use custom dashboards, I’ll explain why I think anyone using New Relic should look at them sooner rather than later.
It’s true, most people happily use New Relic without ever looking at the custom dashboard functionality that it provides. It’s not until you’re a fairly advanced user that you may decide to look at custom dashboards and see what they have to offer you. I think this is a shame, playing around with custom dashboards can not only allow you to slice and dice your app performance data in different ways, but can also:
You can learn all those things by reading the documentation, but playing around with custom dashboards, allows us to begin to understand some of these things by example (on a more intuitive level), rather than just knowing it as a bunch of dot points. As is often the case with technology, tinkering with an unrelated area of a tool, will sometimes give you more insight and understanding into how the more commonly used areas of the same tool work. Using custom dashboards will make you a more savvy New Relic user, and if you’ve read the other New Relic posts that I’ve written, you’ll know how I feel about knowing your tools.
The one custom dashboard I always like to build is what I call ’24 hours at a glance’. I take a bunch of existing charts that I consider important for a single application, lock the time period to the last 24 hours and put them all together on one dashboard. Whenever I am looking at a specific application in New Relic, this will be the first screen I look at to see if there is anything particularly bad that jumps out at me from the last 24 hours. Let’s see how we can build this kind of dashboard.
Firstly, we need to create a new custom dashboard. In the New Relic UI click on Dashboards->Create custom dashboard. On the next screen, we give our dashboard a name (you could use “24 hours at a glance”, or your own name) and pick the grid layout. Essentially, grid layout is a collection of charts all the same size and overview layout is one big chart surrounded by a bunch of smaller charts (we will use overview layout in the next section).
Now we need to select the app for which we want to create our dashboard and then find some relevant charts to add. I like to add the following:
Depending on your application you may want to add some others, but I find this gives me a fairly good snapshot of what’s happening with the application and what to investigate if anything is wrong. Let’s find one of these charts and add them to our new dashboard. The server average response time is an easy one, as it’s the big chart in the Overview section of the Monitoring tab for an application. Each chart in the New Relic UI has a little New Relic logo in the bottom right corner, when you hover your mouse over this logo it turns into a plus sign, clicking on the plus will allow you to add this chart to a dashboard:
But before we add our chart, we need to change the time window for the New Relic UI to be 24 hours. We need to do this in order to give ourselves the ability to ‘lock’ the chart to the last 24 hours when we actually add it to the dashboard (this is awkward UX in my opinion, but at least we have a way to do what we need):
We can now go ahead and add the chart:
Don’t forget to tick the Lock to span checkbox. When we now visit our new dashboard, the chart we’ve just added should be there:
We can rinse and repeat the above process until we’ve added all the charts that we want. In the end, it should look something like this:
You can click the Edit dashboard button in the top right corner which will let you drag the charts around and arrange them in the order you want. The only thing to note is that you can’t modify the individual charts in any way (for example, you may have wanted to have a more descriptive chart title, but you can’t change it) since they are standard New Relic charts.
The other custom dashboard I always like to build from existing charts is the ‘All applications at a glance’. This is only applicable if you have multiple applications you’re looking after. Here we pick one or two of the most important charts for every relevant application and put them together. It’s usually a safe bet to use the ‘Response Time’ chart from each application. The actual process of putting the dashboards together is the same as described above, you’ll just need to switch applications to get the relevant charts from each. In the end, you should end up with something like this:
This is the screen I’ll tend to look at first, when I log in to New Relic. It may be useful to lock the time of each chart to 24 hours just like we did for our ’24 hours at a glance’ dashboard, but that’s up to you. Of course, this is only relevant if you’re supporting multiple applications. Having said that, if you have multiple pre-production environments for your application (for staging or load test), you may want to put them all together into a dashboard similar to this one, it may help you catch changes that degrade performance before the code ends up in production.
The New Relic UI suffers from some necessary limitations. It needs to be all things to all people, so they can only group together charts and tables that would make sense for all web applications. Most of the time the UI screens will limit you to looking at one transaction at a time and one or two sets of metrics at a time, if you need to access others you have to click around. The good news is, with custom dashboards, this limitation no longer applies. We know which transactions are related within our domain, we also know which metrics are important to us on a per transaction basis. We can build a dashboard that groups together several related transactions with all the important metrics for each and look at it on the one screen.
Let’s say we have a particularly important transaction in our application, it might make sense to have a dashboard where we can see most of the important information about this transaction at a glance. Here on Tuts+ we have a concept of articles (obviously) and articles are pretty important to us, let’s build a dashboard to keep an eye on them.
Once again we need to create a new dashboard just like before, we’ll call it ‘Article overview’, but this time we’ll use an overview layout. We don’t have to go hunting for charts as we’ll be creating our own custom charts, so click the big button to create the main chart for our dashboard:
It will ask you if you want to add a chart or a table, we will add a table later, for now choose chart. You will see a screen that looks like this:
The main thing to look at here is the metric that you want to display. When you click inside the metrics text-box it will drop down a list of top level metrics that you can select. The metrics in New Relic are named as prefix/category/label. In the case of a Rails app, the prefix might be Controller or ActiveRecord (if you’re not using Rails, the prefix for transactions will be WebTransactions). For Controller, the category would be the name of the controller and the label will be the action name. If you explore some of the metrics while you’re playing around with your first chart, you will start to have a feel for the kind of metrics you have access to and where to find them. If you don’t see the metrics you expect, make sure that you have the right application selected within New Relic, this always trips me up.
Back to our main chart. The metric we’re after will be tied to our ArticlesController, so its name is Controller/articles/show. Once we’ve picked the metric, the contents of the Value drop-down will change to contain all the values that make sense for this metric. It’s worth once again exploring all the various values and seeing what the resulting chart actually contains. In our case, “Average response time” seems like a good thing to have as our main chart.
At this point, if we give our chart a title and click the preview button we can see what it looks like:
This looks OK, but I want the Y axis to be in milliseconds and I want the units on the axis as well. So, let’s drop down the advanced options for the chart and change the number format to be ‘To Milliseconds‘, we will also set the Y-axis unit label as ‘ms‘:
Our chart now looks good on the preview. The only thing of note that we haven’t talked about is the Chart click-through drop-down. This essentially allows your chart to be a link to another custom dashboard, when you click on the chart, that dashboard will be displayed. We don’t need this functionality, so we leave the drop-down alone. We’ll now go ahead and save our chart.
We can now add the various sub-charts. In our case, I happen to know that Tuts+ has a concept of tutorials (also, obviously) which is closely related to articles, so if I am going to keep an eye on article average response time, it’s probably a good idea to have a tutorial average response time close by as a comparison, so I will create a chart for that. We’ll follow the same steps as above, in the end our dashboard will look like this:
Hmm, it looks like the average response time for articles is much higher than tutorials, but I happen to know that both of them share a significant amount of code, strange. But it’s also an indication that our custom dashboard is already paying dividends and we haven’t even finished constructing it yet. I could have found this information by looking it up in the regular New Relic UI, but having the charts side by side like this helps to really bring home the fact that there might be an issue.
It might also be good to see where our ArticlesController sits compared to other controllers, as far as their maximum response time goes, this is a job for a table. We add another chart just like before, but this time pick table instead of chart. To create tables with multiple rows, we need to use wildcards in our metric name. In our case, I will set the metric to be Controller/, this will select all the metrics under the *Controller prefix, I will now set the limit text-box to be 10 which will do exactly as you expect and set the number of rows in our table to ten. In the end, we should have something that looks like this, right before we save:
Our custom dashboard will now be:
It seems that ArticlesController#show has the longest maximum response time out of all the controller actions, including TutorialsController#show, this is very curious and I should probably make a note to look into this.
We can continue adding a bunch of other charts such as end user average response time or calls per minute. However, some things you just can’t construct using a custom chart, such as historical throughput or response time. Luckily we can always fall back on finding the charts that we want somewhere else in New Relic and simply adding those ones to our custom dashboard.
The only limitation with using a dashboard which has custom charts is that you have to have the correct app selected within New Relic, otherwise all the custom charts on your dashboard will be blank.
If you read my last article on custom metrics, you might remember me mentioning that the only way for you to view the custom metric data that you’ve collected is to create a custom dashboard in New Relic, this is the third reason to use custom dashboards. If you collect a lot of custom metrics, this might be the best reason of all.
On Tuts+ we have a concept of categories (yet again, obviously), I just happen to know that we have a few custom metrics floating around for categories. Let’s see if we can put these on a dashboard and actually get an idea of what’s happening. We’ll create another dashboard and call it ‘Categories Custom Metrics’. All custom metrics in New Relic should live under the Custom prefix and this is where we find the metrics we’re looking for:
We’ll create a couple of charts, one to see how long building presenters in CategoriesController takes and the other to see how long it takes to get a link hash from the presenters. The key thing to know with custom metrics, is what kind of data you’re actually sending to New Relic. In this case I happen to know that we’re measuring time, so I can pick ‘Average value‘ as my metric value and set the Number format to milliseconds to get a reasonable looking chart. After creating both charts, our custom dashboard looks like this:
It looks like getting the link hash from the presenters is very quick and doesn’t fluctuate too much, there is no need to optimize anything here and I can probably stop collecting this metric completely (no need to capture unnecessary data). However, building the presenters takes significantly more time, we can look into this further to see if it can be optimized. We can also keep an eye on the chart (by looking at the custom dashboard occasionally) to make sure the performance doesn’t degrade as we continue to work on the application.
Custom dashboards are not a panacea. Aside from creating charts for custom metrics, you can do everything that custom dashboards can do with the regular New Relic UI. However playing with custom dashboards will definitely help you become more of a power user of New Relic, with a deeper understanding of how it works under the hood. In addition, the ability to look at your performance metrics in different ways can be an invaluable tool to help you surface potential performance problems before they have a significant impact on your application.
If you have any questions about New Relic custom dashboards, don’t be afraid to leave a comment and I’ll do my best to answer. Also, if you’ve used custom dashboards to good effect in the past, please share any tips you might have, it’s always interesting to see how other people use their tools.
]]>|
|
 |
What is “User Experience Design” exactly? Should you not start it unless you are fully dedicated, or should you embrace it in the process as soon as possible? Are all designers also user experience designers, or is it a separate expertise?
The debate is as old as the discipline itself, and while picking up a bucket of popcorn, sitting back and watching the drama is sometimes fun, let’s try to figure out which user experience techniques are useful for startups, in-house teams, big corporations and anyone who wants to improve their website, product or service.
UX design is a broad and vague field, and most commentators say that it’s a superset of all of the other disciplines. Is there one definition to rule them all? In my opinion, no. Do the definitions provided below describe some aspect of your day-to-day activities? Most likely, yes.
Christina Vodtke, author of Information Architecture: Blueprints for the Web, recently tweeted the following:
There are three core disciplines in UXD: Visual/Interface designers, Interaction designers and Information Architects.
— Christina Wodtke (@cwodtke) November 14, 2013
Steve Psomas offers “The 5 Competencies of User Experience Design,” which encompass information architecture, interaction design, usability engineering, visual design and prototype engineering, with a list of activities and artifacts produced by each activity.
In “The State of User Experience,” Jesse James Garrett, author of The Elements of User Experience, defines experience design thus:
“The design of anything, independent of medium or across media, with human experience as an explicit outcome and human engagement as an explicit goal.”
Peter Merholz, author of Subject to Change, argues that UX is strategy, not design:
“A UX designer is coordinating, orienting, helping all of the other folks [designers] achieve some common goal, a singular intent… UX designers lead organizations to ensure that great experiences get out into the world.”
Dr. Leslie Jensen-Inman and Jared Spool established the Unicorn Institute to identify which skills UX designers need. They’ve found that managers need UX designers to have a holistic skill set, including front-end development, visual design, mobile integration, project management, information architecture, interaction design, copywriting, content strategy and user research. According to this definition, UX design is the Swiss Army knife of Web design.
If you even remotely recognize yourself in any of the definitions above, then there’s a good chance you are already practicing UX design and that you could become a seasoned UX designer with a little more strategy, a dozen of relevant books (check out the links at the bottom) and 10,000 hours of practice. While that’s a compelling proposition, it obviously takes time.
Disregarding the fact that it takes time to become a good UX practitioner, firms should still consider adopting UX techniques for their business in the meantime. (Image credit: baldiri)
Most businesses — especially small companies and startups — can’t afford to hire a dedicated UX designer, but that shouldn’t stop them from adopting some UX techniques. Trust me, it’s much easier than you think.
I like to divide the techniques into two main categories: learning about the website or application, users needs, business goals, the industry and the competition, and generating ideas, solutions and communication artifacts that will help to align the team and shape the product.
Most of us, our stakeholders and, of course, our users need to see the results now — or, better yet, yesterday. Taking urgency into account, how do you determine which UX tool is your best shot at improving the experience of your product? In my experience, usability testing, interviews, journey mapping and microcopy tables are the most effective for quick and dirty UX improvements.
I’ve chosen these particular four because they don’t require you to create polished artifacts. And they can be used internally. The goal is to improve the user experience, not to create unrealistically perfect candy for your portfolio. That involves communicating your design decisions to other people.
Let’s focus on how everyone can improve the user experience in any project they are involved in.
While producing artifacts is a skill that is fairly easy to acquire, the most important soft skill one needs to develop as a UX designer is empathy. Empathy, however, cannot be practiced behind closed doors. To truly understand users, their challenges, their pain points as well as their dreams and desires, you need to go out and learn about them.
Observe them while they do their everyday tasks, tune into their habits or watch them as they interact with a system, whether through a screen interface or across multiple touch points. In short, to achieve a great UX, you need to learn about the user, and the best way to learn about the user is to watch them use your design.
Start practicing UX by conducting usability tests in every project and for every major release. If you’re starting from scratch, a good measure is three rounds: before, during and preflight testing.
Usability testing techniques are well explained in Steve Krug’s classic “Rocket Surgery Made Easy“, the sequel to the legendary “Don’t Make Me Think“.
Need recording software? Just use Silverback, which is dead simple to use and quite reliable. Remote viewers can observe sessions with Google Hangouts. In such cases, install Mouseposé to track mouse clicks and keyboard strokes. For offscreen recording, a set of GoPro cameras or a set of smartphones should work. If you opt for smartphones, make sure there’s enough space for an hour-long recording.
An easy way to record sessions on touch devices is with your laptop camera. Turn on the recording software, angle the laptop screen at about 45° and place the device next to the laptop’s trackpad. Another way is to strap a GoPro camera to the user’s chest or forehead, which is especially handy if you need to test in an unusual context.
By “interviews,” do I mean user interviews? Not exclusively. Apart from interviewing (in plain language) users and customers (the ones who are spending money on us), we should also interview stakeholders, managers and other team members, as well as domain experts.
There are many ways to interview people, but an interview is much like speed dating: Learn as much about the person as quickly as possible.
When the user doesn’t know what the interview is about, you’ll get the most honest and least biased insights. No matter how disappointed they are in your product or service, the user might sugarcoat their answers if they know the purpose of the interview. The opposite could happen, too! On one occasion, we interviewed a user who was recruited by the very company we were redesigning for. Because he knew who we were, he couldn’t stop complaining about the price and value, so we wasted the interview listening to mere rants.
Even worse, you could end up writing down a lengthy list of feature requests. Back in 2007, I worked on a redesign of Croportal.net, at the time one of the 10 most visited websites in Croatia. One of the first usability test-interview hybrids we conducted ended with a couple of users recommending a Gmail log-in form right there on the home page. The craziest part was that the product team actually debated whether to do it. It was a nightmare, but we learned our lesson. Inviting users to specify the product is the highway to feature-creep hell. Our responsibility was to uncover users’ problems, habits and motivations and then design the product to match those findings — not to ask users to design it for us.
Focus on facts, not opinion. Pride and resentment are easy to spot and, depending on the situation, can be a pleasure to hear, but behavior patterns are gold. Of course, write down everything, but sport a poker face when users start talking about the bits that you find the most valuable to the project. This doesn’t mean being serious and cold. In fact, be enthusiastic — but equally enthusiastic — about everything they talk about.
Prepare more questions than you’ll be able to ask. This way, the conversation won’t end prematurely. We usually split our questions into two major groups:
Once you have spoken with users, use that data to create personas, journey maps, workflows and microcopy.
Customer journey mapping is a collaborative activity to discover pain points and opportunities with a product. It’s conducted as a half-day or full-day session, with participants from all over the company. If your startup is small, then gather all of your advisors and mentors. If you are big, then bring in a person or two from customer support, billing, retail, marketing and strategy. Everyone should participate in the workshop, because it could be the perfect opportunity to synthesize all internal goals, connect different roles and give everyone a sense of ownership of the product, making for a cohesive UX.
Again, depending on the purpose and the goal, the maps may be more or less detailed. More importantly, be as objective as possible by gathering enough data about users (via website analytics, pools, surveys and interviews). By the time you become skilled in UX design, you will have used personas extensively in your customer journey mapping.
How do you do it? As an exercise, do it on your own first or with one or two colleagues who won’t roll their eyes the moment you introduce something new to the process. Take a sheet of paper big enough to accommodate a 9 × 6 grid of sticky notes; the paper used on flip charts is a good size. Gather a bunch of sticky notes and a marker or two and you’ll be good to go.
Draw a grid of three columns and six rows. It doesn’t need to be perfect, but if you find drawing straight lines to be challenge, I learned a trick at one of Eva-Lotta Lamm’s sketching workshops: Draw the lines by pulling the marker towards you, instead of from side to side. Label the columns “Before”, “During” and “After,” to represent time. The rows represent different aspects of the journey. Label them, too:
Start using the sticky notes with just two simple rules: first, only one idea or comment for each sticky; secondly, stickies are expendable and affordable. Just add anything you can think of, and edit later once you’ve mapped all aspects of the journey.
Tweak this template to suit your needs, but I strongly suggest keeping “Activities,” “Thoughts” and “Feelings” because understanding what happens beyond our reach will lead to a better user experience.
Once the experience has been charted, use the pointing system of your choice to evaluate each touch point and generate a graph. If you need to present the map within the company, make a poster of it, focusing on storytelling. In this case, your notes and data will just be there for support.
How many times have you encountered an error message that basically means that recovery from the error is impossible? These things happen, because no one involved gave it a thought before the project was sent off to the developers to connect all of the wires. It ended up like that not because someone was lazy, but because it was on no one’s to-do list.
You can prevent this by adding a microcopy table to your project checklist. Microcopy is all of the instructional copy, small print and labels on a website. You want to communicate with the same voice, but adapt the tone to the audience, brand and context.
The easiest way to ensure that communication is consistent — and, more importantly, not to forget the critical bits — is to create a cheat sheet. I like to call such a guide a “microcopy table”. Example:
The industry exemplar is MailChimp’s “Voice and Tone,” created by Kate Kiefer, but yours need not be so sophisticated. Never mind the form at this point; focus on the content.
For starters, open a spreadsheet in Google Docs or on your computer and start entering user tasks, each on its own row. Start with common ones, such as registering, logging in and recovering a password, and then get more specific, such as uploading a photo and updating a status. Lastly, break down basic tasks into smaller bits, such as first name, phone number, VAT number and small print about shipping and handling costs. Where applicable, create two rows for each task, a success row and an error row.
The following columns are typical:
Once you start to think about microcopy, listing all scenarios is a quick and fun way to think about how people will use your interface, to prevent misunderstanding and to delight users by anticipating their reactions. For best results, make it a group exercise!
Don’t worry if you are not good at writing copy. More important than writing everything perfectly is to list all interactions. If you struggle with copywriting, simply hand over the table to someone who is comfortable with it.
No, seriously, everyone should. There is something life-changing about listening to how strangers view the world and watching them use the product of your labor. The first step is always the hardest, but it gets better with practice. At the very least, a different perspective will do you no harm.
If you need more practice or wish to dive deeper, join me at the “Pragmatic UX” workshop in Berlin this 17 February 2014.
(al, il)
© Marko Dugonjic for Smashing Magazine, 2014.
]]>|
|