User Research and/or Usability Testing with(out) Recalcitrant Users

So the interface that I am working on is for a very small group of users. These users are very important and they know it. They are far too important to take part in any sort of user research or usability testing.

I am designing one (quite complex) part of the interface for configuring a particular enterprise system. It allows the users to configure the system through a web application instead of manually editing a configuration file. It would be extremely helpful to know more about how the users do these tasks at the moment.

I have access to the developers, who, in turn, have access to the actual configuration files. So this gives me a static view of how things are configured, but it doesn’t tell me what they configured first or why. Or the logic and thought processes behind it.

I also have access to another major project stakeholder, who may be able to give me some pointers.

Any ideas for other ways of getting at this information without direct access to the users?

Thanks :)

What do you think?

Hello – is this helpful. Is this what you were expecting? Are we still to abstract?

Following comments

By the way, there’s no feed for comments here. I use Commentful for that sort of thing — I find it very useful.

Very helpful

Oh no, this is definitely not too abstract. I like the idea of breaking it down by nouns and then categorizing and defining relationships.

In fact, I have already created a mind map that is pretty similar to what you describe. I will certainly do what you suggested as well, to make sure that I didn’t miss anything.

I’m not sure that ignoring the users completely is such a great idea, though. There are some things that are going to be hard to guess at. For example, I don’t know how often the users need to reconfigure item A as compared to item B.

As for the complexity, I will know more once I have my thing diagram. But one issue that I am facing is that the things that can be configured make up a hierarchy. Some things are recursive — they are inherited by every node below them in the hierarchy (though the nodes lower down can override them). And some only apply to the node for which they are defined.

I will have to find a way to show this in the interface. any suggestions?

Thanks!

hierarchy

A couple of thoughts on the hierarchy:
1) can you decouple the creation of the hierarchy from the assignment of the nodes – if the node instances were made separately then attached to the tree you could have some basic rules of how they apply to the tree, where a default behavior could be defined with the ability to override the default as the item is added to the tree – then you would have a tree builder and a series of entity creating pages – several lists of items to put in the tree

2) another possibility is to identify the representation of hierarchy as a page of pick lists where for each topic area you have a section of the page and from there you can select the item that you want attached to that section

There are several models around this area that work. Since I do not know what you have I am sort of “shooting into the dark.” Once you have the relationships down different possibilities will emerge.

At that point you should push your colleagues and yourself to come up with at least 10 different ways to do the design. Create sketches and then critique them. The process of doing many designs will help you choose the best one to go forward with. I believe that this is one of the most necessary steps in the process (it tends to be missing from software design but is essential).

But...

I guess I should have described the problem a little more thoroughly. (Though the ideas you gave me are definitely applicable to the larger design.)

The problem I need to solve (for now, anyway) is how to configure a particular aspect for nodes that have already been added (and for which other things have already been configured). Though for nodes that will be added later, this aspect will be configurable at that stage as well.

I hope I haven’t confused you too much :) Anyway, once I have my thing diagram completed, I’ll let you know. Then on to the generate-lots-of-alternative-ideas stage.

Thanks!

Complexity

I do not think you will ignore the users forever. I think you will have a series of these question you are starting to identify that you can ask your application engineers or service people. Then you can take those answers and verify with users. Verification can be done by an online conference call with an advisory board of users. That will help get buy in and some validation. – I am just pushing you to do some of the heavy lifting from what you know.

There are several interaction models we can tackle with this problem of complexity. I will get back to you on that when I have some time.

More info and possibilities

It turns out that access to users may be easier than I had been led to believe. So once I have identified the important questions, I will go ask them. In the meantime, I will move forward with the heavy lifting, as you suggest.

Thanks!

Design without the users

Ah I love it. I have been there doin’ that for years.

At this point in time do not worry about the users. We need to worry about the configuration tool which has to phases of the world typically: 1) startup and 2) maintenance. Knowing what the tolerances of your users are we probably can answer many of the questions needed for them.

So where to start?

As a writer you will appreciate this part. If you had a PM that put together requirements docs you would go through the docs and underline all of the nouns and their relationships. If you do not have that I want you to write down all of the nouns you have in this configuration system. For example: – end user – thing1 to configure – thing2 to configure – I had clocks in a group – 2 nouns: clock and group – they are related in that clocks are a member of or belong to a group – groups were designated areas of a building where people could punch in time: more nouns: building, people (employees), time

Do this to the full extent you know how. Since you have much of this information in the systems that exist you should be able to put it together. With this information I want you to take a piece of paper, ppt or visio or whatever your favorite shape and line app is and put all the nouns/ things into circles. Take lines and connect the relationships of the things. Above the line state the relationship (is a member of, is an attribute of, is related to etc). Make sure the language used all points in the same direction so that if you use “is a member of” pointing in one direction do no use “contains” for another relationship because they logically mean the same thing but point in different direction and will confuse the consistency of the diagram.

Stand back and look at what you have. This should represent the world for the complex configuration. Review it with the developer that knows the system. Do not let him get hung up on whether you have done the perfect object diagram. This is a “thing” (you know designers) to be used to see all the things and their basic relationships.

So why would I do this?

Your next step would be to define how you would possibly configure these things. Now that you know the relationships you can start sketching the approach. How complex is it? Do you have lists of these things that are later combined and named so that it can be referenced by a role in the system? How many levels of configuration do you have? Do you have one ultimate container that is filled with named things that could also be composed of named things? Once you have your thing diagram you can start having these design questions.