During my recent visit to the U.S. I was trying to book a flight online from Atalanta to Los Angels. It was my first attempt to book flight online in U.S. and someone has suggested to book through Expedia.com. The overall experience of booking the flight was fine till the time I received the confirmation and I found out that I had given wrong dates. I was surprised by this and had to go through the pain of calling Expedia call center and getting the dates corrected and this obviously had a cost associated with it. Although the customer service agent at Expedia’s end was very helpful and gave me all possible options to correct my iternary with minimum cost. BTW my interaction with IVR system that accepted audio input was quit a fun. The recording quality and the tone of voice was so good that it took me sometime to figure out that I’m talking to a machine and not to a human.
After I got everything corrected, I gave a thought to this situation from design perspective. What could have been the reasons that made this mistake?
First my state of mind. I was in a state of excitement and sense of urgency when I did the booking. I had just received a formal acceptance of my leave from client and I was told that flight prices change very quickly here in US so book the ticket as early as possible.
Second the design, although Expedia had given the option to review my iternary before booking, it is evident that I had overlooked the dates.
Lets look at the design, although the travel dates are mentioned on the screen but tend to get lost if you are in a hurry. Possibly this is an opportunity to improve the design so that an excited first timer like me does not make mistake.
Well, I’ve decided to change the track…….once again !
and I believe it would take me to the destination I want to reach. The journey together so far has been enjoyable and rewarding but there is always a wish to explore new horizons.
It’s almost a year since I had rejoined UIDG in Mar 09. Thanks to Pramod and Kiran ! they preferred a known devil against a unknown angel. So it was known people, known organization and known problems but it was fun and comfortable.
Overall when I look back at my entire stint at MBT + Tech Mahindra. I feel it was a very significant period of my career. It marked my entry in to Interaction design from Product design and exposed me to whole new world of knowledge and opportunities. I think I was very fortunate to get this opportunity and I’ve done a justice to the confidence shown in me UIDG leadership and the entire UIDG team to the best of my abilities.
Having seen what I can now call as the ‘golden era’ of UIDG during my first tenure with all the senior people, researcher and the ‘previous Pramod’ ( for those who don’t know what is ‘previous Pramod’, please contact me separately we would need a separate session over a beer) the second one feels like a era gone by but that’s life and we’ve to accept it.
As I get to know myself better ( it’s high time, I’m 40 now!), I’ve realized that I’m little more academic in nature and more inclined to go in depth of anything that I do. Given this, a software services environment puts some constraints by its very nature of business. So I’ve decided to make a move in a product based organization. There I believe I would get the required ‘space’ and the ‘context’. (The grass is always greener on the other side. Few years down the line you will hear me saying how boring it is to work in product company)
Anyway, Today is my last working day at UIDG. You know the standard stuff that goes after this…. thanks everyone… opportunities I got …. friend I’ve made…..small world… our paths with cross in future……I wish you success….etc…..etc.
Simply put from tomorrow onward …
- No more company of the wonderful UIDG team ( well, some of ex. UIDGians will be around but I’ll miss most others)
- No more reminders for being RUS defaulter, SDK defaulter, Security exam defaulter, etc….etc……( I was always bad at following processes )
- No more panic calls to Hemant & Ninad after getting stuck in the impossible EBS (F). (It was my long time wish to master EBS but Ninad & Hemant were always way ahead.…)
- No more ( intellectual ?) discussion with Pramod over a coffee @ CCD( “A lot can happen over coffee… !)
- No more struggle to find a place in canteen for lunch during peak hours.
- No more post lunch stroll in Annex parking admiring the new car models by peeping through the glass ( believe me it’s the only place where you get to compare all car models next to each other)
- No more ‘chat’ ( both Hindi & English) and chai @ Ajuba ( I’ll be in Pune so I can always drop in @ Ajuba but it won’t be an everyday affair)
In case if you want reach me ( Attention- All UIDG job seekers)
Recently we had an opportunity to offer our User Experience design services to a client from Kuwait. Since it was a first of its kind assignment we were doing for a Kuwaiti audience it was very natural for us to go through cultural study. Our thought was that since Kuwait has such a strong tradition and visual culture, it would certainly have a impact on our design. We spend quite some time understanding Kuwaiti culture and traditions and presented our understanding with design implications to our customer point of contact.
The reply came, “This is old Kuwait. New Kuwait is not like this. Young generation here is all American. They want to buy best of the international brands and their lifestyle is completely westernised. Keep this new Kuwait in mind while designing.”
Is this not true for a Indian urban youth as well?
This raises few questions in my mind like what is really the relation between culture and design in todays context? What are we talking about when we say cultural identity in design? Are we all heading towards a ‘monoculture’?
The Indian software industry is broadly divided into two categories 1. Product organizations & 2. Services organizations. These days various services organizations in India have “User Experience” or “Usability Engineering” groups. These internal groups may have their own clients onshore but most often they are required to deliver their services to existing software development projects.
Most often there is a lack of collaboration between delivery teams and UX professionals and at times there are ego clashes about who should be in control. These are insights gathered from my limited experiences working on such projects.
# 1. The customers are coming essentially for development work and UX services are value add to the total deliverables.
a. It is not a need of the delivery team to engage UE group but it’s YOUR business need to get involved.
# 2. UX group should treat their internal customer with equal professionalism as that of external customers.
a. We’ve to embrace a collaborative working approach with internal customers.
b. Get out of the cubicle and sit with the developer .
c. We’ve to come out of this mindset that developers are a bunch of fools and we know more than them. In fact the customer is there because of them and not because of you.
# 3. UX professionals biggest drawback is the lack of domain, product and technology understanding. Unless they develop these, they can’t add value to the product.
a. UX groups usually have a short term engagement with such projects and they’re expected to add value in a very short span of time. Unless they are equipped with the domain & technology understanding, they cannot deliver value. It’s very long way for an offshore UE group to drive the product vision
b. Any developer with a firsthand experience with the technological object will be in a better position to comment on the interaction than an “Interaction Designer” without having an exposure to the technological object.
# 4. Lack of visibility of the larger picture. For any internal UX design service, the ultimate deliverable is an User Interface ( either usable or unusable) and User Interface is a small entity in the entire project lifecycle. The delivery team has much larger stakes in the delivery than a UX group.
#5. The dev team is most likely to have long relationship with the customer and we’ll be the new kids on the block. We’ve to respect the existing relationships.
#6. For most of the internal projects, there will not be enough room to practice the UCD methodology as described in the “UCD Holy book”
a. To claim that we practice UCD methodology for a US/UK client for a product to be used by American/British users sitting here in India is a myth.
b. It is mostly the “pattern language” approach that works.
In the similar context there is good article on UXmatters