I think of Google Analytics as a tool that I can incorporate in my web application to get more information about my UI and UX in general. This is in addition to user testing and other tools, but I'm wondering how else, in terms of mechanisms similar to Google Analytics, I can support UX at the framework level.

My latest ground-up application incorporates a testing mode, where (when activated) users can give feedback on specific interface elements quickly and easily. The architecture was designed to support A/B splitting to complement the concept of quick interface feedback.

Besides these methods, is there any other base level UX integration I can do to make better future design decisions?

  • 2
    I'm confused... are you asking how to incorporate UX into a website, or how to incorporate UX testing into a website? Because they are quite different questions. May 8 '12 at 21:28
  • UX testing implies (to me) user testing done with a moderator. I'm thinking of things that can be done at the lowest level to solicit feedback from users as they're utilizing the deployed product. Similar to a "Send Feedback" feature, but more descriptive and informative.
    – Nic
    May 8 '12 at 22:01
  • 2
    Could you edit your question a bit then? You're definitely asking about some level of research/testing/analytics, not just "UX"
    – Ben Brocka
    May 9 '12 at 14:12

Making Sense of Usability Metrics: Usability and Six Sigma (PDF) outlines the following quantitative metrics that could easily be applied to web applications:

  1. Completion rate
  2. Error rate
  3. User satisfaction (self-reported)
  4. Completion time

All aside from #3 - User satisfaction can easily be tracked on forms using Google Analytics Event Tracking. You will have to manually specify events such as "Success", "Error", etc.

Once, you have data, you can calculate the metrics as follows:

  1. Completion rate = # of success events on a form / # of pageviews on the form
  2. Error rate = # of error events on a form / # of pageviews on the form
  3. User satisfaction [would have to use a separate survey tool]
  4. Completion time = "Time on page" in Google Analytics

Ideally before you build anything - you go through a User Centred Design Process, to figure out what users actually want.

The problem with the 'build and test' approach is that you can leave out big chunks of functionality which only come to light late in the day.

  • I agree, and this is incorporated in pre-design mode. But are there ways to gather more information post-deployment to help continually improve the product?
    – Nic
    May 8 '12 at 23:01
  • If you can, try to round up some users and run you own 'focus group'. You'll probably have to bribe users in some way to get them to turn up. (Not as good as getting the professionals to do it - but cheaper and better than nothing at all).
    – PhillipW
    May 9 '12 at 12:58

Try a contextual inquiry. (This isn't exactly engineering into the code of the webapp, but it is something definitely useful to do at any point.)

If you can, shadow / observe users interacting with your webapp. While it is important to ask users for feedback via widgets, surveys, etc., often times you will notice problems they wouldn't think of simply by observing their normal use.

This could happen via a casual shadow session for 10 minutes where you sit next to a typical user at a desk, or a screenshare if it is easier to do it remotely.

Users adapt surprisingly quickly to bad UX once they learn how to work with it, so this is your chance to spot problems that aren't at the top of their mind.


There is little difference between doing Usability work on a website, and doing it on any other application, except you have an easier time making live changes. UX work should be done as early in the design process as possible... ideally at the start of the project, right alongside the initial visual designs. It's a lot cheaper to find out a particular design is hard to use EARLY rather than LATE, and have to redo it.

It's very difficult to get accurate feedback from users who aren't in front of you. You can get feedback, and even metrics, but it's hard to trust.

Did people avoid something because they didn't see it? Because they aren't interested in it? Because they misread it? Who knows? Testing something with live users right in front of you gets you far more useful feedback than a dozen tests impersonally through the computer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.