Tag Archives: mental model

Lessons Learned From the Affinity Exercise

Leave a reply

Although the affinity exercise was supported by the people who attended, the actual execution of the exercise was not as organized as I had hoped.

 

Affinity Diagram

Affinity Diagram

 

Lessons Learned:

 

·         Apparently most of the people who came to the exercise did not read the information in the meeting request, and therefore did not really know what was going on beforehand. I did not learn of this until AFTER the exercise was done (although I would say it became apparent during the exercise). Next time I do one of these exercises I would give a more robust overview of the purpose of the exercise and the tasks at hand before we start.

 

·         Several of the key architects that were supposed to attend the exercise were not able to attend at the last minute. Management added additional people to attend. About a dozen people ended up attended the exercise. This group was slightly unmanageable, and there was probably too many people at once. Next time I would either invite a smaller group to participate, or split the groups up into teams, and split the tasks into groups. I might create a competitive challenge out of the activity to help get the participants more excited about the exercise.

 

·         A number of people who attended the exercise did not understand the affinity concept. I feel I should have prepared the team better by giving an overview of this before the exercise started.

 

·         The groups that were created in the affinity project still needed to be broken down into smaller groups.

 

·         Engineers organized the tasks in ways that were not expected.

 

After the affinity exercise I created a mental model of the information that was collected. This process was a little harder than I anticipated. Over-all I believe that the project was a success, and I think creating my first mental model was a great exercise. Now I need to distribute the mental model to development and implement it’s use. Hopefully the development team will see the added value of using this process for future projects.

Preparing for Affinity Exercise

Leave a reply

I’ve spent the last few days recording customer data, and getting ready for the Team Building Affinity exercise that I have planned for Nov 3rd. The steps for this exercise are the following:

1. Define the topic to be brainstormed. I will provide an overview to the team on the problem for which ideas will be generated. Here I will discuss our goals, and the scope of our discussion.

2. Next I will give 15 minutes for the team to familiarize themselves with the 200+ Post-it® notes that I will have tacked up to a wall. These will actually be faux notes, because they will be generated from an excel spreadsheet that I typed up.

3. Next I will task the team with finding the relationships between ideas and categorize the ideas together. This will take probably 15+ minutes. The actual notes are called “Atomic Tasks”. This is data that was collected from multiple customers in a Verb + Noun format. The notes will then be grouped into “Tasks”. These are Atomic tasks that are extremely similar from different users, those tasks will be chunked together into “Towers”, and towers can be grouped together into “Mental Spaces”. This is supposed to convey our Customer Needs to Development, and Architecture, and Product Marketing. This will help us prioritize our product features based on customer needs.

These Atomic Tasks, Tasks, Towers, and Mental Spaces are the pieces that comprise up a Mental Model. Once they are all organized, the group will discuss themes and ideas that come out of this Mental Model to make sure that everyone has a general understanding.

I have also put the pieces of the Marketing Requirements into an excel spreadsheet. I will then distribute those to the group, and see if we have correlating requirements for each of the items in the mental model. This can help us see if we have any gaps in our software product design.

Cooper’s Keynote Speech at Agile 2008

Leave a reply

I just finished watching the presentation slides from Alan Coopers Keynote Speech at Agile 2008, and it reading it made me want to write another blog entry because he succinctly talks about several important UX concepts. The title of his Keynote speech is The Wisdom of Experience. In this presentation he says “the most important part of the software doesn’t exist.” He describes these parts as the “interstice between programs”, or interfaces. He describes the difference between Human facing interfaces and “Application Program Interfaces” or API’s.

I mention this because I think it’s relevant to the post that I made earlier today about how people do not understand the User Experience, and how it is not just a marketing buzzword. Perhaps people are puzzled by this subject because it is based on these non-tangible interstices between programs. It is up to the User Experience Evangelist to bring to light how important these interactions are to the applications in which they are contained.

Another responsibility of the UX professional is to decipher and distill useful answers from the cognitive distortions or raw data that people contribute in the user interview process. The following are examples he gives of reasoning illusions that distort peoples perceptions: Cognitive Friction, Memory Distortion, Hawthorne Effectve, Stockholm Syndrome, Diagnosis Bias, Reasoning Illusions, Loss Aversino, Value Attribution, Commitment bias, Pygmalion Effect, Tyranny of Small Decisions, Evolutionary Psychology, Management Fads, Abilene Syndrome. I’m not going to go into the specific details of each of these concepts, you can look them up on wikipedia. However, these are all things that can cloud the truth.

By using the Agile process, using iterations, and a multi-staged process the UX designer can greatly help the success of any development project. This process takes the guess-work out of the design by getting the users involved. The data collected by the users can be presented to development in a mental model, and in personas, and these items guide design-making decisions throughout the process. By using the Agile process, success is based more on the quality into the product, instead of being first to market. To quote Cooper “There is no large group of people out there waiting in a breathless delirium to purchase your lousy product sooner rather than later.” Developing software in iterations allows for quicker detection of errors.

When an interaction designer is brought in on a project, there is someone there to interface with the users and make sure that the application being developed stays focused on the product goal. This helps the programmers because they are then able to focus on technology. This relationship should manifest some very clear patterns, developers can start writing better applications that actually please the users, and experience more job satisfaction. Users have a good experience with the applications, and brand loyalty is built. Interaction designers take on interacting with users and management, so the programmers can do what they want to do, program.

It is very important that the Interaction Designer translates the needs of the user into something that development can understand. It is also important that designers understand the business rationale of the applications that are being built. The UX designer brings clarity to the projects goals, the users needs, and they bring sense to the business requirements definitions. They translate convoluted user input into clear user stories that can be used to develop applications.

For more information I recommend viewing the entire presentation from Cooper but for those people who dont’ have time to look at a 111 page slide presentation I hope this post provided some clarity on the importance of User Experience.