ideas

A Recap on the Talk

This week I attended PhillyCHI's event featuring Michael Carvin and Michael Zarro. The talk was entitled User Experience Research: Is there an Academic – Practitioner Divide? The discussion proposed the thesis that there is hardline division between the practitioner research and academic research. The talk was rich and the discussion afterwards fruitful. The conclusion was that there is much more room for the use of academic research within the practitioners day-to-day projects, but that due to perceived dense material, difficult search options, and time constraints many practitioners do not use the amazingly thorough research that is done in the field of human computer interaction. There also is the potential for further partnerships between academia and corporations within the Philadelphia area. When the talk was finished there were some tangential thoughts and further exploration that occurred as a group.
 

The Discussion

Rigor within User Experience (is there a lack there of?)
The subject of rigor within UX research was posed by Dave Cooksey of saturdave, an independent user experience consultancy. His concern seemed to me to be two-fold: 1. that there is not a rigorous community of partitioners providing the necessary feedback and constructive criticism on the amount and strategy for UX research and 2. that there is no standard for UX research, unlike other fields. Without such standards, there's no ability to measure the level of rigor or to even have baseline approaches to our methods. While many practitioners participate in discussing standards through a lively community online there is no formal academic requirement for practitioners in the field. In his talk. The User Experience of User Experience, another PhillyCHI event, Cooksey made the point that 'there is no qualifying test for User Experience Professionals as there is with architects or Doctors' and that 'we are not held to the same standards as other fields.' Yet, we are increasingly being brought to the table as experts in our field without the same formal qualifications as other disciplines. From my point of view this brings us both advantages and disadvantages. Without having formal requirements we are free to help shape what the field is in a way that other more formal professions are not. We have the ability to shape how we fit into a team through our actions. This could be seen as a disadvantage as well, which I think was more the point of the comment: that there are many practitioners who do not follow rigorous methods of practice, who could inevitably poison the perception of the field by producing low quality work and produce irreversible perceptions within the minds of our non-UX partners. This double edge sword I believe to be one though that is faced by many fields due to differences in the level of rigor at different institutions. Overall, I tend to lean towards the direction that our current position affords us immense opportunity to help shape our field as well as act as change agents in legacy institutional structures.
 
Is the bar set low for design research?
I brought up the point that was mirrored by another participant, forgive me for not citing his name, that the bar for User Experience professionals doing research is quite low. This relates to the way that we communicate to our clients and business stakeholders on the level of numbers and metrics. These are the bread and butter of what they do, and I feel that whenever research is cited or conducted by the User Experience teams, the tendency of business is to be either surprised that such thought was included in what is perceived as more of an aesthetic practice or to somewhat blindly take the research as fact without much questioning. This does get back to the earlier point of there being no true research standards in UX. I also feel it gets at this idea of the increasing overlap of product management and user experience professionals, as we get more refined in our ability to conduct both qualitative and evaluative research we are able to provide more objective rational behind our decisions and also speak more the language of business in a way that we have not been able to before. I recently wrote about this overlap in my article: Product Management and User Experience Had a Baby.
 
How can we use UX metrics?
After the talk a woman who also works at a large corporation explained to me that my comment on the bar being set low for research hit home for her. She spoke of a way that her internal design team has been able to improve the relationship with business as well as the outcome of the final product by creating User Experience Metrics that are more granular ways of measuring success and failure of given interactions and tasks. What these do is two fold: 1. it forces the designs to align closely with the business goals in a way that elevates the practice of User Experience within the eyes of the business as an important and rigorous practice that is integral to business success and 2. With the added inclusion of "how to measure success" tacked on to the definition phase of the user experience both teams are forced to consolidate and prioritize the use cases which comprise the heart and soul of the desired experience. At the end of a project when the product is within flight, the use of user experience metrics map seamlessly with the business metrics and both teams are able to measure success and failure concurrently.
 
Potential for Partnership: Academia and Institutions
The talk also raised the idea for more collaboration between academic institutions and corporations, especially within the Philadelphia area. By creating relationships either through a stipend or granting the ability to publish findings, institutions can have academic research and insight into their operations and products that may not be feasible internally due to timing, budget, or internal resources. This would require some level of trust on both parties and could be tricky from a legal perspective. However, from my perspective seems like a no brainer!
For now, I at least feel encouraged to reach out to local academics and libraries to use relevant published research within my daily practice. 
 
PHOTO CREDITS:
http://trevinwax.com/2007/12/26/2007-the-year-in-book-review/
http://www.flickr.com/photos/taedc/5686750281/lightbox/

As a forward: just as I wrapped up this article a man in the coffee shop where I am sitting handed me a postcard with a large ear on it. You can call it coincidence, chance, I call it synchronicity. OH: the multitude of ideas for future posts abound.
 

"There's room for endless listening"

My dance teacher said this one day, one of the many insightful things he has said in the context of improvisational dance. I often find these nuggets of wisdom apply to my life as a whole. I am relatively sure that is the intent of his lessons. But that is another topic in itself.
 

There may be no I in team, but let there be ear!

Working intuitively as an improvisational dance group to create a performance in the moment is not much different than creating any project with a team. You must be flexible and open to the inevitable change that occurs on the "hot seat" or "stage." You must be willing to let go of control and at the same time maintain personal strength. The only way to do this is to listen: wholly and completely to those around you. When I am dancing, this means sensing the quality and emotion behind other dancer's gestures, posture, and breath, noticing the tangental projection of their movement and learning when to initiate and when to follow.

In the context of team-based projects: In order to move the project forward, there must be a deep sense of listening to the members of the group so that things are not communicated poorly, tasks are not misunderstood, but most of all so the group can perform not as individuals, but as a team, especially when there are things to get done and deadlines to be met. The mentality of "get 'er done" can have the ability to fragment a group without the ability of the group or the group leaders to focus on cohesion. Just as with dance, a good team-member knows when to lead and when to listen - in this way we all have the potential to be leaders as good leadership is about bringing people with you, which has nothing to do with the ego.
 

Listen up ego...

In order to make the necessary room for listening, the ego must be shrunk and kept in check for it takes up the same room where listening occurs. If the ego were a cloud that surrounded each person, by centering and shrinking this cloud, we could make room for additional listening. It may take great energy to maintain a small ego while at the same time have the strength necessary to listen deeply. But it's a fight worth fighting.

The phrase my teacher said has many levels: the term 'endless' says that this action of listening is one that can always be deepened. It also says that there are different levels or degrees of listening. The skill of listening is not static, but based on a dynamic spectrum. This is both comforting and terrifying. By shrinking my ego I leave myself exposed to the elements, I leave myself ready for people to listen to me the real me and I worry they may not like what they hear. At the same time, I feel comforted by the idea that there will always be endless room for listening, which means to me that I will never become bored; there will always be new levels of meaning to understand and no end point in growth.

Now if only there was a pin to deflate this ego, to get on the fast track, or maybe I'll just take the long road, and hopefully hear many things along the way!

It’s ... a challenge to illustrate a holistic view of a site that has a nontraditional navigational structure." from  Is The Sitemap Loosing Its Client Facing Steam by Vincent Au from UXMag.com.

This is a great article that makes you question about the value of traditional site-maps and UX documentation. I have been thinking about this a lot recently, since I am transitioning from a team that works with a different larger dev group to a smaller more agile one. I am not yet sure how UX documentation falls into the picture, but I do know that all very successful meetings I have presented at, have had some type of support documentation tailored to the goal of the meeting. This makes me feel confident that some level of static documentation will live on if not only for means on in-person communication and decision making.
The level of formality of a design presentation or meeting can vary greatly depending on who your client is. At an internal agency this holds true as well. With many different teams in a corporate environment, there are many different types of presentations and brainstorming sessions which occur. Creating documentation that can both be presented formally in a meeting to stakeholders, as well as live on as the building block for development documentation can be a way of keeping track of decisions made as well as framiliarizing different teams with the evolution of the design.

When creating documentation for a meeting I like to start with the following basic outline for the slides:
 
1. The Opener
Questions, open issues, related projects, goal of designs. For visual support it can be great to diagram out the different things that are open and who the related teams or stakeholders are that need to weigh in or if the project is further along, open issues, questions, or timelines.
 
2. The Design Schema
This is completely dependent on the audience. By schema I mean to include either a IA map of some kind for a business stakeholder responsible for menu structures, a diagram of features for a stakeholder responsible for the product definition, or the core wireframe templates called out by name for an internal design review. The point is, you have to identify what are the key decisions you make in your design that your audience will care about. A developer may not care about what the menu options are called, whereas a content programmer will.

3. Detailed Designs
In the later sections is where I show more detailed wireframes or visuals only after the design system or schema has been presented. Often times if you start with this the meeting goes slower because you have not laid out a foundation yet, even when discussing internally.

If you have such a document for a presentation or meeting, it can easily evolve into the development documentation. Even if designs are prototyped quite quickly, you still have a record of the decisions made and questions considered.