I was reading this article "The Personality Layer" this morning, it has very good points about UX and I want to share my thoughts with all of you.
We often see UX people making wireframe, talking about user flow, or compiling the tedious functional specification. If we just judge their work by their deliverables, it seems like what they do is not much different than an IA (information architect). However, UX people care much more than information architecture, usability, and interaction design. UX people care about the whole user experience, rational or emotional.
The famous UX related professor Donald Norman published his book Emotional Design: Why We Love (or Hate) Everyday Things, and he mentioned that "New research on emotion and cognition has shown that attractive things really do work better." Positive feeling does help performance in most cases, and we should not limited ourselves as UX people to usability. Button size(which influences the usability according to Fitt's Law), loading speed, and screen transition, these are all part of the user experience. That said, it's our job to stay on top of the whole production process till the end, and try our best to ensure that the user will receive a enjoyable product, rather than a usable but has no intention to use again product (for example, some government website).
Don’t presume anything. Don't presume UX is simple.
I just read the post "UX is simple", and it triggers a lot of thoughts I've been having.
I know lots of places hiring experience visual designers or art directors as their user experience designer. These days some art directors are eager to get the keyword "user experience" in his/her resume, and I'm not surprised more and more art directors are comfortable making this change. However, is user experience only about layout the page in a sensible way?
I think there are reasons that user experience is not simple, even in the "layout the page" level":
1. When you have to review all UI element with all the high level guideline, it's not simple anymore.
2. When you make a change on 1 UI element and it affects 10 others, it's not simple anymore.
If you're a experienced art director, you might be handle these with clever solution. But is that everything about UX?
User experience is much more than putting the provided information in a sensible way. It's much more than show and hide, box and arrow. The first step of UX process is always about identifying; identifying the user (persona and context), identifying the business and technology requirement, identifying the user needs, identifying the pain point... These are the foundation to create good user experience, which is often missing in the project that no one really knows what UX is.
Here's a slideshow I found useful to communicate with people who really want to know what UX is:
http://www.slideshare.net/nickf/user-experience-best-practices
To sum up, design is about solving problem, and the more you know about the problem, the bigger the chance you can create a better solution. User experience design is a big problem solving process, it's not simple, but it really worth it if you really care about your user, your product, and your brand.
I just read the post "UX is simple", and it triggers a lot of thoughts I've been having.
I know lots of places hiring experience visual designers or art directors as their user experience designer. These days some art directors are eager to get the keyword "user experience" in his/her resume, and I'm not surprised more and more art directors are comfortable making this change. However, is user experience only about layout the page in a sensible way?
I think there are reasons that user experience is not simple, even in the "layout the page" level":
1. When you have to review all UI element with all the high level guideline, it's not simple anymore.
2. When you make a change on 1 UI element and it affects 10 others, it's not simple anymore.
If you're a experienced art director, you might be handle these with clever solution. But is that everything about UX?
User experience is much more than putting the provided information in a sensible way. It's much more than show and hide, box and arrow. The first step of UX process is always about identifying; identifying the user (persona and context), identifying the business and technology requirement, identifying the user needs, identifying the pain point... These are the foundation to create good user experience, which is often missing in the project that no one really knows what UX is.
Here's a slideshow I found useful to communicate with people who really want to know what UX is:
http://www.slideshare.net/nickf/user-experience-best-practices
To sum up, design is about solving problem, and the more you know about the problem, the bigger the chance you can create a better solution. User experience design is a big problem solving process, it's not simple, but it really worth it if you really care about your user, your product, and your brand.
|
Many of us UX designers are familiar with "Agile" Development environment, which enable many quick turnovers in the evolution of software/app/web development, to pursue better quality of product. The goal of Agile is somewhat similar to UX design, "test, get feedback, make the product better".
However, in terms of execution, an Agile Development environment can be sometimes hard for an UX professional to fit in and introduce UX process to the development team. Why is it hard? "Time is my greatest enemy." -Evita Peron. Agile Development's fast turnover nature often offers little time for most of the basic UX design process.
One of the essential spirit of Agile Development is "GOOB" - Getting Out of the Building, which means quickly wrap up a product release and send it to the market, to gather user feedback for the next release of the updated product. That said, this "Agile" spirit is embedded in the PM's head, which often leads to a constant urge of creating a short time frame for the next product release. While most of the basic UX research and analysis process, the short time frame gives UX professional a tough challenge to complete the important foundation work.
I recently read the blog post: "Agile UX vs Lean UX – How they’re different and why it matters for UX designers", it proposed this idea of Lean UX which seems to has its value at the first glance. It looks like a compromise between UX and Agile Development, which can be a useful way to convince PM to conduct a little UX process without delaying the expected product launch schedule. However, the compromising UX process which so called Lean UX will probably lose a lot of the essentials of UX value. Moreover, in my eyes, rather than Lean UX, I would rather call this compromised process as "Agile with a bit of UX taste". UX is much more than getting user feedback from using an existing product.
We know a facelift of the product might be able to bring customers a refreshing feeling, but what's hard for to refresh is user's memory, memory of bad user experience toward a product, a service, a brand. Moreover, once the user has bad experience toward a product, s/he might not even come back! F. Scott. Fitzgerald said: "There are no second acts in American lives", The product with poor user experience might not even get that second chance.
In sum, it is our job as UX professionals to advocate the value of UX, especially for our team member who doesn't quite understand why UX research is so important in the early stage (1-10-100 rule is a good reference to begin with ). It is our responsibility to sit down with product owner, project manager, and other main player in management level to adopt UX process early in the road map, and this process should not be defeated merely by the intention of adopting Agile Development.
However, in terms of execution, an Agile Development environment can be sometimes hard for an UX professional to fit in and introduce UX process to the development team. Why is it hard? "Time is my greatest enemy." -Evita Peron. Agile Development's fast turnover nature often offers little time for most of the basic UX design process.
One of the essential spirit of Agile Development is "GOOB" - Getting Out of the Building, which means quickly wrap up a product release and send it to the market, to gather user feedback for the next release of the updated product. That said, this "Agile" spirit is embedded in the PM's head, which often leads to a constant urge of creating a short time frame for the next product release. While most of the basic UX research and analysis process, the short time frame gives UX professional a tough challenge to complete the important foundation work.
I recently read the blog post: "Agile UX vs Lean UX – How they’re different and why it matters for UX designers", it proposed this idea of Lean UX which seems to has its value at the first glance. It looks like a compromise between UX and Agile Development, which can be a useful way to convince PM to conduct a little UX process without delaying the expected product launch schedule. However, the compromising UX process which so called Lean UX will probably lose a lot of the essentials of UX value. Moreover, in my eyes, rather than Lean UX, I would rather call this compromised process as "Agile with a bit of UX taste". UX is much more than getting user feedback from using an existing product.
We know a facelift of the product might be able to bring customers a refreshing feeling, but what's hard for to refresh is user's memory, memory of bad user experience toward a product, a service, a brand. Moreover, once the user has bad experience toward a product, s/he might not even come back! F. Scott. Fitzgerald said: "There are no second acts in American lives", The product with poor user experience might not even get that second chance.
In sum, it is our job as UX professionals to advocate the value of UX, especially for our team member who doesn't quite understand why UX research is so important in the early stage (1-10-100 rule is a good reference to begin with ). It is our responsibility to sit down with product owner, project manager, and other main player in management level to adopt UX process early in the road map, and this process should not be defeated merely by the intention of adopting Agile Development.
|