UX Guys Blog

We design practical and easy to use digital interfaces

Archive for the ‘UX Techniques’ Category

Your user champion is outside the door

robb, March 7th, 2011 in UX Techniques

So you’ve recognized the need to engage a user experience architect on a major project. As an enterprise level organization, you may even have the luxury of deciding between bringing in a contractor or creating a full-time internal position. With a green light from HR and the gang in Finance, which one do you choose?

There’s often a temptation in larger companies to staff up for positions when looking at a long-term engagement. Creating entire departments has the outward appearance of answering concerns about accountability and professionalism. After all, how committed does that contractor need to be to your end goals, and how likely is that person going to adopt your corporate culture? Maybe those simply are not the right questions.

Here’s a better question, for starters. Where is the voice of your user? If you’ve hired an internal user experience professional, given them the standard company onboarding and set them in front of your senior stakeholders, how objective can you expect that person to be? Chances are, your company IA will eventually stray toward your company’s business goals – possibly jeopardizing the user experience.

Remember, the contractor you bring in to conduct stakeholder interviews, build wireframes and prototypes or perform usability analysis and testing is your user champion. By being airlifted in from outside, that champion lives and breathes the life of your user, unaffected by company politics, internal corporate structure or goals for personal advancement in the organization. If that person seems like a maverick, it’s only because he so closely resembles your real world users.

Wait a second, you may be thinking, how do I keep that rogue IA on schedule and meeting my all-important deadlines? Now, that is a good question…time is money, right? But once again, the contractor model seems to win out. When your user experience architect is a full-time hire, he might have more of a vested interest in keeping that project chugging along indefinitely – since the light at the end of the tunnel might signal the end of the job. Contractors, on the other hand, know that there’s another project waiting in the wings with someone else. They’d prefer to get your job done and move on, hired guns that they are.

So, now the sensitive question. What’s it going to cost? You know those contract user guys are going to run you some serious dollars, while your HR department is also telling you there’s room to add a few more bodies to the company payroll. Even factoring in benefits, paid holiday time and other intangibles, the internal hire may be more attractive on the balance sheet. But look again. That contractor might be long gone and finished the job ahead of schedule while you’re still finding busy work for that full-timer. Plus, with the added benefit of a superior user experience (generally speaking, of course) you can have the satisfaction of knowing you’ve met your real goals.

Now, I’m not suggesting you race out and only hire contract user professionals. That would be revealing my own vested interests too much. If your company has the resources to have both, then you really are getting the best of both worlds. The fraternity of user experience is deep, and professionals in the field work well together. So why not cover the complete spectrum that spans user objectives and business goals, with external influences nicely complementing internal knowledge.

In the end, it is all about creating the best possible user experience. Start by looking outside your door, before closing it and trying to figure it all out from within.

Prototyping

Scott, March 7th, 2011 in UX Techniques, UX Tools

In an ideal world, we could build and test complete, functional, high-fidelity prototypes for every project, then iterate and test again. But even in the real world, with time and budget constraints, we can use prototyping to answer user-research questions, solve interface problems, prove concepts, test usability, and reduce risks before committing to development.

Prototyping techniques range from rough sketches on paper to hand-coded HTML. Tools like Axure and iRise allow non-programmers to develop interactive HTML prototypes that approximate enough functionality and fidelity to cover most testing requirements.

When planning a prototype, there are two basic questions to answer. First, what level of fidelity and functionality do I want? This will determine which tool or technique you use. Second, how am I going to test the prototype? This can range from showing it to a few stakeholders to setting up full usability lab testing with a group of typical users (which of course costs more).

But before you can answer these questions, there is a more important question – what exactly is the problem you need to solve, the question you need to answer? A clear sense of these priorities is vital to cost-effective prototyping, since you only want to develop enough prototype to solve these problems or answer these questions.

Two examples from recent UX Guys projects:

Online Store

As part of a redesign project for a telecommunications company, we developed an online store environment for ordering complex TV, internet and phone products. We built a series of high-fidelity prototypes in Axure to test two different interface concepts. The prototypes were first created as functional wireframes, then once we finalized the logic and flow, we added content and minimal skinning with graphic elements to create the illusion of a real web site for test users.

The first interface concept was a traditional catalogue in which products were grouped by a hierarchy (e.g. HD vs. non-HD TV service) then a good-better-best order for different products (e.g. numbers of phone features or TV channels in different packages). The second, alternative concept was an “assisted-selling tool” that made product recommendations based on how the user answered questions about their preferences and intended usage needs.
The prototypes we developed included readily available comparison tools and progressive-disclosure techniques such as roll-downs and pop-ups for more detailed information. We added a floating shopping cart showing which items have been selected (though due to Axure limitations we were not able to calculate a running total).

We tested our prototype with two groups of eight users on two different evenings. We gave the users a number of tasks, and divided them equally between interface options. We used feedback from the first session to make iterative changes before the second test, but only to correct minor usability problems that presented consistent roadblocks.
In developing the prototype, we used a new visual design and interaction model but preserved the current product names and organization. One of our goals was to find weaknesses in the way the company’s products were structured, positioned and marketed.

In testing, we had two very different objectives, or basic questions: to see how the prototype interface performed in terms of allowing users to complete tasks, and to see how users responded to the organization of the company’s products. Did the conceptual model – breaking TV into service then channel package, for example – actually work? In other words, could we build an interface that allowed users to complete a complex task successfully, but could we also find ways to reduce the complexity of the task by simplifying the underlying structure?

Based on the testing sessions, we learned that both interface concepts were relatively successful at allowing users to complete all tasks, but that users do in fact struggle with the complexity and ambiguous naming of the client’s products. Users were divided in their preference for the traditional catalogue and the assisted-selling tool, so we proposed including the tool as an optional “help” path for users who needed more hand-holding.

Thanks to the prototypes, we have a well-developed IA for an online store environment that we know will work effectively, thereby reducing risks once we start development. But perhaps more importantly, we found compelling evidence of user confusion that we can take to business stakeholders, in an effort to convince them to reduce product complexity.

Internal Software Application

We were engaged on a small project to solve interface-design and usability problems for an web-based internal software application used by the purchasing department of a global auto manufacturer. The client presented us with rough wireframes showing their first ideas for a solution.
We sketched out a number of possible solution concepts, then drew wireframes of the most promising idea. Without going into great detail describing a complex application, the core problem was to present a list of up to 100 different auto parts, then for each part multiple tabs containing dozens of data fields, while allowing values from certain fields to be copied from one part to one or more other parts (e.g. the right- and left-side versions of a suspension component would both come from the same supplier and have the same price terms and shipping costs, so the user should be able to copy those fields from one to the other rather than enter them twice). Our basic question was simply this: was our interface concept “intuitive” and usable? There was no formal testing beyond presentation to the client.

The client requested a clickable HTML front-end prototype that would show interactive elements on the page, but with no access to data. A developer quickly took the wireframes and built out the pages, but in the process the developer and the UX architect together added a number of dynamic elements that provided the user with clear indications of what steps should be taken next in the process, and clear feedback showing when an operation was successful. (When the user checked a data field to mark it for copying, the paste button appeared above the list of parts, along with check boxes next to each part and a select-all button. When the user clicked on the paste button, selected parts were highlighted in green for a few seconds to indicate a successful copying of data fields.) Hiding controls until they were needed improved usability by reducing interface complexity and making next steps clear.

The lesson from this project is that while dynamic behaviours can be documented in wireframes, it’s hard to think dynamically when you’re drawing statically, and the HTML prototype was critical to developing screen-level interactions that provided a far better solution for the user.

The Emotional Power of Wireframes: Part 1 (Practitioner)

Ross, March 7th, 2011 in UX Techniques

We all know that wireframes are great for communicating design concepts and rationale before a pixel is ever pushed in Photoshop or a bezier curve is laid out in Illustrator, but I was wondering if anyone has ever considered how wireframes make people feel? This curiosity extends to both the people building the diagrams and the people taking in all the ideas being conveyed through wireframes.

As a wireframe-type guy, I can only speak to my own personal emotional response to the process and final outcome of building wireframes, so that is where I will start.

Ross, tell us how you really feel…

I’ve been building websites for over ten years and I’ve done everything from concept models, to visual design layouts, to writing client-side code line by line. The biggest thing I’ve learned is not to get too attached to ideas or concepts because there is a good chance they will be changed, edited or rejected at some point. Throughout my career I’ve had clients who have loved my design work and other projects where it’s been flat out rejected; it’s the nature of the business and my skin has grown thick over the years. But even now, I find myself much more anxious about reviewing visual design concepts when compared to reviewing wireframes and the reason is really quite simple: emotional investment.

For me, drawing boxes, arrows and lines in varying shades of gray does not create the same kind of internal emotional response when compared to designing the visual look for a project. When I’m wireframing, I have my analytical hat on. I’m thinking about the page’s functionality, the primary objective of the page, making sure blocks of content are located in a logical place for the user, etc.; it’s hard to muster emotions when you’ve got the analytical hat on. When I do visual design work the emotional hat replaces the analytical hat. I am much more focused on colours, shapes, depth and creating an overarching visual theme. I am still aware of the logic behind the wireframes but because more detail is being given to the visual design, and those details are intended to trigger emotional responses in users, I find myself getting much more connected and attached to my work.

How many times have I felt crushed, dejected and forlorn if a client comes back with some harsh criticism of a wireframe? Almost never. That is the one of the strengths of wireframes which is often overlooked; it’s hard to get upset if someone tells you your box is the wrong shade of gray. Wireframes keep me emotionally distanced from my work. This is not to say that I don’t take pride in what I do, because I do, but emotional distance has, time and time again, provided me with a clear head and sharp focus for solving problems without bogging down on how I am internalizing criticism or feedback. More often than not, my ego remains intact and the client ends up getting a great solution.

I was working on project recently which had many, many iterations and the wireframes for one particular section had turned into a bit of a moving target. One evening, I realized that I was not getting nearly as frustrated or overwhelmed as I could be given the circumstance. After some self-reflection, I came to the conclusion that I was not emotionally attached to what I was doing. But this was not a negative feeling, it was actually liberating and somewhat empowering. I simply thought about the feedback I had received and started to form a few different options for solutions. No hurt-feelings, no ego, just focusing on the solution; I love wireframes!

For part 2, I will try to get into the head of a client and see how they are reacting to and internalizing the process of wireframing.

Practical Search Engine Optimization

Mark, March 7th, 2011 in UX Techniques

SEO.

It’s a little three-letter acronym that has represented dreams of corporate success and online riches and padded the wallets of digital snake-oil salesmen and spammers ever since Google became a verb.

It certainly earns its both bad and good reputations in the worlds of digital strategy and consulting.

First, the bad: practitioners remain out there who swoop in with a wink and grin promising to own the first page of Google with a dizzying strategy of thousands of inbound links and horrible sounding pages of repetitive copy. Yeah, not cool.

This post is about practical SEO: the tactical things to think about when designing for users, not search bots. There used to be a difference between the two, but thankfully, those two audiences are merging.

Practical SEO is not about mystifying users while somehow tricking search engines in order to get a click-through.

The practice isn’t magical at all really, and there are a few steps, that, with a little leg-work, should improve how users get to your site. And you really don’t need “SEO Specialist” on your business card to successfully pull these things off.

1. Do Your Keyword Research

Anyone can crack open Google AdSense for free and with a little time invested, find out what words users are searching for in relation to their business/organization/blog/etc. Sometimes the results are obvious, sometimes they’re not.

As an example, I was designing the user experience for a destination site that was to include a listing of job postings in Calgary. The preliminary label for the page was “Working in Calgary”, that in my preliminary opinion, should have fared pretty well for SEO.

Yeah, not so much. People looking for work actually search for “Calgary Jobs” or any other such combination of “Jobs” and “Calgary” substantially more than “Working in Calgary”, “Calgary Employment” or the like.

A quick sanity check on AdSense resulted in changing the name of the page in the site map, site designs, copy and meta content. This wasn’t done to trick search engines in any way, it was done to reach those users actually looking for jobs in Calgary, the whole purpose of the website in the first place.

Even if you’re not doing any full-blown SEO research or keyword implementation, take the time to run your site labels through tools like AdSense or Wordtracker. You might be surprised at what you find.

2. Research and Craft Quality Meta Content

Copywriters rightfully focus on the website’s experience, including the information it provides and the emotion it conveys.

All too often though, meta content (most importantly titles and descriptions) goes ignored. A quick explanation for the uninitiated…

This is a meta title (and where and how it appears on the Google search results page):

Meta title

It’s one of the most important things a search engine looks at for keywords. It’s crucial that you have a unique one for each page on your site, and that it accurately describes the page’s content and includes appropriate targeted keywords (ideally researched on AdSense or Wordtracker).

The optimal format is “Primary Keywords – Secondary Keywords | Web Site Name”.

This is your meta description:

You have 144 characters with spaces to describe the content of your page. Keywords are important here, but equally important is letting users know what they’ll find by clicking your link.

Essentially, these two components make up a free targeted ad for your website (AND every single individual page on you website). Make them count by actually enticing users to visit those pages and letting them know what they’ll find there.

3. We’re Social Animals – So Be Social

It used to be that the content on your page was enough to get you rankings: structure it and write it a certain way and you’d end up performing well in search engines. Now, the Googles of the world look at who’s linking to your site even more than what is on your site.

So is content no longer king? It absolutely is, because in order to get people to link to it, it needs to be as good, engaging and informative as always. Even more so: everyone’s a content creator so competition is high.

Essentially, Twitter, Facebook, Flickr, MySpace and countless others matter in the world of search.

This doesn’t mean you should go out and take the smarmy spam approach. Those Google folks are pretty clever, and they’ll catch on to spamming SEO specialists who try to illegitimately manipulate the rankings with pages upon pages of links.

It does mean creating engaging and informative content that is of value to users, and then telling them about it via Twitter, on a Facebook page, in a Flickr group, or in any other number of places that online conversations are taking place. A social media strategy is also an SEO strategy.

Those are the three biggest tactics that you can take to get started on your own initial SEO program. Like a lot of what we do online, it’s mainly a question of practicing common sense once we wade through the buzzwords and mystical nonsense.

To be successful, make sure SEO has its rightful place in your project plan, and assign someone (or some people) to do the keyword research, create the meta content, ensure those keywords make it into site labels, strategize and seed social media, and keep regular tabs on how it all comes together.