“…And if you don’t know where you’re going,
Any road will take you there…”

- Any Road, George Harrisson

Although Georgie’s words make sense poetically, not knowing where you’re going might lead to a lot of trouble in the real world. And when it’s a daily commute, knowing the details of your ride is crucial to your routine. That’s where Track-on-Travels (or ToT, as we like to call it) comes in.

AFour has a fleet of buses that run through multiple routes in Pune to pick-up and drop employees. ToT assists these employees to manage their daily rides to and from the office premises. It also allows the administration to monitor and manage the running buses.

Side Note: ToT was the brain-child of Darshan Gaikwad and team, while they were a part of Hack-D-Day, a 24-hour hackathon event at AFour. Because of the impressive work that they did, the stakeholders decided to take it up as an internal project and see it through completion. I spearheaded the design of the app when it started out as an internal project.

Project Highlights

Timeline: Nov-Dec ‘18

My Role: UX and UI Design

Team: 1 UX/UI Designer (me), 2 iOS Developers, 1 Full-Stack Developer, 2 Software Test Engineers, and Product Manager

Current Process and Pain Points

To understand how users currently manage their commute, I took up guerrilla interviews. It proved to be a time-effective, low-cost way to way understand and learn about travelers’ and admins’ current experience.

The Goal

The goal of the interview was simple. Through the travelers, I wanted to know how they currently keep track of the running bus. And as for the administration, the focus was on the hiccups in the current process of onboarding the users and monitoring the buses daily.

Participation Criteria

The only participation criteria for the interviews was that the individual should be a regular traveler on the office bus.

In addition to the travelers, I also had a quick word with the bus drivers to get an idea of their daily routine while on the bus.

Key Findings

What I learned about the current process and pain points fell under the following three heads.

1. The WhatsApp Group

No running buses currently have location monitors on them. However, the current travelers have implemented a workaround for their ease. They have a WhatsApp group in place wherein the first individual to onboard the bus shares his/her live location with the group.

This practice, although innovative, is prone to human error. There had been days when no employee boarded the bus on the first stop and the location of the bus was unknown to those boarding next.

“ I think the WhatsApp group helps. People just update the status of bus on the group and then I can plan my mornings accordingly.”

2. Manual Onboarding

First-time travelers need to contact admins physically to check availability and get themselves added to any route. The process was often exhausting and susceptible to delays.

“ I had to spend an afternoon getting to know the routes and seeing if there’s a stop closest to my home.”

3. Unwanted Delays

Another issue which the travelers mentioned was the frequent delays while traveling. This often led to collective trouble.

Most of them also agreed that they’ve been the cause of these delays, at least once. And since no measures were in place to hold them accountable, a general sense of complacency towards punctuality prevailed.

“ If everyone boards the bus on time, I think we’ll be able to save an hour or more of our time every week.”

What lies at the end of the road? — Goals and Scope

We now knew the primary issues that were to be addressed through ToT. These issues were the single source of truth while locking down the goals and scope for the app.

Goals

As a response to the identified issues, the following goals were set to evaluate our success once the app is developed.

1. A seamless experience

A fast and smooth experience of onboarding and tracking the location of running buses for employees.

2. Reduced offline tasks

Reduced workload for the administration related to monitoring and managing the fleet of buses.

3. Traffic and location data

Insights from the daily traffic data and employees’ timings would improve accountability and help in planning better routes.

Scope

Since a couple of resources who weren’t a part of the team initially (including me) came on board, making sure that all of them are clear on the scope of the app was crucial.

Enter, User Stories.

The purpose of using User Stories at the inception of the project was bifold. First, it allowed us to set clear and feasible goals for the MVP and second, everyone had a clear picture of what fell in their task bucket.

Here’s what our high-level, informal user stories looked like.

Once we had the user stories in place, it became really easy to estimate and prioritize them for the MVP. For example, we deprioritized the in-app chatroom to get done with the admin console in the initial sprints.

Wireflows as a UX deliverable

Since the app was confined to a couple of pages that changed dynamically based on user interaction, wireflows were the best choice to give the team an idea of the information flow in the context of common user tasks.

Before starting with wireflows, I sketched a flowchart of the primary actions in the app for the stakeholders to sign-off. This made sure that I’m on the right track with the design and no information is being lapsed.

And then came the wireflows…

Beep beep! Your app is here.

And just like that, the design for the Track-on-Travels app was complete. The admin panel, however, contained minimal functionalities for the MVP, i.e., reviewing the onboarding requests and gathering metrics like travel frequency and delays.

Here are a couple of screens showing the core functionalities in the app.

1. Onboarding

New users can place a request to be added to a route through the app. Once approved, they’d be notified daily about their rides.

2. Real-Time Tracking

Travelers can view real-time location updates of the bus while it’s traveling. They also get notified when the bus initiates its journey to or from the office premises.

3. Geofencing Notifications

The app notifies the travelers once the bus reaches within a 2 km radius of the pickup/drop point.

4. Chatroom

Since the users were used to conversations while in or out of the bus, an integrated chatroom was a positive nudge to the application. It allowed them to converse without switching frequently between apps.

5. And then some illustrations…

Adding these fun illustrations to the empty or error states of the app made the experience a bit more delightful.

Outcomes

Currently, an alpha version of the app has been developed and is being tested on one of the buses. The development team is consistently working on identifying and resolving all functional or visual bugs.

What’s next?

Since we wanted to make the admin console just functional enough for the time being, we’re looking into adding more analytical capabilities to it. As more features come into the picture, a dedicated design sprint would be undertaken as we go ahead. In the meantime, the location and delays data is being recorded to analyze and plan better routes in the future.

The job, for now, stands done.

Pradyumn out. *drops mic*

Turns out, it isn’t that terrible after all. The good thing was that since the ‘deliverable’ was just a screen here every day, I got to focus on every little detail on that one screen. Leveraging Occam’s Razor as a guiding principle, I attempted to use only elements that add value to the user experience.

Instead of jumping right into designing screens every day, I formulated two goals for myself.

• Get my hands dirty with as many tools possible (Sketch, Figma, Adobe XD, InVision Studio and Illustrator) for these designs.
• Elevate my micro-interactions and UI animation skills

Here’s what I achieved.

001: Sign In/Sign Up Page

Prompt: Design a sign-up page, modal, form, app screen, etc. (It’s up to you!)
Tool: InVision Studio

002: Card Checkout

Prompt: Design a credit card checkout form or page. Don’t forget the important elements such as the numbers, dates, security numbers, etc.
Tool: Sketch

003: Landing Page

Prompt: What’s the main focus? Is it for a book, an album, a mobile app, a product? Consider important landing page elements (call-to-actions, clarity, etc.)
Tool: Adobe XD

004: Calculator

Prompt: Design a calculator. Standard, scientific, or specialty calculator for something such as a mortgage? Is it for a phone, a tablet, a web app?
Tool: Sketch and InVision Studio

005: App Icon

Prompt: Design an app icon. What best represents the brand or product? Or is it incredibly unique? Does it look great at a distance and does it stand out when put on your home screen alongside other apps?
Tool: Figma

006: User Profile

Prompt: Design a user profile and be mindful of the most important data, names, imagery, placement, etc. Is it for a serious profile? A social profile?
Tool: Figma

007: App Settings

Prompt: Design settings for something. Is it for security or privacy settings? Game settings? What is it and what’s important?
Tool: InVision Studio

008: 404 Error Page

Prompt: Design a 404 page. Does it suit the brand’s style? Is it user-friendly?
Tool: Adobe Illustrator

Side Note: I realized later that the message does not resonate with the ‘404’ Status Code. It’s more likely a server error (5XX type). But since I’d invested so much love and tears in this, I decided to let it stay.

009: Music Player

Prompt: Design a music player. Consider the controls, placements, imagery such as the artist or album cover, etc.
Tool: Adobe XD

010: Social Share

Prompt: Design a social share button/icon and be mindful of the size, imagery, placement, and purpose for sharing.
Tool: Adobe XD

011: Success/Error Flash Message

Prompt: Design a Flash Message with both the outcome for an error and success. Is it for a sign up form? A download/upload message?
Tool: InVision Studio

012: E-Commerce Landing Page

Prompt: Design an e-commerce shop. Is it simple for a local business or a large online retailer? Is it for clothing, shoes, handmade soap, or something else? Consider the brand, the products offered, product views, product options, desired actions (conversions, product views, etc.) and the users!
Tool: Figma

013: Direct Messaging

Prompt: Design a Direct Messaging app, profile, or chatbox. Consider the parties involved in the messages, images, placement, and context of the messages.
Tool: Sketch

If you enjoyed this piece, hit that little 👏 below and share the story with your mates. Peace!

Follow my work on Behance and Dribbble. No pressure, though.

In July 2019, I was asked to be a part of a usability study for a telecom company’s mobile app. The app at the time had more than 2.2 million downloads on Play Store, which meant that any recommendation we make would affect a mass-market audience.

The next two months had one of the steepest learning curves of my entire UX career. Learnings that I thought might benefit other designers and researchers starting with a usability study of their own.

I knew that I’ll have to learn from the real world and learn fast. Then put all of that back into my work. This post serves more like an open diary for me and everyone who might feel blocked at any point in the research.

The success of any usability study depends on how adequately the following tasks have been performed

• Defining the purpose of the study
• Getting the right participants
• Asking the right questions
• Unearthing and presenting the insights

I present my learnings on how to perform these steps more effectively. Having said that, I don’t mean to dole out lessons on what’s perfect for conducting a usability study. Boy, I’m not even sure if this might work for you specifically. What I’m sure about is the problems I faced, might be encountered by you as well.

In that case, here’s the help you cannot refuse.

Defining the purpose of the study

“Well that’s not what we were looking for!”, exclaimed a frustrated client after an hour-long demo of a deck with hundred-something slides. To avoid being in such a situation, you need to know (and get a sign-off from the stakeholders, saying they know that you know) the purpose of the study.

“He who has a why to live (read, research) can bear almost any how.” — Friedrich Nietzsche

1. Have a Research Protocol in place

A research protocol helps avoid misunderstandings and keeps everyone, including the stakeholders on the same page. Do not forget to get it reviewed after every update. Once you have the protocol in place, you can plan and structure your thinking around the research activities. If you need to know what all needs to go in the protocol, here’s an article talking about it.

Research Plans: Organize, Document, Inform

Every research protocol is unique and is influenced by the kind of problems you’re trying to solve. The Nielsen Norman Group has a fantastic article to help you decide on the exact research methods you should employ in your study.

2. Document and (over)share everything with the stakeholders

Keeping the stakeholders involved as you go ahead in your research project helps build trust and confidence. This would help you at the time when you present your findings. They will then be aware of the fact that the insights you present are not pulled out of thin air, but are backed by relevant data.

Getting the right participants

Screening in a set of participants representing the target users can be a tough business. This also has a direct impact on the type and number of issues you identify in the study. Here’s how you can do it right.

3. Know your audience (duh)

It helps if you have personas of representative users in place before you go ahead and recruit actual participants, but if you don’t, it’s not a dead-end.

Try classifying your audience based on their behavioral attributes. Remember, no classification is wrong if it encompasses your user spectrum. Look for similarities in attitudes and behaviors over demographic factors like age, gender, and economic status. You’d be surprised by how similarly people behave even when they’re virtually at two different ends of civilization.

Here’s an article that would help you wrap your head around this concept.

'Our Users Are Everyone': Designing Mass-Market Products for Large User Audiences

4. Grab their attention!

Well, you might not need to go all-in on this one if you hail from a place where people love showering feedback. But where I come from, people generally don’t pay heed to researchers sitting at a coffee shop, smiling sheepishly with the promises of a cappuccino or a box of donuts.

To get them on board and allow for easy access to the participant screener, I created this.

The posters gathered a lot of attention and so did we. We received 56 out of 108 responses to the screener through them.

Side note: We chose to lock down the screener once we reached 108 responses ’cause we got hold of the decided number of participants (5 users and 1 substitute, in case there’s a no-show).

I also had to take desperate measures and reach out for the strongest weapon in my arsenal — memes.

Asking the right questions

Now that you know the tricks to get participants on board, let’s get to the part where you conduct actual assessments with them. The way you gather information might be observational (“what users do”) or conversational (“what users say”). Even while observing, you might want them to “think aloud”. It’s important to exhibit a clear and unbiased perspective while conversing to gather true results.

5. The three golden words: “Tell me more”

“Don’t ask leading questions!” is the advice that most researchers swear by. But with all that pressure to keep the conversation going and avoiding awkward silences, it’s easier said than done.

One piece of advice which I gathered through a talk by Nadyne Richmond was asking the users to talk more about the subject. That’s one simple trick (which works!) to gain attitudinal information about them. The perfect thing about this is that it can be used anytime through the conversation. And you do not lead the users in any way. Win-win.

6. Use vernacular language whenever possible

Some participants in our study were from a rural background and spoke only the local language. It was important to convey the essence of tasks without mincing the words. Using vernacular language did the trick for us.

Remember to converse, not interrogate. And the essential step for that is talking in the language participants think in. Often a lot of information is lost or misinterpreted in translation. To avoid this, have someone on the team who’s proficient in the local language. If the participant agrees to it, record the session for transcription later.

Unearthing the insights

Yay! Now that you’re done with the difficult part, the job is almost done. All you need to do now is report the identified issues to the stakeholders and feel proud when they applaud you for your tremendous efforts. Right? Wrong.

Until you’re able to convey clear actionable findings, which also elucidate the value they add to the user experience, your job’s not done.

7. Prioritize all findings

A successful usability study can give you as many as 60 usability issues in an app or website. To avoid getting overwhelmed by them, you need to get them prioritized. Now, I followed the Kano model for that but you can take any simple prioritization framework like Value vs. Effort or Affinity Grouping.

A few more suggestions

Here are a few more suggestions which helped me while looking to learn more on the subject of usability testing. Take notes, ladies and gentlemen.

8. Take help from the community

Ask for help shamelessly. In a community of individuals who’re known for their empathy, you’ll find it. The Mixed Methods slack community is a great place to see how brilliant minds in UX research do what they do.

“If I have seen further than others, it is by standing upon the shoulders of giants.” — Issac Newton

If you want to take it up a notch, you can try becoming a participant in a UX research by organizations with a dedicated research wing. I signed up for participating in user research by Google to see how they go about it and it taught me a thing or two. Looking at their research process from the inside might help you evaluate your own.

Here’s their website if you want to sign up too.

https://userresearch.google.com

Fortunately, I was screened for a remote unmoderated study and got the hang of their process for this specific study. Benchmarking my process against theirs filled in many gaps in my knowledge.

9. Don’t do it alone

Going through this article by Jared M. Spool about the KJ Technique (or as popularly called, affinity diagramming) made me realize the value of having multiple heads while working on a research project. It’s so easy to fall a victim of confirmation bias while working alone. You need someone to call out your BS at times like these. In my case, Aditi Kale was more than happy to do the job.

Plan brainstorming sessions together if you’re a team. If you’re a research team of one, get regular feedback from people who’ve done this before.

10. And don’t forget to have fun, whenever you can

Lastly, be proud that you’re creating new knowledge! You brought something into the world that didn’t exist before. That’s some good work right there. Now that you’ve come this far, you’ll only go onwards and upwards. Cheers!

“Man suffers only because he takes seriously what the gods made for fun.” — Alan Watts

Hey Reader! Glad you could make it till the end. Liked the article? Do let me know in the responses below. Any other suggestions which might be helpful? Leave them down below too. Peace!

Follow my work on Behance and Dribbble. No pressure, though. Your choice.

To err is human; to really foul things up, you need a computer.

-Paul Ehrlich

Obtaining insights about the health and performance of a system is often crucial in maintaining its reliability and security. One of the best ways to do this is to use a robust operation-monitoring system which keeps a tab on all of the running services.

AFour Solar is such a system for clients in the Solar energy domain, which gathers metrics from solar sites, visualizes data and alerts, on-site operators if things seem to go wrong.

When I was asked to look into the product interface, I immediately felt that it could use a facelift and there’s still a lot of room for improvement. This was a great opportunity to reimagine the way users interact with AFour Solar and all the while making their lives a bit easier. Also, this was the first time I was working on a project whilst navigating between the business constraints, viability, budget, and other such factors.

The excitement was high.

Project Highlights

Timeline: July-October ‘18

My Role: UX and UI Design

Team: 1 UX Researcher (Pranjal Deep), 1 UX/UI Designer (me), 2 Frontend Developers (React and Angular 6), 2 Backend Developers, and Product Manager

Why the redesign?

In my interactions with the stakeholders, I tried to gather the reason why they wanted the entire product to be redesigned. Through all my interactions, I was able to identify the following three themes in their arguments.

1. It felt difficult to use

There was feedback from the site supervisors that the on-site operators often had issues while navigating through the interface. New operators often took a couple of attempts to find the desired information.

2. A lot of features were redundant

Quite a few elements in the product seemed irrelevant. They did not add any value to the workflow of administrators or operators.

For example, the statistics slideshow on the Dashboard, which displayed stats like ‘Lifetime Electricity Generation’ and ‘ Earnings This Month’ just made you feel a little good and helped in no other way.

3. The interface felt dated

Well, to be honest, visually the interface appeared ancient. I couldn’t agree more that the only visceral feeling that the current design stirred up was nostalgia.

Getting Started

The key stages of the project were similar to any other product redesign project. We first identify our users, the problems they’re facing with the current interface and classify these problems into tangible work items. Moving ahead, we propose solutions to the identified problems and test how well they work.

They say any research is better than no research. The strict timeline of the project called for a rapid research process and for that I and @pranjaldeep did a simple thing: we talked to the users.

We knew that the product has two types of users: site administrators and on-site operators. Speaking to them helped us identify who they are and why do they use our system. Here are some highlights of these conversations:

Profiling Attributes

• The administrators are professionals around 35 to 50-year-old with a lot of industry experience under their belt. Most site operators fall in a younger age group of around 25 to 40-year-old.
• They mostly show competent to expert-level skills in the context of using an operations monitoring system. The administrators are usually the COOs or Site Managers while the operators are the guys-on-the-field.
• Operators show a goal-oriented behavior while using the system whereas administrators are browsers who look for anomalies in the functioning of the system.

Differences in the frequency of use

On-site operators use the product more frequently than admins. Admins, more interested in cumulative health and performance of inverters, use it once or twice a day. On-site operators, on the other hand, use it all through the day to keep track of incoming alerts.

Differences in primary tasks

Admins generally are more focused on the trends in production and reporting features while operators are more likely to use the notifications and ticketing features.

Heuristic Evaluation

Apart from talking to our users, we did an audit of the existing interface to identify the current concerns. Here’s what we found:

• Faulty Information Architecture: Overlapping information categories and confusing labels took a toll on usability. We redefined the architecture in an attempt to reduce the clutter and repetition of information.

• Incoherent visual language: The existing product did not seem to follow any consistent visual design patterns. The absence of consistent branding and UI palette left the users dissociated and confused.
  This was handled by keeping in mind the Material Guidelines and introducing a consistent palette and iconography throughout the product.

• Navigational Overload: The primary side navigation had multiple child sections that were displayed in the navigation bar itself. We discovered alternatives to this issue, which are discussed ahead.

Get, Set, Renovate!

Now that we’d diagnosed the problem pretty well, it was time for us to operate. To start with we went to the birthplace of all great ideas aka the whiteboard!

Initial Sketches

It was evident that we’ll have to restructure the content in such a way that it seems, intuitive while making sure that it does not seem so disruptive to the users that they instantly hate it. Through the heuristic evaluation, we had found two sections that needed a major revamp.

1. Dashboard, Sites, and Trends Pages

What we discovered was intriguing. Dashboard, Sites and Trends, all of these pages displayed slightly different information about the same set of items. ‘Dashboard’ displayed the cumulative generation and health metrics at all sites while ‘Sites’ showed the same info, along with Inverters Summary at specific sites. ‘Trends’ allowed you to look at the variation of these metrics with time.

Aha! If we’re talking about the same metrics at all these places, why not have them at the same place? That’s exactly what we planned to do.

2. The Navigation

Well, we knew from the start that the overloaded side-navigation is an issue. It was only a matter of time that it got addressed. Combining the Dashboard, Sites and Trends pages had solved half the problem for us. What we needed now, was secondary navigation to avoid the ‘dreaded’ dropdown in the side navigation. ENTER, Tabs.

We introduced a tabbed layout on Reports and Tickets pages as a replacement to the dropdowns in the side navigation.

Moving ahead to the wireframes now…

And finally — the result of love, warmth, and tears ✌🏼

Here’s a glimpse of the final responsive product for web and mobile.

Outcomes

The redesign brought in numerous positive feedbacks from the current client. We also pitched the product successfully to two new clients, one based in South Africa and the other in Ahmedabad, India.

Currently, the product is being tested at 12 production sites by the prospective clients and continuous metrics are being gathered to make the system more robust. A support team from AFourTech is in regular contact with the clients which brings in any issue or feedback raised by them.

The fact that we were able to address the existing issues without creating (a lot of) new ones is what brings true joy to me. Going ahead with a few more iterations, I believe we’ll be able to optimize the usability of the product.

The job, for now, stands done.

Pradyumn out. *drops mic*