Trang

28 thg 9, 2012

Tại sao không thể thiết kế UX ?



Ngày nay, rất nhiều designer thường nói về tương tác người dùng (UX). Chúng ta phải làm hài lòng người sử dụng, thậm chí cung cấp cho họ những điều mới lạ, để họ có thể yêu thích các website, yêu thích các ứng dụng và bắt đầu sử dụng. Tương tác người dùng là một concept mở, do đó có rất nhiều người sử dụng thuật ngữ không đúng. Hơn nữa, rất nhiều designer luôn tin rằng họ có thể thiết kế tương tác người dùng trong sản phẩm của họ (và thường không thực tế). Tuy nhiên, UX không chỉ phụ thuộc vào cách thiết kế, mà còn nhiều khía cạnh khác. Trong bài viết này, tôi sẽ cố gắng làm rõ lý do tại sao UX không thể thiết kế.

Giải thích thuật ngữ UX

Mới đây tôi đã ghé một trang web khá thanh lịch của công ty thiết kế. Trang web trông rất tuyệt và đã được tùy chỉnh nhiều lần. Tôi chắc rằng nó cung cấp những sản phẩm có chất lượng cao. Nhưng khi trình bày nội dung của UX, công ty cho đó là những thông tin về cấu trúc (IA) như site maps, wireframe và tất cả những gì tương tự. Về cơ bản nó không sai nhưng đó chỉ là một phần mà UX thực sự làm được.
Sự hiểu biết có thể không được trình bày rõ ràng nhưng UX có thể được cảm nhận theo những cách khác nhau và đôi khi được sử dụng như thuật ngữ thông thường (để biết rõ hơn, bạn có thể xem bài viết của Hans-Christian Jetter và Jens Gerken “Một mô hình UX đã được đơn giản hóa cho ứng dụng thực hành”). Nhưng UX không chỉ về tương tác giữa con người và máy tính (HIC), khả năng sử dụng hoặc về cấu trúc (IA) mặc dùng khả năng sử dụng là phần quan trọng nhất định hình nên UX.
Một số nghiên cứu cho thấy rằng nhận thức về UX là khác nhau. Tuy nhiên, mọi người vẫn đồng ý UX là cách để người và máy tính tương tác với nhau hơn là HCI truyền thống (Xem bài viết của Effie Lai-Chong “Understanding, scoping and defining user experience: a survey approach”). Trong khi HCI có liên quan đến nhiệm vụ, giải pháp, mục tiêu cuối cùng và thành tựu thì UX còn vượt xa hơn. UX bao gồm cả những khía cạnh khác như cảm xúc, sự hưởng thụ, thẩm mỹ, tình cảm và kinh nghiệm. Khả năng sử dụng nói chung có thể đo lường được nhưng các yếu tố khác tích hợp thành UX thì không dễ để đo lường.

Mô hình UX của Hassenzahl’s

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?



Rất nhiều mô hình UX đã được đề nghị, một trong số đó dựa trên mô hình của Hassenzahl. Mô hình này giả định rằng mỗi người chỉ dùng một số thuộc tính khi sử dụng sản phẩm hay dịch vụ. Nhưng chúng ta có thể thấy có những thuộc tính khác nhau cho mỗi người dùng cá nhân. UX là kết quả của việc kết hợp các thuộc tính này vào một sản phẩm được sử dụng.
Tất cả các thuộc tính có thể phân thành 4 nhóm chính: thao tác, nhận diện, kích thích và gợi ý. Những thuộc tính này có thể chia thành mức độ cao hơn, nhóm thực tế và nhóm hưởng thụ. Trong khi các thuộc tính thực tế liên quan đến việc sử dụng thực tế và chức năng của sản phẩm, nhóm hưởng thụ liên quan đến các thuộc tính tâm lý người sử dụng. Hiểu rõ về sự phân chia này sẽ giúp chúng ta hiểu cách làm thể nào để thiết kế sản phẩm có liên quan đến UX, và làm rõ lý do tại sao UX không thể được thiết kế.

Thao tác

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?
Trong mô hình này các thuộc tính thực tế liên quan đến thao tác của phần mềm. Về cơ bản, thao tác là các chức năng cốt lõi của sản phẩm và cách sử dụng các chức năng. Thông thường, chúng ta cho những thuộc tính này là khả năng sử dụng. Hậu quả là sự hài lòng. Sự hài lòng xuất hiện nếu người dùng một sản phẩm hay dịch vụ để đạt mục tiêu nhất định và các sản phẩm và dịch vụ đáp ứng được những mục tiêu đó.
Ví dụ các thuộc tính thông thường của trang web (và phần mềm nói chung) là “hỗ trợ”, “hữu ích”, “rõ ràng” và “có thể kiểm soát”. Mục đích của một sản phẩm phải rõ ràng và người dùng cần hiễu làm thể nào để sử dụng nó. Cuối cùng, thao tác được xem là thuộc tính quan trọng nhất góp phần tạo nên UX.

Có thể nhận diện

Mặc dù thao tác là quan trọng, một sản phẩm cần có các chức năng khác. Đầu tiên là có thể nhận diện được. Hãy nghĩ về việc có rất nhiều item kết nối sẽ cho thấy bạn là ai, bạn quan tâm đến điều gì và thậm chí một số thông tin rất quan trọng hơn một số khác. Chức năng thứ cấp là để liên lạc với người khác. Vì vậy, để thực hiện chức năng này, người dùng cần có thể thể hiện chính họ.
Sự phát triển của các phương tiện truyền thông có thể được giải thích bởi các chức năng nhận diện này. Trước đây, chúng tôi sử dụng trang web cá nhân để cho mọi người biết về sở thích và thú cưng. Bây giờ chúng ra sử dụng mạng xã hội.
Facebook, blog và rất nhiều dịch vụ online khác có thể giúp nhận diện chúng ta là ai và chúng ta làm gì, các sản phẩm được thiết kế để hỗ trợ cho việc nhận diện. Ví dụ MySpace, lợi dụng chức năng để xác định thông tin cá nhân, nó cho phép người dùng tùy chỉnh hồ sơ của họ để thể hiện bản thân. WordPress và các trang khách cho phép các blogger chọn theme và thể hiện thông qua nội dung, người dùng có thể update tình trạng trên Facebook, Twitter và tất cả các trang xã hội khác.

Chức năng kích thích

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?
Nguyên tắc Pareto hay còn được biết là nguyên tắc 80-20, cho rằng 80% các nguồn có sẵn thường được sử dụng bởi 20% các hoạt động. Trước đây, nguyên tắc cho rằng việc sử dụng kỹ thuật truyền thống cần bao gồm các tính năng là không cần thiết vì phần lớn chúng hiếm khi được sử dụng.
Điều này là cần thiết không chỉ riêng với UX, bởi hiếm khi người dùng sử dụng chức năng kích thích. Các chức năng này hiếm được sử dụng để có thể kích thích và thỏa mãn người dùng để phát triển cá nhân và các kỹ năng. Một số có thể giúp ích bằng cách cung cấp những hiểu biết và ngạc nhiên.
Từ quan điểm này, các chức năng không hữu ích nên giảm bởi chúng hiếm khi được sử dụng. Nếu giữ lại, một ngày chúng chỉ có thể được phát hiện bởi một người và có thể mang lại cho họ sự ngạc nhiên và trải nghiệm tích cực. Kết quả là người dùng có thể nghĩ rằng đây là một ứng dụng tuyệt vời, thậm chí còn thích nó hơn.
Trên thực tế, đây là chính xác những gì tôi nghĩ và tự tìm thấy khi Gmail thông báo cho tôi rằng tôi đã quên đính kèm file mà tôi đã lưu ý trong email. Nếu bạn thực hiện thao tác tìm kiếm với “gmail attachment,” với Twitter, bạn sẽ thấy kết quả làotherswhofeelthesame.
Hơn nữa, tôi nghĩ tôi nghĩ nó cũng rất tuyệt khi Youtube bằng cách thay đổi logo trên SuperBowl Chủ nhật (hoặc ngày Valentine). Tôi cũng tìm thấy một số tương tự như khi tôi dùng MailChimp, tiếng “Psst, Helge, I heard a rumor…” làm tôi liên tưởng đến bài hát Bananarama songtrên Youtube. Có rất nhiều ví dụ và chức năng kích thích tốt nhất có thể không được mong đợi nhưng vẫn rất tốt (như thông báo của Gmail).

Gợi ý

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?
Theo mô hình Hassenzahl, chức năng thứ tư mà một sản phẩm cần có là gợi ý thông qua bộ nhớ. Chúng tôi thích bàn luận và suy nghĩ về sản phẩm mỗi ngày (thậm chí là sản phẩm của ngày hôm qua) và chúng tôi muốn những gợi ý có thể giúp điều này. Ngay cả những món quà lưu niệm đầy bụi và vô dụng (có chất lượng thấp) có chức năng gợi nhiều liên tưởng vì chúng giúp chúng ta gợi lại quá khứ.
Trong thiết kế, chúng tôi chắc chắn có thể cung cấp một trang web có phong cách cổ điển và có thể nhắc nhở về thời thơ ấu, những năm trung học, những năm 60 hoặc những năm 30. Tuy nhiên điều đó cũng có thể thực hiện với các trang web có thiết kế hiện đại và nhỏ gọn. Ví dụ, facebook và Flickr (thông qua người sử dụng và bạn bè của họ) cung cấp cho bạn lượng lớn hình ảnh, một số được đánh giá cao trong việc đưa ra sự liên tưởng.

Vì vậy, tại sao UX không thể thiết kế

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?
Tất cả đã cho thấy tại sao UX không thể thiết kế? Bởi UX không chỉ phụ thuộc vào sản phẩm và còn phụ thuộc vào người dùng và tình huống họ sử dụng sản phẩm.

Bạn không thể thiết kế người dùng

Người dùng là khác nhau. Một số có thể dễ dàng thực hiện khi dùng trang web và một số khác thì không. Một sản phẩm mang lại sự kích thích tùy thuộc vào kinh nghiệm người dùng với nhưng sản phẩm tương tự. Người dùng so sánh các website và có những kỳ vọng khác nhau. Hơn nữa, họ có mục tiêu khác nhau và vì vậy họ sử dụng những gì bạn đã thực hiện trong những tình huống khác nhau.
Khi đánh giá thực phẩm và dịch vụ tại một nhà hàng, bạn sẽ thường so sánh kinh nghiệm của bạn với những khách sạn mà bạn đã từng tới. Chúng hình thành kinh nghiệm của bạn. So sánh những kinh nghiệm trước đây, chắc chắc khác nhau. Với các phần mềm, trang web và các ứng dụng cũng vậy. Chất lượng hác nhau, chỉ đơn giản chúng là duy nhất và độc đáo.

Bạn không thể thiết kế tình huống

UX cũng phụ thuộc vào bối cảnh mà sản phẩm được sử dụng. Tình huống có thể vượt xa những gì được thiết kế. Có thể xác định lý do tại sao một sản phẩm được sử dụng và hình thành mong đợi của người sử dụng.
Trong một vài trường hợp bạn có thể muốn tìm hiểu và tận dụng lợi thế của các tính năng trong WordPress. Trong một số trường hợp khác, các chức năng tương tự có thể gây phức tạp cho bạn. Trong một số trường hợp bạn có thể thấy chú khỉ MailChimp thật tuyệt khi nói ngẫu nhiên với bạn “5h ở một nơi nào đó”, trong trong trường hợp khác, nó sẽ hoàn toàn kỳ lạ và gây phiền nhiễu bởi bạn đang sử dụng các ứng dụng trong các chế độ khác nhau.
Hơn nữa, UX phát triển theo thời gian. Lần đầu tiên người dùng thử một ứng dụng, họ có thể nhầm lẫn và có một kinh nghiệm tiêu cực. Sau đó, khi họ sử dụng nó và thấy các tính năng và tiềm năng, cách để xử lý, họ có thể cảm thấy gắn kết hơn và UX trở nên tích cực hơn.

Chúng ta có thể thiết kế cho UX

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?
Một số nhà thiết kế tự cho là “UX Designer”. Điều này là sự tự tin rất lớn trong khả năng của designer; nó cho thấy trải nghiệm người dùng có thể thiết kế. Nhưng như đã giải thích, chúng ta không thể làm điều đó. Thay vào đó, chúng ta có thể thiết kế cho UX. Chúng ta có thể thiết kế sản phẩm hoặc dịch vụ, có thể loại đi kinh nghiệm người dùng trong khi thiết kế. Tuy nhiên, không có gì đảm bảo thiết kế của chúng ta sẽ được đánh giá cao cách mà chúng ta muốn (một lần nữa, hãy xem Hassenzahl). Chúng ta không thể tình huống mà chúng ta đã thiết kế.
Chắc chắn đó là một ý tưởng khá tốt trong những cách tiềm năng người sử dụng đánh giá những gì chúng ta đã làm, như cách Oliver Reichenstein đã đưa ra. Phim ảnh, hùng biện và xây dựng thương hiệu chứng minh: kinh nghiệm là nhất định và họ cũng thường đạt được mục tiêu của họ.
Tuy nhiên, một vào bộ phim kinh dị sẽ càng kinh dị hơn trong nhà hát hơn ở nhà, bởi môi trường vật lý là khác nhau (ví dụ như tình huống của UX). Trong cùng một cách, hiệu quả của quảng cáo luôn phụ thuộc vào bối cảnh nó sử dụng và ý nghĩa quan trọng và hiểu biết của khách hàng (ví dụ kinh nghiệm trước đây của người dùng). Các quảng cáo thương mại được thiết kế ở một kinh nghiệm nhất định, nhưng mức độ thành công phụ thuộc hoàn toàn vào các quảng cáo của mình.
Sự khác biệt giữa thiết kế UX và thiết kế cho UX là rất tinh tế nhưng quan trọng. Nó có thể giúp chúng ta hiểu và nhắc nhở về những hạn chế của chúng ta. Nó có thể giúp chúng ta biết làm thế nào để có UX mà chúng ta muốn.
Như đã gợi ý, UX là tổng các yếu tố nhất định, như cảm xúc vui vẻ, khả năng sử dụng, động cơ, kinh nghiệm, sự tham gia và cam kết của người dùng (để thấy rõ hơn, hãy xem bài viết của Marianna Obrist: “Evaluating user-generated content creation across contexts and cultures”). Đổi lại, chúng ta phải giải quyết các yếu tố này khi chúng tôi thiết kế cho UX, tùy thuộc cách chúng ta muốn sản phẩm được cảm nhận như thế nào. Nếu chúng ta muốn một ứng dụng chỉ để cho vui, chúng ta cầm thêm vào một số yếu tố giải trí, truyện vui, bài kiểm tra thử thách, video vui, thử thách hay một cái gì đó khác. Chúng ta nên nhớ, là nhà thiết kế, chúng ta không bao giờ dự đoán rằng ứng dụng sẽ được người sử dụng thích thú. Người dùng có các tiêu chuẩn khác nhau và thậm chí đôi khi họ không muốn giải trí.

Làm thế nào thiết kế UX

Hướng dẫn: Tại Sao Không Thể Thiết Kế UX?

Hiểu UX

Nếu chúng ta muốn thiết kế cho UX, chúng ta cần hiểu UX nói về cái gì. Ví dụ, hiểu biết cách người sử dụng đánh giá một sản phẩm như thế nào là tốt và mô hình UX của Hassenzahl là một trong những mô hình khá hay.
Các mô hình khác cũng được cho là khá hay, ví dụ “7 khía cạnh của trải nghiệm người dùng của Peter Morville. Ở đây, UX được chia thành “sự hữu dụng, khả năng sử dụng, dễ tiếp cận, đáng tin cậy và có giá trị”. Như bạn có thể thấy những khía cạnh này khá phù hợp với mô hình Hassenzahl: hữu ích, có thể sử dụng, dễ tìm, đáng tin cậy và truy cập có thể coi là chất lượng thực tế (tức là tiện dụng và các khả năng sử dụng có liên quan), trong khi mong muốn sử dụng và có giá trị có liên quan đến yếu tố hưởng thụ.
Như đã đề cập, UX cũng được xem là tổng hợp các yếu tố cụ thể. Các mô hình khác cũng là đề xuất tốt, một trong só đó:

Hiểu người sử dụng

Chúng ta cần hiểu người sử dụng. Các phương pháp truyền thống chắc chắc được áp dụng, chẳng hạn như nghiên cứu người sử dụng bằng các bảng câu hỏi, phỏng vấn và quan sát. Ngoài ra, tính cách cá nhân được xem như là phương tiện thiết kế cho UX, mô hình UX mà Smashing Magazine đã trình bày trong round-up of methods.

Vượt cả mong đợi

nguồn vnwordpress.com

Cuối cùng, cho người sử dụng có được những gì họ muốn và hơn thế nữa. Thêm vào môt số dịch vụ để người sử dụng thấy sự hiệu quả, làm họ nghĩa rằng nó vượt mong đợi của họ: “Các ứng dụng này thật tuyệt”. Nếu bạn làm như vậy, họ sẽ sử dụng trang web không phải vì họ phải sử dụng mà vì họ muốn sử dụng. 

7 thg 9, 2012

Beyond Wireframing: The Real-Life UX Design Process


We all know basic tenets of user-centered design. We recognize different research methods, the prototyping stage, as well as the process of documenting techniques in our rich methodological environment. The question you probably often ask yourself, though, is how it all works in practice?
What do real-life UX design processes actually look like? Do we have time for every step in the process that we claim to be ideal? In this article, I’ll share a couple of insights about the real-life UX design process and speak from my own experience and research.

User-Centred Design: Truth Vs. Fiction

A few years ago, I joined one of the biggest e-commerce companies in Eastern Europe. When I entered my new office, I immediately spotted a huge user-centered design (UCD) poster on the wall. The whole process was described in detail that left hardly any doubts about the step-by-step approach to design. Exciting interior design for an aspiring UX designer, right? I stared at the poster with great hope and imagined how exciting following the ideal UCD process would actually be. Guess what? They didn’t apply a single step from the poster to the actual process. They never did any research, nor any serious analysis of user behavior. Yikes, they didn’t even prototype! This fancy poster simply hung shamefully on the wall.
For the next three years, we worked hard to put user experience design at the heart of a developer-driven culture. We forgot about the poster and structured our own process, which fitted well with the company’s capabilities and allowed us to constantly optimize our main service. Why didn’t we use the crystal-clear theoretical approach? Because we couldn’t afford to go step by step through a classic UCD process with a lot of different activities. It would have taken too much time, and therefore it was economically invalid — the budgets for our projects were way too tight.
To deliver a user interface on time, we were forced to get really lean. We used a classic UCD process as inspiration and created a process that was simple but actionable for the company. We defined the problem, defined the scope of the project, iterated through paper prototyping and wireframing, pushed code to production as fast as we could, and always used multivariate split-testing and detailed Google Analytics event tracking.
Post-launch was the time to measure and plan optimization, which we executed immediately. Unfortunately, only huge projects had budgets for qualitative testing. Huge projects were also full of preliminary diagrams (site maps, flow charts, conceptual diagraming) — a enormously recommended activity to find order in a complex mess of information.
All in all, our process was simple but efficient. Of course, in general terms, it was a UCD process, but compared to any popular approach and a famous UPA poster, we used about 20% of the recommended tools and studies. We assumed that users don’t benefit from poster unicorn processes. Users benefit from the hard work of a product team; therefore, a simplified process is better than a robust unactionable theory.
UPA UCD Poster
Designing the user experience. (Large version)
Suddenly, I started to wonder how others managed to apply UCD. There’s a lot of talk about wireframes, but what does our work look like beyond wireframes? Was I the only one with a simplified approach? What can we do to create successful designs? What does the process beyond “the poster” look like? Is there a pattern that works well for the majority of designers?

The Reason For Research

Luckily enough, I was about to find some answers to my questions about the design process. I was forced to perform a worldwide reality check on my opinion about the classic UCD approach and design processes. Sharing this reality check is the raison d’être of this article.
  • If you’re fresh in the UX design world, learning how more experienced designers work might be useful.
  • If you’re a seasoned designer, treat this article as an incentive to reconsider your approach to design. We’re all rushing our designs every day. This is the time to take a breath, see what others are doing and think about what works and what doesn’t work in our real-life approach — beyond a UCD poster.
You may wonder what force persuaded me to revise my approach to the design process. The answer is simple: my own startup. Together with my friends, we created paper prototyping notepads to make our process more efficient, and then we created our own collaborative wireframing application. We suddenly became quite popular, took VC investment and decided to face the challenge: to create a user experience design toolset to support teamwork in the design process.
We felt that we were trying to fight Godzilla (or Tywin Lannister, if you prefer Game of Thrones to old Japanese movies). If my UX teams couldn’t apply a classic UCD approach, how could I be sure that using any theoretical framework would enable me to design a toolset that fits anyone’s real-life process? I couldn’t. Is there any pattern in design processes that we actually apply in our companies? I had no idea.
We felt that we needed to find out the truth about real-life design processes and we needed it now. It appeared to us that our research might be of vast importance to the community and even beyond. A simple equation: a great tool for the design process equals less work for designers on the tools side, equals more time for creative work, equals better designs for all of us.
The stakes were great, and there was just one right thing to do: get out of the building, get our hands dirty with research, find out and learn about the real-life design process (if it exists), and literally hunt out pain points in it to make the work of our team much easier and more pleasurable. We packed our stuff and crossed the great pond, so to speak, to do some serious research in San Francisco and Silicon Valley. Read on if you want to know what we found out about the design process!

The Customer Development Process And Tons of Individual In-Depth Interviews

The life of a modern startup is full of UX design work, even if the founders don’t realize it. Drake Martinet (Wall Street Journal, Stanford University) considers the whole lean startup movement to be a mere application of design principles to the business environment. I couldn’t agree more.
When starting a new project, you actually need to talk to people from your target group. Here comes what are well known as IDIs (individual in-depth interviews): moderated, individual interviews in which you try to learn as much as you can about the problems of your interlocutor in a particular area of their life.
Our target group was user experience designers, so we scheduled above 50 interviews (personally and via Skype). Each focused on the same theme: the real-life UX design process. We asked designers to tell us stories of their usual process based on one of their projects. During the interviews, we asked a ton of in-depth questions to learn as much as we could about the process.
We hardly asked about problems in the design process, though — we tried to spot them in the stories on our own and then confirm our judgment by asking questions (for example, “I understand that X was troublesome in this particular project?”). We tried as hard as possible not to push any views onto our interlocutors. Letting them speak was important.
We interviewed UX heroes Mike Kuniavsky, Indi Young, Luke Wroblewski, Peter Merholz, Brandon Schauer, Jeffrey Kalmikoff and John Zeratsky and some lesser-known but excellent UX designers. Among our interlocutors were in-house UX designers, designers from consultancies and freelancers. Surprisingly enough, the problems that usually trouble UX designers were similar in all three groups.
It was an intense learning experience, and I highly recommend considering such preliminary research in every project. It will give you a ton of ready-to-use knowledge — a kind of canvas to work from.

The Process That Emerged From Designers’ Stories

First of all, we didn’t find any unicorns, but we did find racehorses in excellent condition. While all of the processes that emerged from the stories were somehow simplified UCD processes, they were tailored to the specialities of the designers. Flexibility is what helps us survive in the diverse jungle of projects. Processes morph to fit projects.
The approach to an e-commerce website differs from the way we design mobile apps in the healthcare industry (guess where context analysis matters most?), and government clients differ from corporate stakeholders and startup entrepreneurs, and so on. With few exceptions, though, the process looks surprisingly similar. There is a visible pattern that we all use to design interfaces in different environments:

1. COLLECTING INFORMATION ABOUT THE PROBLEM

Every UX designer needs to be a kind of detective in the early stage of a project. We need to find out as much as we can about the three Ps (people, problem, project). Activities in this stage, in contrast with the classic UCD approach, are vastly simplified:
  • Meeting with the client (no matter whether externally or internally) and identifying the product’s requirements (often in the form of a standardized product requirement document);
  • Benchmarking and trend analysis (oh yes, most of the designers we interviewed do that).
We seldom perform user interviews, but writing user stories is one of the commonly accepted attachments to the product requirement document. Our user stories are sometimes created based on personas, which are hardly ever backed up with data. Field studies and task analysis are hardly used by any of the designers we interviewed.

2. GETTING READY TO DESIGN

This is clearly the ideation part of the process. It’s completely conquered by analog tools. I haven’t met a single designer who doesn’t use quick messy sketching or some other paper prototyping form at the early stage of a design process!
Designers try to act on the material gathered in the first step of the process and find a design worth refining. This stage is not about documenting; it’s about artistic fury and creative explosion. Many of us use Adaptive Path’s multipage templates to quickly create very generic sketches.
Unfortunately, testing lo-fi prototypes is not popular. We prefer to take the risk of choosing one option with a stakeholder and begin the refinement process. Not very UCD-like, but that is the reality.

3. DESIGN

In contrast to the anti-documentation agile approach, most of the interviewed designers create wireframes and prototypes to document the experience and then hand them to the developers.
Refined sketches from the previous stage are still rather lo-fi and are usually not tested. Hi-fi design is left for visual designers. In Aristotelian terms, we create the form, while developers and visual designers fight to create the matter. Heuristic evaluation is definitely out of fashion, while expert review backed up with a cognitive walkthrough is quite popular.

4. APPROVAL

This is surprisingly an important part of the design process. Research documents and deliverables usually also serve as persuading factors in the “buy-in” process. This does not differ between in-house UX designers, freelancers and folks from consultancies.
Buy-in is the unfortunate peak of our process. None of us want to see our work go directly to the trash, and I’ve seen some great projects rejected just because the story behind the design process wasn’t particularly persuasive.
And guess what? A lot of the interviewed designers actually create a special presentation to tell stakeholders the design story. The presentations show stages of the process, deliverables and interactions, and they aim to give stakeholders lazy access to all of the information.
The four points mentioned above form a pattern visible in the majority of design processes that we went through with our interlocutors. You might have noticed that not a lot of iterative research is done in these processes. Sadly, the classic usability study is not a permanent part of the process. Why? The answer is simple: budgets are tight. Problems that appeared in the company that I used to work for appeared to be common. Tight budgets are forcing UX designers to tailor their processes and skip costly research.
I believe the best answer to this problem is guerrilla research methods. Startups do adapt guerrilla research as a part of the customer development process, but more “mature” companies, in my opinion, are strangely afraid of spontaneous and methodologically questionable yet efficient and cheap research methods. One of the challenges of the UX design community in the coming years will be the popularization of guerrilla research methods and bringing them into our real-life design processes.

Houston, We Have Several Recurring Problems

During our research, we tried to spot recurring problems in the design processes of our interlocutors — a so-called pattern of pain. Surprisingly enough, similar problems appeared in almost all individual interviews. Apparently, a lot of us live arm in arm with three tough unresolved problems that tend to slow us down:
  1. Spreading an understanding of the design process
    How to engage the whole team in the process and show them that UX designers are not people who lack talent in visual design yet still insist on drawing something? How to teach that there’s user experience beyond wireframes?
  2. Communication within the team
    How to communicate with a team throughout the process and actually use different perspectives of teammates to evaluate design deliverables?
  3. Demonstrating the process to get buy-in
    How to present the design process to stakeholders and developers to actually get buy-in, both formally and psychologically?
One of the UX designers we interviewed said the following:
Do you know what the most painful thing is in my job? Bureaucracy. Having to go to meetings. I would rather design than fight over the picky details. We should make at least part of the workflow online instead of in person. Have the approval process online, instead of in a meeting.
Another said this:
It’s really hard to show the process to clients and spread some understanding of the importance of design.
We have probably all tried to solve these problems countless times, but we still lack efficient and fast methods. This results in less time for creative work and research.
My hypothesis is this. We as UX designers need to resolve the three painful problems identified above to have more time for creative work and research. We need to demonstrate our work beyond wireframes, spread understanding of UX design and, in fact, sell ourselves both internally (within the product team) and externally (outside the product team, in front of clients and stakeholders). This is the recipe to increase our effectiveness.
Our real-life UX processes need adjustment, and since we share the pattern of the process and the pain points, we can solve them together. This is most likely the most positive outcome of this research.

Outcome Of The Research

The research shows that UX designers are constantly modifying the classic and complex UCD approach. Less emphasis on iterative usability studies and a narrower range of design activities (compared to classic UCD) are the main traits of the current real-life design process that have emerged from our research.
A process tailored to the capabilities of our companies and our clients proved to be generally effective, but it still causes some recurring troubles that should be eliminated.
This is, generally speaking, the state of our field. Don’t get me wrong: I don’t mean to criticize classic UCD — it still serves as an inspiration for our work. After all, I’m happy that I worked in that office with “shame” hanging above my head (yes, I mean the UCD poster), which constantly reminds me of the need for adjustment in the process. I’ve learned that what matters, though, is an actionable process — possible to use, adapted to the company’s culture and financially effective.
After talking with dozens of UX designers, I’ve started to wonder, however, whether we should actually create a poster that shows this version of the process. It could help a lot of aspiring UX designers take their first steps in the field and could be effective as an educational tool for our internal and external clients.
After all, our work is not nearly as expensive and time-consuming as the old poster says.
P.S. A study of the process and the problems spotted in it inspired us to create “The UX Design System” — it’s a work in progress, and I’d love to hear your feedback.

Source : smashingmagazine.com