Thinking outside of the <div>

Posted on by

An interesting article from UXBooth offers some great take-away points about approaching complex interactions:

  1. Realize that just because everyone does something a certain way it doesn’t mean you should do it, too. Popular design choices may not apply to your particular use-case.
  2. Layout the objectives of the design from the user’s point of view. Listen to customers to understand their pain points.
  3. Make a list of all the elements you want to include. Make sure each element has a clear function. Don’t just add things for the sake of it. Get pragmatic.
  4. Put everything together and see how it “fits.” Can you remove anything without jeopardizing the function of the element?
  5. Launch, test, iterate!

This process opened our eyes to the fact that a lot of designers might just be recycling standard design patterns resulting in sub-optimal experiences. I know we’ve been guilty of this. Are there places in your web-app where you might be doing the same thing?

Worthwhile advice when approaching any interaction, no matter how complex.

 

I thought we moved past this

Posted on by

Apparently, some still think that it’s ok to let you know that their site is best viewed in a browser that you’re too lame to use.

BuzzData letting you know you're not very cool

I, however, do not think this. Neither should you. New, and emerging technologies, while cool, are just that: new and emerging. So, don’t allow your first impression to be delivered with a slap across the face. Allow for graceful degradation among the most popular browsers. Period.

 

Ferrari Configurator!

Posted on by

As with their cars, Ferrari has created a really fantastic experience with their 458 configurator. Not only is the 458 gorgeous, but it’s a technological marvel with a seemingly endless number of options. The configurator will keep even the most critical desk jockey occupied for an entire lunch break. 

Overall, the configurator looks terrific, but it could use more contrast; viewing in my bright office made reading the text sometimes an eye-squinting affair. And while offering decent, and obvious, points of navigation—which is an important interaction that not all configurators do well—if I had to pick some nits, I would like the sections—both parent and child—to be more visually distinct from one another. As they are now, it’s not immediately obvious where a section begins and ends. Also, when clicked, a parent section expands horizontally to expose its children but in doing so the following parent section label is moved. Not a deal breaker, but not awesome.

As far as that red slider thingy at the bottom of the UI goes, besides being made taller, I’m not sold on the idea that it’s really necessary at all. I understand that it’s marking where the user is located within the work-flow, but since the user is able to navigate to any point in the flow at any time, an indicator of progress is not valid here.

Other than these small issues—that are easily ignored—the configurator is tons of fun, which after all is the real goal of these kinds of things. And for those of us who don’t quite (yet) have the scratch for the real thing, it’s nice that Ferrari throws us a bone with some cool online eye candy to kill some time until we do.

Related articles: Autopilot

 

Don’t just make it better

Posted on by

Every once in a while I need to remind myself that interaction design is not just about making a new thing better than an old thing. It’s ensuring that the thing—new or old—provides a great experience in comparison to nothing other than itself. It’s either good or it isn’t. Judging that something is working well for your users based on how it’s better than it used to be is no guarantee that your design is any good.

When looking for a new home, do you think that it’s reasonable to make your selection based on the current home’s condition as compared to its old condition? What if it’s a dump but the agent tells you that it also used to be a crack house? Would you buy it because a dump is better than a crack house? Of course not. So, if you, your colleagues, or clients claim that the existing experience is good because it’s better than it used to be, please stop. You’re doing yourself—and, most importantly, all your users—a disservice.

Instead rely on user testing and heuristic evaluations that will provide you the concrete data you need to ensure that what you have created is truly great and not just better than it used to be.

 

Oh, the irony

Posted on by

Several days ago, while checking email on her phone (natch), my wife received the above email from Microsoft. It seemed reasonable enough until she clicked the iPhone link within the “improved methods to get Hotmail on your smartphone” section. She received the following in response to her apparently misguided action:

Really? It’s hard to tell what Microsoft’s intention was here. Did they assume that since she wanted to read about using a smartphone to read her email that she would be using a PC to read the email? Considering that 27% of the word’s population (that’s 1.08 Billion for those who are counting) has a smartphone and is on it nearly constantly, it would seem that Microsoft would have made the connection between clicking on a link about smartphones and smartphone usage. They did not.

It should come as no surprise to anyone, especially Microsoft, that she was reading the email on her phone considering that they created a massive infographic that goes into ad naseum-detail about the subject of smartphone usage. According to them, not only is she the most active demographic but she spends twice as much time on her phone than she does eating. So, I have to wonder what they were thinking when they thought it was totally fine to tell her that she can’t use her phone to view information about using her phone. To Microsoft’s credit mobile phone usage won’t officially take over PC usage until 2014 so they can sit back a relax until then.

There’s a reason irony only works in books and movies.

 

Wireframes: the good, bad, and useless

Posted on by

As a UI designer, I’m constantly creating all sorts of documentation whether it be rough sketches on a whiteboard or a technical specification. In my article 1000 Words or Less, I touch on the applicability of wireframes in the design process:

Wireframes are purposely non-interactive. This is an advantage in the early stages of design. They not only keep the team focused but also decrease the time to get something in front of them.

While wireframes have their place, they aren’t as useful for documenting or maintaining the final design once coding has begun and should not be relied on to communicate the evolution of the design. Darrel Austin at uxformobile agrees and states in his article about the misuse of wireframes that:

They are an invaluable tool. What I am against is them being used as a document of record outside of the UX team. A wireframe simply can’t communicate the full complexities of the solution to every individual team.

I think this is accurate. He also goes further to suggest that an agile development methodology should serve to evolve the design into code faster and more efficiently than wireframes (and really most other forms of documentation) can. Wireframes as well as most other documentation inevitably become quickly outdated. The time spent making updates to the documentation can be spent sitting with a developer and updating the code.

The one place where I don’t quite agree with Darrel is that I don’t have a problem creating electronic versions of my wireframes. Where he would prefer to keep them on paper and whiteboards, I find that wireframes if used properly are as useful (more so in fact) if they can be shared via email, projected on a screen, or otherwise archived along with other project documentation that gets created along the way. Besides this, I agree with his final words of wisdom:

Focus on the product. Not the wireframes. After all, our users will never be using the wireframes.

 

Lost in Translation

Posted on by

Errors happen. It’s a fact of life and software. But if you go to the trouble of localizing the interface you shouldn’t stop there. Localizing the messaging content helps too, especially if the locale starts in Stuttgart and ends in Seattle. This comes courtesy of porsche.com’s 911 car configurator.

porsche.com error message

Cool configurator, not a cool message.

 

Plan of Attack

Posted on by

Since I’m an interaction designer, I don’t normally produce documentation not directly related to design. In most of my projects there is at least a project manager, and a business analyst who handle most of the heavy lifting when it comes to documentation at the start of a project. This is not always the case however and the duties of producing up-front documentation falls to those that don’t normally do it. In other words, me.

I don’t always have the luxury of working with a fully staffed project team. This is not just the case at my company where nearly all my work is geared toward internal clients (our own employees) but happens often at consulting agencies where team members are called upon to wear all sorts of hats or places where staff size is small and money is tight (who hasn’t felt this?). When this is the case, I or others on my team (of three!) need to step up and get things started.

One of the first things that we’ll produce is a Project Work Scope. In many cases a project work scope only gets written when the project charter has been given a green light by some person above you who parks their Mercedes in their reserved spot in the parking garage. The project charter is a very high-level document that gives enough information about the intent of the project and the problem that it’s trying to solve. Boring.

Even though the project charter and project work scope aren’t necessarily page-turners, the project work scope is a crucial piece of documentation that serves several purposes:

  • succinctly states the background and the problem that needs to be solved
  • describes the specific ways in which this problem is going to be solved
  • gives rough estimates of how long each thing will take
  • lists the people that will be involved
  • specifies dependencies – what is required in order to be successful
  • specifies constraints – what things might stand in our way

There are other things that are also appropriate for inclusion in a project work scope but may depend on what your project is trying to accomplish. For instance, I don’t have to worry about budgets since I don’t bill any clients, but time-frame is still important. Include only those things that you know will truly impact your project and leave out the things that won’t. Some other things that you might want to include only if it makes sense for your situation:

  • capital expenses (e.g. hardware, software licensing)
  • organizational impact: will this require resources from other projects or outside of your immediate dept?
  • work alignment: how does this project align with other initiatives already happening in your organization?
  • stakeholders: who is either driving this initiative or who will be directly affected by it?
  • project approval: get sign off before starting the work.
  • items out of scope: this is the yin to the in-scope’s yang. Also good to get down on paper.

The bottom line is keep the document as short and to the point as possible. Once everyone who is involved reads and agrees to the work, you’ll hopefully never have to look at it again. If you do though, it won’t require much effort to look it over.

When would you look at it again? When the project is getting off track or is suffering from scope creep. Put those ideas into a feature list to be prioritized later. Let everyone know that you’ll get to the ideas, just not now. The project work scope is a good way to remind everyone why you’re engaged in the project in the first place.

Here is an example of a recent project work scope that I put together for a small-scale engagement with another project team (also the motivation for this post): Project Work Scope Example

For more information than you ever wanted on this topic the following might be useful (in order of anal retentiveness):