UX

• Codename: Patronus.

• Time: Oct 2019 to present.

• Organization: HCL Software.

• Customers: 10+ enterprise products and websites with a wide user base.

• Platform: Responsive web, desktop and mobile. Design toolkits for Sketch and Figma, code libraries for Vanilla JS, React and Angular.

• Personas: Product designers, UI developers, enterprise end users.

• Releases: 4+ stable and major releases. Multiple minor and patch releases.

• Team: 4 designers, 5 developers, 3 testers, 1 dev manager across multiple locations in India, US and Italy.

• Role: Owning the design system, leading the design team, reviewing component designs, designing complex components, creating and maintaining design tokens, creating documentation, meeting regularly with the users, taking feature requests, deciding on how the system evolves.

The challenge

HCL Software had a wide range of sprawling enterprise products which were using a mixed bag of design systems, some none at all. Universally adopting an open source design system was possible but it would dilute the brand identity and custom requests were hard to field. Furthermore, the growth and direction of an open source system was not in the hands of HCL Software. Meanwhile, the products themselves are not mandated to use any specific design system, so they had to be convinced with due evidence to pick up a homegrown one.

The solution

We researched some of the leading design systems at that point, Microsoft Fluent, IBM Carbon and Google Material, and created our own from scratch. It started with 25 basic components and then grew as per the products' needs.

The role and journey

I took ownership of the design system from get go, I had to evangelize hard the power of a design system which grows according to the demands of the products. I had to listen closely to the customers' requests, pre-empt them and cross-reference them wherever needed. Moreover, we needed to deliver stable releases every few months in tune with the dev and release schedules of the products. It started with only two adopters, a lot of bugs and design conformance issues. But we thrived under the pressure and today it's a major success story, helping products shed up to 30% of their design and dev time per sprint.

Innovations and achievements

• Semantic design token systems for theming color, corners, typography, animation and spacing.

• Design conformance protocol and conformance checkpoints throughout the dev-test-release cycles.

• Methodical check-ins with customers to understand their usage needs.

• Contribution model and pattern library for cross-product redundancy reduction.

• WCAG 2.1 AA accessibility testing for each component and accessibility recommendation documentation.

• Presented a talk in UX India 2020 on "Design Systems, take or make?"

• Codename: Stockwatch.

• Time: 2 days in Jul 2019.

• Organization: Independent Consultant.

• Customer: Non-disclosable. One of India's leading banks.

• Platform: Mobile app.

• Personas: Stock market enthusiasts and casual investors.

• Team: 3 stakeholders, 4 sample users - in person in Kolkata.

• Role: Design thinking session conductor, UI designer.

The challenge

A reputed bank wanted to provide a comprehensive mobile experience to entry level investors and enthusiasts to monitor the stock market and their own portfolios day to day via their mobile banking app. They were looking for some ideas and a mockup of how those may be implemented.

The solution

A 2 day design thinking workshop. I prepared two personas, one for the enthusiast and one for the casual investor. Then we recruited 4 participants 2 each matching the 2 personas. The stakeholders were 1 representative from the bank and 2 from the IT vendor team who hired me.

The process

Day 1 - empathize, define, ideate.

We started with our sample users opening the mobile apps of competing banks and trying out their stock monitoring interfaces, the casual investors had an active portfolio in some of those apps while the enthusiasts didn't have a portfolio registered. For an hour or so they kept providing inputs which we kept putting in an empathy map.

Empathy map - contents blurred to comply with non-disclosure agreement.

Post the map we had a discussion on the content of the maps and defined the problem as:

• Maximizing the availability of stocks of interest to the users in their preferred arrangements.

• Bringing the data that they want to the forefront when they want it and keep the rest available but hidden otherwise.

With these problems in mind, we further noted down the learnings from the session.

Learnings

• Both personas like to rearrange the stock manually but also want high alert items to jump to the top.

• Casual investors like the breakup of their unit count, the unit price and the total value present at one glance.

• Casual investors wanted the option to go to buy or sell interfaces right from the stock details.

• A simple 10 day EMA graph of the stock was universally understood and appreciated.

• Both personas prefer a high data density than a clean, minimalist display.

• Dark mode screens felt more exciting than light mode screens!

• The ability to set custom alerts in multiple ways is very useful. As is the alerted stock to be highlighted.

• Often they would rearrange the list according to a day's focus, but they want to snap back to their standard daily arrangement.

• They hated the apps which would make them login just to view their portfolio or watchlist. They acknowledged it's important to authenticate before buying or selling but not to view stock values.

From there we had an ideating session where we generated a lot of ideas and notes, then the 4 sample users were dismissed for the day.

Next, we arranged the ideas into an effort/impact quadrant and then organised them by priority.

Ideas organized by priority - some contents blurred to comply with non-disclosure agreement.

Day 2 - prototype, test, iterate.

We opened the second day with paper prototypes and information architecture sketching sessions with instant feedback from the sample users, and iterated till we had some screens which generally agreed with the users needs.

 Paper prototypes and IA sketches - some contents blurred to comply with non-disclosure agreement.

Once we had the paper sketches firmed up, we went into a live medium fidelity wireframing session to beat out some quick details and layout wireframes with some placeholder and some sample numbers. We kept updating the wireframes with live feedback from the stakeholders and users.

Layout wireframes - altered to remove any non-disclosable information.

That concluded the 2 day design thinking workshop, I took 2 more days and some remote feedback iterations to design the final clickable prototypes and delivered them. Colors were chosen to match the bank's branding colors and to maintain text accessible contrast wherever required.

• Codename: CESCapp

• Time: Apr to Dec 2017.

• Organization: Independent Consultant.

• Customer: CESC, the leading power supply company in eastern India.

• Platform: Mobile app.

• Personas: Homeowners and tenants.

• Team: 7 stakeholders, 5 developers - in person in Kolkata.

• Role: User researcher, UX analyst.

The challenge

CESC is a century old company providing electricity to millions of households - then undergoing a major digital transformation. They asked us to build a new mobile app because their existing basic app had very few downloads and usage. They had a vision of a new app which would primarily allow consumers to log in to their singular account to make service requests and also pay bills online.

Preliminary research

Thankfully, getting access to users of CESC was not difficult, as almost every household in eastern India is supplied by them. I created a questionnaire based on bill payment and the types of service requests CESC was able to field, so that we could prioritize those services in the app and also some basic questions on the awareness of the apps.

The results were both striking and confusing. Most connection owners were seniors in the family, they were not bothered about the electricity connection because they were not paying the bills and they didn't call CESC when they had a power cut. Quite a few of the connection owners were deceased! Also each household had multiple connections in the name of different people and most also were either absent or unconcerned.

This was a major surprise to the stakeholders, they were vaguely aware of this scenario but never figured it'd be a hindrance to their mobile app adoption. I changed my line of questioning to learning more about who is paying the bills and how, and who makes service requests.

Further research

Armed with the new questionnaire, we went door to door and interviewed more than 20 households, and got actionable learnings:

• Most houses had multiple connections not just for multiple apartments but also individual families had multiple connections to avoid higher-slab bills.

• In each family, the bill paying and service requests were usually managed by someone younger in the family, who were often aware of online bill payment at the CESC website but not the app.

• Most of these users managed multiple connections. Often they resided in other cities or abroad and paid bills for their parents.

• CESC identified people with a 15 digit customer id, which no one remembers and has to fetch their electricity bill to figure out. Few people who did download the app deleted it because it asked for that 15 digit number every time they opened the app.

• Finally, apart from bill payment, users were interested in tracking their consumption and seeing how they fared against the last year.

• They were also eager to have easy way to report a power cut and being updated on the ETA of resumption. The current way was to call up CESC and give them the 15 digit number.

With these learnings. CESC updated their database structure to account for these users (who are often not the same as the connection owners) and I reimagined the app to handle multiple accounts with phone/email login, quick bill payment, consumption history and reporting of power outage as its key features.

• Codename: Acclaim

• Time: 2011-2014.

• Organization: Acclaris. Currently acquired by Willis Towers Watson.

• Customer: Bank of America, Fidelity, Aetna - etc financial giants.

• Platform: Mobile friendly desktop web app.

• Personas: Employers providing health insurance, employees claiming health insurance.

• Team: 3 designers, 12 developers, 4 testers.

The challenge

A peculiar case of a captive but reluctant audience, revamping a vast and archaic US healthcare reimbursement and administration platform with 200+ contextual scenarios and use cases in a mobile-first, responsive, and overall efficient experience while maintaining strict HIPAA, ADA and multiple financial security compliances.

Most American Employees dreaded the repetitive experience of logging and claiming health expenses but they had to do it.

Innovation

This was a case of simplicity first, a number of radical design decisions that uncluttered the whole dashboard yet kept the user's customized favourite actions on single click. A number of these innovations (made in 2013) have slowly permeated in other Banking UI dashboards in recent years.

Roles

• UX research and analysis, coordinating with multiple stakeholders globally.

• Leading a team of 3 UX designers and reporting to the CTO.

• Creating a Design Ethos, guidelines and specifications.

• Information Architecture remodeling.

• Codename: JTV

• Time: 2012-13.

• Organization: JunctionTV / FoundationTV, a startup currently acquired by Cinedigm.

• Customers: Hallmark SpiritClips, TVC Mas Latino, etc. Content providers.

• Platforms: Web, mobile and smart TV.

• Personas: Content providers, content managers, streaming consumers.

• Team: 1 designer, 2 developers, 1 stakeholder spread accross

Challenges

• Designing from scratch a whole ecosystem for OTT Internet Television and VOD services, from client purchase portals and players in computers, tablets, phones and Smart TVs, to distribution administration and monitoring for channels and producers.

• The multiple Smart TV architectures were nascent at the time, yet designs had to be universal, keeping the common denominator of all systems.

• There were a lot of complex technologies like geolocation, custom il8n and streaming video management to be implemented in the UI.

Innovation

• The UI designs and the systems were made modular and customizable, components could be assembled for a custom IPTV solution for each client.

• A big amount of data crunching was offloaded to the frontend client for the admin portal, leaving the server free for streaming intensive tasks.

Roles

• Conducting User Research all over the world.

• UX, UI, Information Architecture and Interaction design.

• Leading multiple UI development and integration teams for separate platforms and devices, keeping UX specifications same throughout.