Thursday, February 6, 2014

How to Change Icon Color in 7 Steps

As a user experience architect, I do not do visual design myself. However, last month I needed to change the colors of some icons that was handed over to me (from Grey to Blue). I thought that should be simple and straightforward task. I searched online for the Photoshop solution but I did not find anything useful. I found vague responses on StackOverflow, which were least helpful to me.

So, I got in touch with my visual designer friend to demystify the approach. He gave me the solution that was straightforward and simple and worked for mono-colored icons. Here are the steps:

  1. Import the icon in Photoshop.
  2. Using Marquee too, select the area you want to apply the new color to.
  3. Lock the layer.
  4. Select the foreground color by picking on the foreground color icon in left hand tool bar.
  5. Enter the desired color values in the Color Picker dialog box and hit OK.
  6. In "Edit" click on "Fill.." or hit "Shift+F5" to invoke Fill dialog box. Ensure "Foreground Color" is selected in the dropdown menu and hit OK.
  7. Save the image with a different name.
Enjoy changing icon colors!

Thursday, August 1, 2013

Is Responsive Design the Answer to Mobile Design?



Mobile design has come a long way. It all started with native apps, then came an era of hybrid apps, then designers went crazy for mobile web (creation of mobile version of websites).
Lately, designers and developers are beating the drum for “Responsive Design.”

At least for now, responsive design appears to be a silver bullet to address all the design issues pertaining to various screen sizes – it is very promising. Responsive design works on the philosophy of: “design once and for all.” Meaning, there is no need to maintain multiple sites, which helps decreasing the development costs. The site – with a single url – renders itself differently on different devices by analyzing the query type using flexible grids, layouts.

So, is responsive design truly the solution to all problems? Most of the posts and blogs indicate that it really depends on user’s context than anything else. Some companies are creating a mash-up of both mobile and regular sites.

eSurance realized that their mobile users had different content needs than desktop users. For example, the mobile users needed contact and policy information handy in case of an accident. On the other hand, desktop users don’t really care for this kind of information. Therefore, they had to create two different sites. Responsive design didn't work for them.


In conclusion, there is no shortcut to identify whether a responsive site or two different sites – one for desktop and one for mobile users – are required. Therefore, as designers it’s our prerogative to go hard on user research to identify correct user scenarios and design accordingly.

Monday, April 8, 2013

Design Lessons - iPad Application for Supplemental Insurance Agents

Lately, I designed an iPad app for supplemental insurance agents for a global client based out of Chicago. Designing for mobile is always fun because of its connectivity and size constraints. Below are some of the design lessons from the insurance domain that I would like to share.


Supplemental Insurance Industry Context


  • The retention rate for sales agents is very low, at least for this client. Every year 2000 new sales agents are recruited to maintain an average of 1300 agents on payroll.
  • For effective selling, agent training is a significant part of the hiring process. Due to low retention rate, the training costs are pretty high.

Sales Agent Usage Context


  • Uses heavy paper binders for references on medications, sickness, product related brochures, during sales process
  • Spends significant time prospecting – customer conversion rate is less than 10%
  • Services customers in various locations; therefore, internet connectivity on iPad cannot be taken for granted
  • Works with both office and residential customers
  • Works at variety of locations: parks, coffee shops, fairs, homes, offices, inside the car, etc.

Design Considerations


  • Design for portrait mode (default) to accommodate more content (long forms, brochures, etc.).



  • Divide the content (long forms) in multiple sections and sub sections with expand and collapse functionality  For e.g. create a master section with expand/collapse functionality and create nested sub-sections with their own expand/collapse controls.




  • Use lookups with both alphabetical (A -> Z) navigation and search capabilities to reduce errors. List of medications and health conditions can be pretty long; their names are confusing and homo-phonic.







  • Reduce key strokes wherever possible, typing on iPad is not very user friendly. For e.g. Carry over the information that’s already entered in the form; e.g. names, addresses, etc.






  • Use wizards, wherever possible, to ensure 100% form completion and reduce training costs. Do not create a linear wizard; instead, allow the agent to hop back and forth between various steps – sales process is highly dynamic and unpredictable. A customer may demand an agent to show something from a step which may not be the next.






  • Allow the agent to save incomplete forms for future use. Sometimes prospect takes couple of days before making the final decision to pay for the insurance.



  • Make the forms editable as long as they are not submitted to the system for final processing.





  • Create effortless payment steps. Customers could use different payment methods or multiple payors for same or different policies – consider edge case scenarios.



  • Create an easy to read and sign payment summary screen. Customers like to read the application summary before approval.



  •  Create large area for signatures with a finger on touchscreen





  • Provide clear directions on every step if the agent needs to switch to paper for some reason






  • Use two or three column layouts for side-by-side comparison of rates and policies.



  • Agents need to know – just in time – if the customer doesn't qualify for insurance. The disqualification cue on the UI has to be subtle enough to not catch the customer’s eye.  Disqualification from one insurance type doesn't disqualify the customer from other insurances. Therefore, customer relationship, even with a disqualified customer, is really important – he can always refer the agent to his friends and family.






Of course, every project is unique and brings its own set of problems and challenges. Irrespective, we should try to leverage device or OS’s guidelines and patterns as much as possible for better user adoption.

Tuesday, April 2, 2013

Human Factors – Bed Time Reading on iPad


51% of iPad use is in bed or in front of the TV – according to Neilsen. 61% percent of eReader owners use their device in bed, compared with 57% of tablet owners and 51% of smartphone owners. Sorry, I don’t have the new numbers.

Some people are trying to solve the problem – to read effectively on iPad in bed – by creating plethora of kitschy products.

That’s why as designers, it’s very important for us to understand the context of use to create user friendly applications.



I use my iPad primarily during the bed time to read news and books. In bed, when I read on iPad, lying straight on my back, my viewing area or (scanning area) becomes almost half of the iPad screen length.

Unless I am using lot of pillows (in bed) to elevate my head from the rest of my body, it’s really difficult to view the whole iPad screen easily. Of course, I can hold the iPad slightly higher to make it easier for my eyes to scan the whole screen; however, its weight adds a lot of stress on my arms if continued for a long duration.

It’s incumbent upon us as designers to recognize this problem and provide better design solutions. Let’s not get into product design here; the easy fix is to first recognize the reduced screen scan area during lying on back and design for it.

For the same reason, browser based sites with long scrolls work like a charm for me - when I reach the middle of the page, instead of lifting my head or iPad up to read the bottom half of the screen, I just swipe the page up and bring the new content to the top half. On the other hand, reader applications like “Kindle” do not work in this scenario – at all, and cause lot of annoyance and frustration. Every time I reach the middle of the page, I am forced to lift the iPad screen or my head to view the content in the bottom half.

One solution could be around creating long scrolling pages instead of using paginations. Or provide the user an option to switch between long scroll and pagination based on his context.
I am sure some of you are also facing the same problem. But, we cannot just leave the problem for others to solve for us. We are the problem solvers, we are the designers.

Friday, December 7, 2012

Is Sitemap Dead?


Sorry, but I needed an interesting subject to draw your attention. Did it work? J

I am facing a growing problem of explaining the concept of sitemap effectively to our clients. It’s very important for the client to understand an artifact clearly – if we are seeking approval on it.

The problem is arising because of the connectedness and dynamism of the content and functionality that today’s technology offers. Gone are the days of static HTML pages, where the user used to navigate on pre-defined paths on the sitemap. We are in the era of portlets, multi-layered dynamic UI, widgets and context sensitive controls.

In today’s world, sitemap:

  • Is not a page hierarchy; It’s not information hierarchy either
  • Doesn’t “truly” represent hierarchy levels because the content/functionality can be accessed from multiple routes
  • Doesn’t map to user flows either


So, the question is: how to best present the sitemap to the client? Moreover, how to explain it effectively and clearly?

  • Are we doing the sitemap because it has been part of our deliverables – historically?
  • Does it really have any value? Shall we start doing conceptual sitemaps going forward, as the article (link below) suggests?
  • Does it makes sense to seek client approval on this – even when they don’t get it?


This article on Sitemap in UXMAG clearly defines my problem - http://uxmag.com/articles/is-the-sitemap-losing-its-client-facing-steam

I am attaching a conceptual sitemap as an example. Do you think that the conceptual model works better than traditional sitemap?

I would like to hear your experiences, comments, thoughts, and suggestion on the same.



Friday, October 14, 2011

Who Paid Tributes to Steve Jobs

Steve Jobs (1955-2011) touched so many of us through his high-end consumer products. His early demise has created a big void both in technology world and in our hearts. Everybody - including fans and foes - came together and prayed for his soul.

Here is how Apple, Google, and Amazon paid tributes to this visionary -


And, here is how Microsoft's Bing ignored to pay respects -



 *These screenshots were taken on October 6, 2011- a day after Steve's death.

Wednesday, October 5, 2011

Is Apple Going to Become Google of Voice Search


Like everybody else, I was not disappointed by iPhone 4S announcement. Everybody was expecting Apple to upgrade the phone, which Apple did with: new processor, camera, iClound, and iOS 5; however, it still has the same look and feel. Perhaps, that's why it's called iPhone 4S not iPhone 5.

"Siri" is now trending on Twitter. Though, I did not like the name but the idea of having a "voice controlled" personal assistant is very powerful. Siri does not, just, parse the words in a sentence but also makes sense out of it. This is a huge improvement and - sort of - a dream come true for a lot of us. I am sure that after Apple's announcement others are going to follow its footsteps.
Apple really needed something to exist in business for long term. The most powerful companies, today, are the ones who know the most about us. Sounds creepy, but that's really true. Think of Google and Amazon, both the giants know so much about us. That's why they can tailor their solutions for each of us.

Everybody was questioning Apple after it opened its data center in NC. Now, everything "really" makes sense. After the launch of iCloud, Apple launched Siri yesterday.

Siri will remain a beta product for sometime. It may not be a perfect personal assistant that you dream of, but it's a great beginning in Natural Language Processing space.

Now, here is the catch - Apple's data centers will not only be collecting mountains of data from iCloud but also be storing, managing, and analyzing voice queries using sophisticated natural language processing algorithms. Siri could, potentially, turn Apple into Google in terms of voice search – the next wave in search technology.

It’s a win-win situation for Apple. Apple may use Google search to retrieve results but all the "rich" data queries from Siri will remain with Apple. Google will not be able to use that data in any way.

Is Apple waiting to become Google of voice search? Only time will tell....

Thoughts?