Archive for category Design

Button placement on Forms

I’ve been reading a number of great articles on forms recently – covering things like general layout and inline validation (Luke Wroblewski seems to be the world authority on forms – most of his advice seems well worth paying attention to). But I’ve been looking at something recently and I’m wondering how best to implement it, namely the positioning of the buttons for submitting a form.

I have a simple, linear search form with "Search" and "Clear" buttons. Automatically, I would have considered laying it out like this:

Simple Form - default layoutLet’s set aside the accessibility argument of whether form labels should appear above fields – I’d like to consider the buttons here. There’s no requirement for multi-language support, either.

I can think of a few reasons why this is unfriendly. Firstly, all the form labels are right aligned and if a user is tabbing down through each of the fields their focus will suddenly jump to the left when they get to the buttons. Secondly, is there enough of a distinction between the "Search" and the "Clear"? And whilst from the text it’s clear which is the call to action, is it as obvious visually? Well, no, not really. Thirdly, how necessary or common are clear/reset buttons these days? Because it’s a separate topic, really, let’s assume we’re going to persist with the "Clear" button.

My first thought was "What about moving them to the right?" Like this…

form-opt2

So I’ve flipped the buttons around and shifted them over to be inline with the right-side of the fields. I think it’s a little more intuitive but it doesn’t deal with the spacing issue nor the intended call-to-action.

Colours are a potential way of differentiating but it will a) set a precedent in terms of styling throughout the application and b) I have an accessibility requirement so colour to convey meaning is a no-no.

I think it’s a little bit of an improvement, but should I go with it or can I do anything else with it?

How about…

form-opt3

The "Search" and the "Clear" buttons are totally separated and (to me) it’s clear that the search is the main call-to-action – and that’s probably what we want. If a user is tabbing down through the fields the tab out to the button will be naturally followed.

The clear button is there and can be used, but I hope it comes across that it’s not something we really want users to be getting too involved with.

Now I appreciate that the all of my reasoning is pretty subjective. I don’t have any research I’d be keen on to get some thoughts and opinions about this particular question – are any of my three options go-ers, or have I missed the best-practice approach completely? Any other suggestions?

Tags: , , ,

UX when using a product

The world of web-based user experience design is a fascinating one. And some of the places you can go creatively to ensure that users of your site get the most of it can be amazing. But, what about those situations where you deliver a solution based on one or more products e.g. WCM/ECM, shopping carts, wikis, etc.?

I suppose this post is most inspired by my own experience of the WCM world. Invariably, you will be building your site (intranet, extranet, website, whatever…) on some platform or product which immediately introduces a level of restriction in terms of what you can do with the user experience. CMS applications tend to be filled with tools and components to make it easy to present common types of content e.g. static content, blogs, polls, forums, document libraries, membership management, etc.

By using these in-built components, you’re automatically tying yourself to the user experience as governed by the CMS vendor. And, having seen numerous CMS frameworks – from open-source to enterprise scale £10,000s-per-licence – sometimes that’s not a good thing at all. Some of even the more expensive tools of the market give such a poor, unfriendly user experience.

Yes, you can do a certain amount with styling, and on occasions (depending on a customer’s requirements) bespok-ing a certain piece of functionality may make more sense than using whatever comes out of the box. But what is the best way to handle those situations where the CMS product provides all that is needed but with a user experience that, for want of a better word, sucks?

Very, very few customers would be pleased at having to pay an expensive licence for a set of tools only to be told that you’d recommend re-writing some of them in a better way (at additional cost). There’s always the possibility of feeding back to the product vendor to suggest UX improvements or changes, but that rarely gets you too far as most vendors will have their own roadmaps and priorities.

There are a number of factors that will impact the best course of action here.

  • Your relationship with your customer;
  • Your relationship with the product vendor;
  • Your knowledge of the product;
  • Your ability to apply changes/improvements in a cost-effective way.

There will obviously come a time when a compromise of some description has to be made. If you can persuade your customer to trust you in terms of your advice and to pay for the work you suggest needs done (by promising – with confidence – a return on that investment), that would be a good result.

But, I feel it’s more likely you’ll have to accept that the customer will make a decision on behalf of their users and take the user experience/usability limitations as they come.

If you haven’t got the wealth of persuasion skills necessary, what’s the best way to make the most of the UX elements when delivering a product-based solution where the out-of-the-box user experience is not what you’d like it to be?

Tags: , , ,

Sketching/Wireframing

There is an increasing plethora of tools available when it comes to sketching layouts/wireframes for solutions. It’s amazing how rich these tools are becoming and how productive some of them can be in a workshop scenario. If you’re trying to present layouts and flows to customers in a way that they can understand easily and can help them visualise how their application is going to look and operate when it’s created, it’s getting more and more likely that you’ll be using some of these tools.

(I don’t intend to diss the good old “pen and paper” – or whiteboard – approach, but when you’re art skills aren’t the best, some of these little apps are more effective).

Here is a look at some of the things I’ve used.

Balsamiq Mockups

This Adobe AIR-based app was one of the first I used. Whilst my experience with any of these tools is still a little theoretical, I was really, really impressed with the wealth of tools and components available in Balsamiq. And combined with the Napkee tool, you can easily convert your Balsamiq Mockups into working HTML prototypes for that extra level of confidence.

Microsoft Expression Blend SketchFlow

Doing a lot of work in the Microsoft space, I was keen to see what their front-end focussed “Expression” suite brought in terms of mocking up. One advantage this has over Balsamiq is that it allows for basic workflow/process flow definition. I’m going to be attending a training course over the next few weeks in which I should hopefully get a chance to investigate this in a little more detail. There is also a great overview of SketchFlow here (this is part 1 of 3).

iPlotz

Another Adobe AIR app which comes with additional tools like variable views (sketch / Windows app / Mac app). iPlotz also has the concept of project management and collaboration which allows tasks to be defined and assigned making it more applicable to design teams when compared to some of the alternatives.

Pencil

This is a Firefox add-on that allows for very simple GUI mockups. It’s not as rich as any of the tools mentioned so far in terms of screen components and so on, but a couple of colleagues who have used it have suggested that it’s quick and dirty but it’s simplicity can be a bonus if you’re trying to throw together something very, very quickly.

There are obviously loads more, but these are just a few of these tools that I’ve used. When I get some real world experience I’ll probably be in a better position to provide more educated comment. Any views on any of these tools would be appreciated.

Tags: , , , , , ,

Timeless User Experiences

Six Revisions: Creating a Timeless User Experience

I’ve just had a read at this article and found it very interesting. Whilst repeat work (i.e. site refreshes) every so often can only be good, they don’t necessarily guarantee the best (or most timeless user experience). And that goal of having something that will be as familiar and friendly to users in five years as it is now is certainly a worthwhile one to have.

Tags: ,

Prioritising User Experience

I’m currently in the middle of an attempt to formalise how my company should go about the process of defining the user experience/user interface for a given website or web application. It’s very interesting to read all of the diverse range of views that are out there in terms of the best way to go about this. Inherently, whilst looking at UX/UIs, you’ve got to consider the Information Architecture of a site. So, which comes first? Which one do you focus on to make sure you reach the end goal of having something that the customer is completely happy with, completely educated about and which the developers can implement without the needs for multiple follow-up questions?

Pat Kennedy has a strong view that, overall, UX is the most important facet of the design process. But, interestingly, Jan Jursa (in a comment on the post) suggests it should be the other way round. Both people make very good, well-thought-out, based-on-experience, convincing arguments for their point of view.

I guess that, as someone who is coming to this whole subject with a great deal of passion for it but a not-insignificant amount of naivety, I can find myself a little overwhelmed by the whole thing. I really feel that I have an opportunity to come up with a strong offering for my company to pitch to potential (and indeed, existing) clients around our UX experience and practices. And I suppose that it’s not the sort of thing that can be rushed – it will take time, and it will need to be honed (based on experiences and based on how clients in our target markets accept us). It will obviously start at a very high-level – minor improvements and more formality and structure around what we do at the minute – and then progress and evolve into something more complete, based on experiences and research.

There’s a lot of work to it, but I’m enjoying it. I’ve been looking to gather some people’s views on their own experiences and what has worked well for them. I fully appreciate they may not translate to my own circumstances, but I’m trying to absorb as much as I can to make sure I at least start on the right foot! Any comments or advice would be appreciated.

Tags: , ,

Visual Design for the Non-Designer

I’m not an artist. I never have been. When it comes to creativity, I’ve got all the imagination of a … er … see, I can’t even think of a witty analogy! I’m that un-creative.

Confused?I’ve been a web developer for 10 years. I’ve been focused on the front-end of sites (the UI) for most of that 10 years, mainly because I have developed a set of skills that have been useful in constructing UIs. I’ve migrated slowly – but with increasing speed – to the world of UX and trying to develop a set of skills that can be useful in that particular field. I can’t help thinking that more artistic skills and more of an ability to visualise and conceptualise ideas would be beneficial to me, but I am learning.

So I really enjoyed listening to Dan Rubin’s take on how non-designers (or non-artists) can still make a great contribution to the design process. His comments on the “rules and patterns” of design make a lot of sense, and I certainly feel I can contribute to design in that way (having a slight case of OCD when it comes to the precision of things).

Highly recommended for those who feel, like me, that anything they lack in the artistic field mean they can’t be successful or well-educated UX engineers.

Tags: , ,

Best Practice Call To Action Buttons

Slightly inspired by this Smashing Magazine article, I wanted to take a look at Call To Action buttons. How do we, as designers, best distinguish the actions that we want our users to take? How do we make such calls obvious enough that users understand instinctively what the action is and understand exactly what will happen when they click it?

I think planning calls to action is of special importance on a home page or a landing page. You want these pages to present (almost instantly) what your site is about and the next action you’d like your users to take. For example, any e-commerce site will load their home page with product links to ensure that users are enticed to purchase things immediately. News sites highlight main articles or features. Software sites generally have a “Download Now” link prominently placed on their home page.

I’ve recently been working on a site that has two very distinct purposes for two very different user types. I’ve been proposing that we make these two streams immediately clear on the home page and entice the user to follow the most appropriate stream with a relevant call to action. We could then filter the content and materials to be most appropriate to that particular type of user. OK, there may be a few users who have a foot in both camps, but all content will be public and available by following links to “cross the streams” (!), as it were.

Valuable, well-considered, well-implemented calls to action can make or break a site, but as the first comment on the Smashing Mag article goes to show, not everyone gets this. Some just don’t get it at all – but as is borne out by many of the other comments, a large measure of the success or failure of a site can be placed on the design and implementation of the calls to action.

“What are the calls to action for this page?” should be one of the first questions asked when you first think of a particular page or section of a site or application. Once those are identified, they can feed into the layout and structure decisions later.

Tags: , , , ,

Owning The Design

This post beautifully sums up the main point I have been trying to make in my organisation for the past couple of years. In short, designers should carry out all of their interaction with the customer before a line of user interface code is written. The main obstacle I have come across is getting enough time built into the project plan to allow this level of detail to be reached.

All too often, we will ask customers to sign off on concepts of one or two screens and simply assume that all subsequent design decisions will be inferred by the developers when they get to implementing each individual screen. I believe this is far from ideal and is especially compounded when the developer may not necessarily be experienced (never mind expert) in UIs. I’ve yet to experience what you’d call “success” with this approach and usually see a massive investment of time and money in revising UI elements once a customer actually gets to see them.

There are so many advantages in undertaking a more rigorous UX definition phase – both for us (as the supplier) and for the customer. It removes one major undercurrent of doubt during the development phase and will ensure that the customer receives no surprises when they actually get to see their product. Also, developers don’t need to over-concern themselves with design decisions that they neither want to think about nor, in many cases, are qualified to think about.

Tags: , ,