Considering User Goals

Successfully Designing With Information > Building a Richly Connected Microsite > Improving The Interface With User Testing

The microsite built with these three page types has a lot of interconnections, and users can focus on projects or practices depending on their interests.

We can desk-check the usability of this micro-site in more detail by constructing some plausible user goals and scenarios, and seeing how well the user’s needs are met by the current design.

For illustration purposes, we assume that there are two main types of user approaching this site for information.

User has a Sector Focus – this user works in a specific sector (let’s say Government), has a project in mind, and wants to know if we have done projects like it in their sector.  This user is only secondarily interested in what practices are needed to deliver it, if at all.

User has a Capabilities focus – this user has a project in mind, and through previous experience knows the skills and resources that are needed to deliver it.  The user is looking for evidence that we have the skills and resources, and furthermore, have deployed them successfully.

In an ideal world, the goals will be the result of user interviews or watching users interact with an interactive mockup.

Regardless, conducting a fictitious plausibility check like this is still valuable in the early design stages; it can catch some obvious gotchas before real user testing, or at least generate some issues to watch for during testing with live users.

Usability Testing: Sector Focus

This user wants belong to the Government sector, and is looking for a company that understand government and has successfully delivered projects in this sector.

We (mentally) follow a user through a plausible exploration, in fine detail, and see how well our interaction meets their needs.

User Goal	User Interaction	Assessment
See if we have done Government projects	Go to the landing page; Observe that we have done a Federal Government project;	Goal achieved
Check the Federal Government project	Navigate from the landing page to the Federal Government project page; Look at the Federal Government Project page; This project is not similar enough, look for other Government projects	Goal achieved
Look for other Government projects	Realise that there is no indication of other Government projects; Navigate back to the landing page; Read the descriptions of the other projects displayed: None are Government related: Abandon the site	Goal not supported

Things start off well, but the user soon runs into a problem. Having found one Government project, the user does not have a way to find others, and has to figure out their own method to do so.

There is a much worse problem, a business problem. Our company has in fact done other Government projects but none of these were chosen to appear in the Selected Projects area. We have failed to meet the business goal of conveying our company’s track record.

To address this, what additional information would be needed, and where should we display it?

The answer seems straightforward: “Display other Government projects on the Federal Government page” as this is where the user ran into problems.

Generically, our design specification becomes “On a project page, display other projects for the same sector, if there are any”.

Usability Testing: Capabilities Focus

This user has a project in mind, and through previous experience knows the skills and resources that are needed to deliver it.  They are looking for evidence that we have the skills and resources, and furthermore, have deployed them successfully.

Let us suppose that they need (and know they need) Software Development and User Experience expertise.

We (mentally) follow a user through a plausible exploration, and see how well our interaction meets their needs.  Things start off well but again run into snags after a while.

User Goal	User Interaction	Assessment
Check that both Software Development and User Experience expertise are available	Go to the landing page; Observe that Software Development and User Experience are both offered; Investigate further	Goal achieved
Check what the software development group can do	Navigate from the landing page to the Software Development page; Look at the Software Development Practice page; Assess that capabilities look promising; Notice some projects (Federal Government, Retail) that look relevant; Investigate further	Goal achieved
Check the Federal Government project	Navigate from the Software Development to the Federal Government project page; Look at the Federal Government project page; Assess relevance; Decide to check out the other Software Development project; Try to remember its name, ah yes, Retail; Investigate further	Goal achieved, memory work needed
Check the Retail Project	Realise that there is no forward flow; Figure out workaround by using back arrow in browser to go back to the Software Development page, or navigate to the landing page; Decide whether or not to proceed;	Goal not supported

The problem is that the user has to rely on their memory, and that there is no built-in forward path. Clearly, the user wants to see related projects, but which ones, and where do we display them? Thinking about the user flow, the user had come from the Software Development page, had looked at one of their projects, and now is looking for more.

So in this flow, “related projects” means other Software Development projects. If the user had started by looking at User Experience, “related projects” would mean other User Experience projects.

We could display something like this.

More usable project page

The following wireframe shows both of these usability improvements.

The good news is that the level of granularity in the information model supports all of these changes.  Certainly, the developer has work to do, but this does not involve changing the underlying information structure.  This is perhaps the biggest lesson from this case study, that a robust information model can support multiple access paths for various types of users with different goals.

Is this the final answer?

Probably not.  We may determine that there are other usage scenarios that we overlooked.  We may find that the solution works well for small numbers of projects but is structurally unusable when there are hundreds of projects (in this case, we may decide to add a Projects Browser with advanced search capability).

It also leaves open a lot of questions for our UX colleagues to address and perhaps demonstrate in more detailed wireframes of mockups. Even in this small example, the UX considerations that have to be addressed are numerous, and include:

• What should the overall placement of page areas be? For example, we moved testimonials to be lower in prominence than other Government projects. Is this what is required?
• How do we handle edge cases? For example, what would we do if there were no other government projects?
• How well does the visual treatment scale? For example, suppose there were 200 other Government projects?
• Are we presenting too much or too little information about various instances? For example, would it be more compelling to display Project thumbnails and summaries instead of just links? And for Practices Used, do we really need the thumbnails and summaries, or would links be enough?

The answers to these will feed into the next generation of wireframes or mockups.

Summary

This design case study started with a business goal of building a microsite to describe a consulting group’s capabilities.

We established the types of thing we could say about the group, and chose some of these to formally express in an information model. From these, we constructed the information model, raising usability questions as we did so.

Turning to presentation, we showed how the various aspects of an information model can be expressed in different ways in the user interface

With this in hand, we created wireframes for the microsite. We assessed the site’s usability against plausible usage scenarios which indicated significant usability issues; we modified the design to address these. With the informational aspects of the wireframes complete, we indicated that significant UX decisions remained, and indicated some of them.