Usability Review or UI Specification?

Question

At the moment I am trying to see where UI/UX will fit in with our current software development cycle. We have a separate department that wireframes new products.

Our specification stage for new products as well as existing products contains a wire frame and a technical spec.

I'm not sure which would be best during the early stages., my involvement with wireframing is distant, therefore any changes ito such will be done so by another.

1. I perform a usability review on a wire frame, with feedback for improvements / amendments based on internal focus groups, opinions & best practices.
2. Write a UI specification based on the wireframe
3. Perform a usability review, focus groups, and make amendments to the primary wire frame i receive, (effectively altering the software dev cycle).

Usability testing is not typically performed on wireframe, although i did read here http://www.loop11.com/wireframe-usability-testing/ that is could be a good way to streamline new products .

Essentially my role, is to give the ok to completed wireframes. What would be the best way to refine a wireframe, best practices, and documentation to support any amendments.

Answer 1

Jakob Nielsen recently wrote a good article about what is the most useful usability activity http://www.useit.com/alertbox/field-study-vs-user-test.html. Ideally, you do both a user study before any wireframes are created (to understand what users need and what mental model is) and also usability studies with the wireframes (to see if design supports user goals and if there any usability issues). A big benefit of running user studies with wireframes is that you still may have a chance to change the architecture of the UI. It is much harder to do later in the process when dev work already started.

Based on your question you are usually involved in the process when wireframes are ready so you can still try putting them in front of the users to ensure that the UI works before any specs are written. Often timing is a constraint and recruiting participants may take a while. What I found valuable is doing quick usability studies with co-workers that are not involved in the project to avoid a bias. You can usually send an email to people in the company and see if anyone would like to participate. My observation is that people find usability studies fun and it is not hard to recruit within the company. Of course, ideally, you can find participants that are similar to your actual users.

Answer 2

The answer is:both.

Before:

The users speak the language of the UI: therefore, any requirement they have, any change request they ask for can only be in the language of the UI, in the language of the user interface.

If a user asks for adding a new method to a class, (s)he knows too much, and usually it's not how the system is actually written, but what is the mental model of the user about the system (and sometimes programming in general).

So, UI has a place in requirement gathering as it's the language the user speaks.

Usability was always tested in the UX industry beforehand, Google for paper prototyping, the "ancestor" of wireframes.

Design phase, in the original software engineering sense was there to reduce the cost of change: it takes much more time to make changes on a half-finished product.

The balance is between how detailed a design should be (how costly a design is) vs how meaningful it is to the user.

Software engineers, like in anything, like to go full-scale. I usually tell them, that you can buy a house in East-Europe from the price of a single sprint (and a brand new car in any country), and that I'm yet to see a customer saying "throw this sprint out for this feature and let's start again in next iteration", exactly because of this: usually, whatever is done in a sprint remains, even if it's suboptimal.

You have to be able to provide designs which are low-cost enough in order to be throwable.

If you do the full UI, that'll costs more, and the customers (or you) will be reluctant to throw it out completely. The less the better.

There are tools to help you make your wireframes clickable. The most usual one is powerpoint, but you can have a look at a bunch of them here.

Also, I usually employ a frontend-first solution, that is, I like to do a clickable, but non-functional frontend first (using javascript mock data stores for example), and wire in backend later, as it's the frontend the user is able to tell the problems with.

After:

Nothing is perfect, so when you have the finished product, you have to check if it does work as intended. Usually, instead of a training, I ask key users to try to do certain tasks on the interface themselves - usually a variation of the user stories / use case scenarios we've agreed on previously and which were used to build the application.

Also, whenever it's possible, I add measurement / monitoring methods to the application, which are turned on for the first few weeks (or, in case they don't take too much resources, always), and create key metrics beforehand on what we'd like to see as an improvement. Whenever there was an older version, the older version gets the same kind of monitoring beforehand, in order to have something to compare with.

For the users, the UI is the system. Interaction-wise, perhaps the interaction flow is a bit more important to get right, than finishing touches on the UI, especially as it's usually the finishing touches which make an application rigid - both in the technical and psychological sense: neither the users, nor the creators can differentiate between that and a finished application, it's stuck in their mind, but they're also stuck technologically to a given solution.

Answer 3

Essentially my role, is to give the ok to completed wireframes

I'm not a fan of this approach, though it's common.

Though it also varies as to what we mean by 'ok'.

If it's merely to say "the wireframes are OK, now let's finish the UX process" then that's fine.

However, all-to-often I see it treated as a "the wireframes are OK, UX is done, now build this"

The problem with the latter is that the product isn't the wireframes. The product is the wireframes, and the UI, and the user testing, and the back end development, and, etc...

As such, I'm a huge fan of wireframes never being treated as something that needs to be signed off on. Wireframes should be treated as an internal work-in-progress document to create the actual user experience. The UX is what needs to be signed off on--not specific wireframes.

To specifically answer the usability question, I say do it whenever and however you can. If you can do that with wireframes, great. Do it. If you can do it with the UI and prototypes, even better. Do it! (Basically, do user testing whenever you can).