One sentence I put out in the beginning of the article “Everything is related”. They can be functioning in different parts of a bigger plan, their view may conflict with each other; they may complement.
For the whole book “Lean UX”, it teaches you valuable Lean UX principles, tactics, and techniques from the ground up—how to rapidly experiment with design ideas, validate them with real users, and continually adjust your design based on what you learn. Inspired by
Lean and Agile development theories, Lean UX helps you focus on the actual experience being designed, rather than deliverables. This book shows you how to collaborate closely with other members of the product team, and gather feedback early and often. You’ll learn how to drive the design in short, iterative cycles to assess what works best for the business and the user.
4 of the key takeaways, that is actually the same takeaways of most of the books on UX nowadays seems to suggest:
- Conduct competitor benchmarking to see the pros and cons
- Involve the team in the design process using design studio/workshop
- Test the hypothesis/prototype as soon as possible
- Reflect the idea into the development as soon as possible
This brought me to think about 5 things that I did in the past that standing from today, I will consider to be wrong:
Competitor Analysis: I was doing competitor analysis just to look for how they design the interaction of a feature, but I have questioned very little why they do it or look around and see if it is good or bad, in other words, I am just copying what there is available on the market with very little value added:
I did this extensively when working as product manager in Lane Crawford, a fashion retail or in Hong Kong and China; the logic was that it is "safer" if we don't introduce new behavior into the market as users may find it difficult to learn.
Now that I think again and observe around, users learn very quickly if I design a good experience. Learning is natural. And the risk I have us to introduce "yet-another" same offering to the market, which I find hard to sell.
Collaborative Design: I have done few collaborative sessions, mostly with business analyst and designer, very rarely with developers and marketing.
Looking back, 3 main reasons I didn't do it:
- Too much time needed: I am submerged by all kinds of work, I don't have the time to prepare, conduct and analyze the results; and others seems not to have time as well;
- Ego and ownership: I believe as a product manager, I own the product and I should be the one who decide what is what;
- Lack of experience: I don't really know how to do it; I know roughly how it works but I have not done one in real life, most of them I have done before are just commenting on a design the team prepared;
- Bad time management: I am bad at time management, which result also in the first point that I think everything takes long;
I also need executive support, but for them to support me I need to show some evidence of benefits to them first. So I guess I will start inviting them.
Test A Lot: the company I was in before fells into the category of using focus group as usability test and testing if the idea will work just before the launch, I found my current company may have the tendency to do so as well.
I am sick and tired of this though. It is wasting my life if I do something the world does not want. And it is wasting everybody else's life as well.
Use the Test Result: there is little problem if the result comes early, a lot of problem if it comes late.
The second piece of reading I finished is the "Don't Let Me Think" (Chapter 11 to Chapter 13). It has a different focus than Lean UX and talked a lot about the practical skills and mentality that can be applied to everyday design.
In this 4 chapters, Steve focuses on usability following the guidelines to make a website "readable" for visually impaired people.
I made a checklist out or that and if you are interested, drop me a comment and I can e-mail that to you. Heret to summarize, 4 points:
- Write short and punchy sentences;
- Clear indicate of where users are at anytime;
- Easy to recover from mistakes;
- Test A lot;
The last point is very similar to what Lean UX also advocate, while Steve focus more on what to test and what not to do in the test. Things like don't force users to do something etc. He categorizes all UX in 4 types
- Interface Design
- Interaction Design
- Visual Design
- Content Strategy
The answer we look for determines what question we want to ask and then how we want to ask them (benchmarking; eye tracking test etc).
Another rather practical article I read in the past week " 10 Tricks That Chatbots Use to Make You Believe They’re Human" concerns about a specific feature, chat. The article is really talking about implementing a natural language chatbot where all questions are open-ended and the answers can be anything. The aim is to deceive humans from distinguishing if they are talking to a bot or a real human.
Not all 10 tricks are applicable to what I am seeking, I am not trying to develop a chatbot that will have a lengthy conversation with anyone, I am trying to develop a chatbot that will have a short and task-oriented conversation with a consumer over a product or purchase. I find 5 out of the 10 tricks useful:
One Sentence at a Time: the first I did after I read this title is to go back and find my past chat with anybody and observe the patterns. Yes, we break down the chat into sentences and we often text several sentences in one reply.
Crowdsource Replies: absolutely, the variation we have towards the same question, I mean, even the way we express a "yes", vary so much depending on who we are and who we are talking to. I am still to come out a good way of collecting these answers and add them into the DB but one thing for sure, I can't do think alone,
Develop a Character: one of the best way to make people believe that a bot is human is to make them believe they are a single specific human, someone that has limited knowledge and interest, can be selfish, can keep turning conversation to one subject. Say it is designed to be Butler for any reason, it would be using something like "Yes sir", "No madam"," I'll take care of it".
Applying the 3rd point would mean I am going to choose very distinct characters, say Butler, Soldiers, Truck Drivers, R&R Singers, Politicians, Fashion Designer etc, since many professions just don't have a recognizable way of communication. The other approach I can talk is to go for subculturws such as Hardcre punk, Hippe etc. From where I came from I don't observe many Subcultures but I knew it is very pervasive in US and EU.
There is one use case that I came across which is the IBM 小冰 chatbot on Wechat. The character it developed is a 5 year old girl, most of the question you throw at it, 小冰 would reply something like "I don't understand" or "this question is too difficult for a 5 year old".
I lost interest in 小冰 in less than 5 minutes. It does absolutely nothing useful for me, the only reason I think it exist is to ask users to help train the bot. The character building is successful, I do believe it is 5, or even younger, while it can improve with some more up-to-date knowledge on what a 5 year old should know from kindergarten, from the cartoon she is watching and from her parents etc. I have yet to see another bot with a Character, most are purely functional.
The last article I came across to be interesting is "Four Fundamentals of Work Place Automation" from Mckinsey. Through an analysis of over 20,000 respondence in their day-to-day activities, it found:
- Codifiable works are candidates for automation
- Few jobs get replaced, most jobs being redefined
- Automation is not relevant to salary but to the type of work
- Creativity and sense emotions are hard to automate
While I am yet to find if I "characteristic" interface would bring additional user value. I recognize it is a very collaborative process to collect humanized answers and questions to support the functional needs. To reduce the scope, identifying the most recognizable characters is the key.
At last, test the idea, I mean not only test the desirability and usability, it will be a good idea, layer on, to test if the character created is recognised by the user to be aligned with the same character in their mind.
Reference:
Four Fundamentals of Workplace Automationhttp://www.mckinsey.com/business-functions/digital-mckinsey/our-insights/four-fundamentals-of-workplace-automation
Lean UX: Applying Lean Principle to Improve User Experience by Jeff Gothelf & Josh Seiden Publisher: O'Reilly Media March 2013
Don't Make Me Think: A Common Sense Approach to Web Usability, 2nd Edition by Steve Krug
Comments
Post a Comment