The Wall Street Journal has an interview with DICE’s Lead Gamer Tester and Executive Producer that I found really interesting. Awesome to have more insight into user testing outside of the web/application realm.

There was one bit in particular that struck a chord with me:

I don’t know why, but I always feel ashamed about the games I’m involved in making. I can’t even bring myself to start up “Battlefield Bad Company 2,” our last game, because I feel so ashamed. I know it is a great product but still I only see the things we could have done better.

Patrick Bach, DICE Executive Producer

UX, Interaction designers, and others who help plan, execute and analyze user tests are often perfectionists, and also tend to be their own worst critics. It’s true in web design, and apparently it’s also true in game design.

For what it’s worth, Battlefield Bad Company 2 was a ridiculously good game (one of my all time favorites), and Battlefield 3 is looking to raise the bar quite a bit. Just more evidence that investing in user centric design, just like investing in outstanding talent and leadership, is crucial to building great products.

Just a passing thought on remote research:

I recognize several pros and cons to using remote research. My favorite part about it is to intercept a person about to do [a task], and then watch what they were going to do anyways from their own natural environment. However, I do wonder if remote research practitioners are able to go a step further.

What if we could somehow watch someone do something (they were already going to do), but not have them act any differently due to the knowledge of someone watching their actions. What if there were someway this could be done without invading someone’s privacy, securely, with their permission. There would be no interaction between the moderator(s)/researcher(s) and the person completing the tasks, and the research team would be able to see when the user is using the site, versus when they switch to another application, pause from the task to go do something in another browser tab, or do anything else that the user does naturally.

There are certainly a lot of what-if’s there, and I do think that the current remote research methods are very valuable, but I think that this type of ideal approach offers a lot of benefits. I sometimes take notice to strange things I’ll do when filling out a form, or sending a payment that I never get to watch other people do. For example, while subscribing to a service this morning, I paused in the middle of the signup process to go chat with a friend, then did some browsing on another site, and then I remembered that I hadn’t finished signing up for that site. Maybe that’s a pretty rare occurrence, but it definitely seems like something I could test for. Maybe it was actually just a bad sign up process, and where I paused ends up being an area where some people drop off.

*shrug*

Just a thought

Since the initial work on CSSsitemap, Andrew Maier and I have been pretty busy working on an array of other tools that are a bit specific to a project we’re collaborating on presently. The result: almost no time has been invested in CSSsitemap since the first in-house version.

Rather than make an empty promise about how we’re going to build some cool features into it eventually, I’m just going to share the code now (it’s awfully simple at this point). Yes, we’re still working on a pretty cool set of tools for project documentation & UX designers, but it’s still sort of up in the air in regards to when and how we’ll share that system with the world.

Download: CSSsitemap System (.zip, 13.3 KB) | Demo

Code example:

<ul>
  <li><span>Fruit</span>
    <ul>
      <li><span>Apples</span></li>
      <li><span>Oranges</span></li>
      <li><span>Watermelons</span></li>
    </ul>
  </li><!-- Fruit -->
 
  <li><span>Vegetables</span>
    <ul>
      <li><span>Leaf Vegetables <a href="linktothisitem">#</a></span>
        <ul>
          <li><span>Arugula</span></li>
          <li><span>Cabbage</span></li>
          <li><span>Lettuce</span></li>
          <li><span>Spinach</span></li>
        </ul>
      </li><!-- Leaf Vegetables -->
 
      <li><span>Root Vegetables</span>
      	<ul>
          <li><span>Beets</span></li>
          <li><span>Carrots</span></li>
        </ul>
      </li><!-- Root Vegetables -->
    </ul>
  </li><!-- Vegetables -->
</ul>

The system is intended for documenting pages in a website in a visual and functional way. It’s very straight forward: pages are presented in a branched format using unordered lists. URL information can be added to any item in the tree for quickly navigating complex sites.

This system was built for webkit browsers, and will probably not work as-is anywhere else at the moment. We recently used it in part of a documentation process for a 300-page website where it has helped tremendously (a preview of which is shown below, intentionally obfuscated).

To be clear, this isn’t a sitemaps to be used on websites to aid people in their navigation or for SEO purposes. This system is for internal use at the moment, which allows us to visualize the depth of a site, section content appropriately, and create useful flowcharts. Someday, we hope to integrate more powerful functionality directly into this system such as illustrating user flows with color coded paths, and methods for organizing and filtering parts of the sitemap in realtime.

Feel free to use however you’d like. If you do anything cool with it, be sure to let me know :)

About a week ago, I mentioned that I’ve been working on a super easy to use Sitemapping system for use in some UX projects I’m working on. Today, I’m happy to say that the CSSsitemap System is just one piece of a larger templating system for UX designers.

Another part of this overarching tool is a simple Mental Model templating system. Like it’s Sitemap counterpart, this system is built to reduce time spent on tediously styling a document, and facilitate the process of laying out information effectively.

Furthermore, it’s very simple to build themes for :)

Cake Theme:

Simple Tech Theme:

Both of these systems are usable already, but I’m still figuring out the best way to release them. I’ve been discussing some ideas with Andrew Maier that might allow us to support the system more effectively in the long haul. In the meantime, I might release a preview of both systems here for your feedback and suggestions.