Take the 2-minute tour ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.

I'm working on a dedicated CMS system for my client. I have already prepared some use cases and wondering how to communicate it to client's salesmen. I need their feedback but I am afraid they won't read it because of form in which use cases are usually written. Thus, I am going to use screenshots of mockups to facilitate the reception of the document, but still don't know how to present it.

Any suggestions?

share|improve this question
    
I've also had problems communicating use cases with developers, because for some developers a use case is a completely different thing. –  Jason Feb 13 '13 at 0:02

3 Answers 3

I think this is a very common problem and one that unfortunately takes some effort to overcome. My preference is to engage the users in an actual meeting (web or otherwise). I often have to explain the importance of the meeting to project teams that bring up various reasons why it won't work. The meeting itself is advertised as a usability session or focus group feedback.

Regardless of whether you settle on a meeting or a written document, the presentation has to relate to issues (pain points) felt by this user group in particular. This is especially true since you have a user group that is pressed for time (salesmen) and an application (CMS) that is foreign to most people.

The approach that has worked for me is to think of the document more as a slide presentation that walks through each user story that is related to the use case. I actually create slides that represent each event that occurs in the UI and embed them in the document or simply distribute the slide deck itself. I prefer the latter because you have the advantage of being able to navigate through the user stories. I add narrative slides as needed and voice-over on occasion. It is presented as a conversation with the user:

  1. Why we think this feature is important to you.
  2. What might you not like about it or specific things we want you to consider. (Yes, I actually seed their negative thinking. Hopefully we have thought about issues in advance and covered them. If the users do come up with something valid we want to know now, not after delivery).

I have found this to not be as much work as it sounds. Most events do not create major changes to the UI and with a little practice the process of creating them goes fast. By actually seeing each event as it occurs the layers of abstraction created in a well-written use case are removed.

An interesting discussion of use cases vs. user stories that suggests the name is not as important as the orientation and provisions that are made to help the user understand. http://c2.com/cgi/wiki?UserStoryAndUseCaseComparison

share|improve this answer
    
I agree with this one. A good storyboard is worth a thousand emails. If you really need their feedback, it's best to spend some time illustrating the user stories for them. –  Pdxd Oct 28 at 1:58

Personally I like the simple presentations from the firefox ux team. The case steps are visualized by screens. It's nice and clear. Some examples you will find on there blog. Firefox UX Blog

An example mockup Example of Mockup description

share|improve this answer

I recommend going with a storyboarding approach where you use an wire frame flip through approach to walk through the different use cases and the user flow through them and what would be success and failure conditions. I strongly recommend reading this article Beyond Use Cases with Storyboarding which has this to say about using storyboards for use case demonstrations:

Business users often ask me how the screen looks, even in the early phase, to understand the system we propose. So, I explain by drawing some simple wireframes on white board. Some elements and text messages are enough to express the system's behavior. This sort of visualization lets them get on the same page, and you can get more feedback from them.

Similar effects can be seen in a storyboard technique that visualizes interactions between system and user. The storyboard was originally developed in the film industry in which a series of pictures that represent each cut scene are organized in sequence. It pre-visualizes the script so that team members can easily understand what they have to do.

enter image description here

I also recommend looking at this research paper Integrating Use Cases, Storyboarding and Prototyping which talks about the methods which can be used to integrate use cases, storyboards and prototypes to drive home the user flow and potential issues.

Another option to consider would be consider an actor model with a pictorial representation of the user flow with action and result called out. An example is given below:

enter image description here

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.