Hey There! Thanks for stopping by. I'm Aditya. User Experience Architect, currently working at ICF International.
My work focuses on formulating business strategies that fuse user needs with business goals and designing cohesive and consistent omni-channel, cross-platform experiences for products Here's more about me.
Large Supermarkets are designed strategically (market-basket) so that customers end up buying maximum products and avail the best deals. However, this design doesn't cater the busy shoppers who are shopping under time constraints. So we thought what if we design a solution that's a win-win for both the busy customer and the shopper and one that leverages technology to attract more customers.
Supermarkets attract a mixed audience, people with different ages, profession and habits. But on observing customers of 3 different supermarkets closely, we found that they could be categorized into 3 broad personas:
It was now time to brainstorm and plan the road ahead. We sent out a survey to friends and family with a set of questions regarding their shopping habits. The results we got were quite surprising, as almost 33% of the interviewees described themselves as shoppers who just wanted to get the items on their list in the minimum possible time, weren't too interested in deals and wished the checkout queue never existed! Based on the traits, we decided to call our persona - need-based customers.
Good products are a conglomeration of good design decisions, that are made by empathizing with users, setting achievable goals and collaborating with passionate teams. One can never perfect or master design, but however, can leverage one's experience and ideas to make something next-to-perfect (atleast for the target users). It's a process, one never complete or exhaustive and the quintessential designer always instantly adapts to the changing trends of the industry and its consumers. That being said, a designer shouldn't be afraid to think out-of-the-box. Sometimes crazy thoughts can lead to extraordinary ideas!
The design team at Ipswitch (including me) played a pivotal role in designing and driving the efforts for Ipswitch’s new Reporting Tool -
ANALYTICS. While this was going to be provided as an add-on to MOVEIT (Ipswitch’s File Transfer Software), we anticipated
high customer adoption by our clients as we had been receiving customer requests for such a platform since long.
We designed the platform after some rigorous research (competitive analysis, card sorting, affinity diagramming), multiple brainstorming meetings with devs, PMs and analysts, numerous iterations, many MVPs and user interviews while following a strictly Agile approach.
However, after moving to test the application with the first round of usability tests we noticed a major issue. Users were overwhelmed on seeing the information-explosion on the first screen and looked confused. We had 8/10 users have this problem and was a top-priority item.
With help from other members of the UX Team, I worked on redesigning the flow.
It was necessary to make the user’s mental model aligned with the application pathway.
This is what we wanted to tell them -
“You first start with Selecting a 'New Report', but you create or edit a report using a 'Report Template', so you ‘Manage Report Templates’ and once modified you can ‘Schedule’ them to generate real-time reports for you.”
We gathered feedback on what out users felt when they used our system and how would they approach the problem. We remodeled the web flows and modified the pathways. With the new approved and gone live, we tested the product again with a new set of users and saw that only 1/10 users had some problem identifying the technical jargons - Reports and Report Templates. This was however, a huge improvement for the product and a good win for the team.
With a great product suite comes great responsibility! Ipswitch had an amazing product suite but there were some design inconsistencies in terms
of branding language, product appeal, terminologies and interaction patterns. I had the wonderful opportunity to explore the entire product suite
and look for such discrepencies. Here are some of them:
Login Page Inconsistency
Login pages used different terminologies for different products. This was also applicable to the error messages / notifications after attempting to log in.
Title Case - Sentence case Inconsistency
It was necessary to establish guidelines and design scenarios for content writers and designers to make it easier to choose between title case and sentence case. The snapshot below provides some food for thought.
This project was part of the 'Interactive Design Methods' course curriculum. The problem statement seems pretty simple at first, but has an added requirement that makes it super interesting. Such problems, push designers out of their comfort zone and make them ready to tackle challenging real-life scenarios.
"Design an experience to access recipes online. The application must be designed for blind and regular users"
This project provided me with an opportunity, a domain I always wished to explore - Designing for visually impaired users. Here's some background research on how visually impaired users use smartphones. So there are a number of ways in which visually impaired users use smartphones
1. Voice Recognition
Voice recognition software is the most sought technique while designing applications for visually impaired users. Such applications usually come with their own built-in voice recognition tool or leverage the native operating system's voice recognition APIs. Apple's 'Voice Over' is the best example of how software must be designed to address the needs of such users.'Voice over' uses a different set of interaction controls as compared to regular smartphone interactions (For eg: While typing, a single tap reads the word aloud for the user and a second tap confirms a text entry. This minimizes the chances of typing errors) This video by Anna Garzya shows how visually impaired users interact with smartphones using this technique.
2. Braille phones
A number of braille phones are already out in the market along with a few other concept phones being proposed each year that aim to make the experience better for such users. UK-based OwnFone, a company that lets users design their own mobile devices, introduced what it's calling the world's first Braille phone. The phone is the size of a credit card and comes in a number of shapes and colors. Here's another concept smart phone proposed by Sumit Dagar that has a bunch of amazing features. However, these phones and typically the applications designed for these phones have some limitations:
Due to the limitations of designing an app for a braille phone, I decided to adopt idea 1 (i.e Leverage the power of voice recognition to solve the problem). The idea was to keep the application as simple as possible while providing all the features a recipe app is expected to have. It was also important to provide a convenient way to enable/disable voice instructions at any time.
An taxonomy is generally created for a complex, branched system and is not absolutely necessary for a 2-page application with less than 5 modules. But it's always a good practice to have one as it helps stucture, organize and link content
and explains the realtionship between different modules.
Here we see an IA map for 1-The holistic application (Home) and 2-The Recipe Structure.
Wireframes are the skeleton for a prototype and almost paint a clear picture of what a designer intends to achieve through his/her design.
While designing the wireframes, my goal was to keep the app as simple as possible by minimizing the total number of interactions required to achieve the end goal, leveraging voice commands to automate the entire process and handling edge cases and possible errors.
The prototype has two screens, namely, the home screen which allows for searching and browsing available recipes and the recipe screen, which presents or reads the recipe to the user.
View the interactive prototype here
The prototype with voice
Handling edge cases
When designing for a target set of users, design keeping the target users' requirements in mind, then extend the application to accomodate other users.
Background research is really important when it comes to designing applications for challenging use case scenarios. For this project, getting to know how visually impaired users think and interact with touch interfaces was really important. Articles like these helped me explore different possibilities.