Category Archives: Field Notes

Another Railway UX Article

 

 

 

 

 

Bad UX is all around us.

I guess I am not the only one who notices UX fails in everyday experiences. This is a column by  from Febrary, 2018

I travel by the Mumbai local train every day, and often take the metro. Millions of people in Mumbai do this too. The commute is such a mundane part of our lives that we do not stop to think how an outsider would feel about the chaos that we have  internalised over years of (bad) experience. From what I can guess, they would be confused at best and frustrated at worst.

If I were to describe my morning commute, it would sound like this:

I take the 8.08 Churchgate-bound slow train from platform number 2 in Borivali. Alight at Mahalaxmi and take bus number 154 to my office.

Now this is a normal part of my routine. If you are new to the city you’d know just two or three of the parameters required to reach your destination. The gaps in information should ideally be filled by the system through UX design. A good user experience design helps a user achieve the desired goal with minimal effort. In case of a commute, a user’s goal is to go from point A to point B. It is criminal to assume that the user would know anything more than what point A and B are.

Unfortunately, the local trains in Mumbai, and even the metro, fail spectacularly in addressing this.

I recently traveled to Europe. I was worried that it would be an arduous task to ask for directions in a language I wasn’t very comfortable in. But I was blown away by how convenient the Paris Metro was for complete novices, even though it was built over 100 years ago. It has its problems (it is slow, old, unreliable and smells like piss) but ease-of-use is not one of them.

Coming back to Mumbai…

Umm.. where’s the platform?

So, you have to undertake the train part of my daily journey at some other time of the day. The difference is that you just know you have to board at Borivali and alight at Mahalaxmi. Nothing else.

All right? let’s get going.

You’ve reached Borivali station after fighting your way through a traffic jam of auto rickshaws, BEST buses and for some reason, roadside food stalls. You see Borivali written in huge letters outside assuring you that you are at the right place.

Welcome to Borivali!
Welcome to Borivali!

You enter the station, buy your ticket to Mahalaxmi. All good. Let’s get to the train. This is when you are hit with your first question: “Where the hell is my train?”

Once you enter the station you are greeted by an indicator on a tiny monitor. Mahalaxmi is nowhere to be found on it. If you are lucky, it might even be working.

Electronic indicator at Borivali Station. Figure it out yourself.
Electronic indicator at Borivali Station. Figure it out yourself.

All right, so there are trains to Churchgate, Virar and so on. Some have “S” or “F” written next to them. You think: “What the hell is that?”

Herein is problem number one. There is no way a user can guess where her or his train will arrive without knowing all about directions, slow and fast trains, and where the platforms are.

This is how Paris Metro solves a part of this problem. All stations on a route are listed before one enters the platform.

By Clicsouris (Own work) CC BY-SA 3.0 , via Wikimedia Commons
By Clicsouris (Own work) CC BY-SA 3.0 , via Wikimedia Commons

They don’t have the slow/fast complexity in Paris so we’ll have to figure it out ourselves. Also they don’t have unscheduled platform changes.

Let us assume you somehow figure out which platform number to go to. You get to your platform, that is, platform number eight (for which you had to walk the length of two platforms). You find a relatively empty spot on the platform. The train arrives, but you’re told you can’t enter this coach which makes you think: “Why the hell can’t I get in this coach?”

There is no sign to show that the empty spot you found on the platform is where the luggage compartment of the train stops. You’re made rudely aware of this fact by the rushing dabbawalas exiting the compartment with their large trays. But wait. That’s not it. It could have been any of the other compartments you are not allowed to enter but don’t know the stopping positions of:

  • Handicap
  • First class
  • Ladies
  • Ladies first class

This is problem number two. A user has no way to guess where her or his compartment will be. The only indications are the coloured bands on pillars. Red and yellow for first class, green and yellow for ladies. How on earth will anyone guess what those colours mean?

Alright, there are some signs to tell you that you have to enter any of the general or second class compartments, but it wouldn’t bankrupt the railways to put out clear signs.

Anyway, now you know that you belong with the unwashed masses in second class. So you accept it, and try to find a place to sit. You settle for the “fourth seat” that you are immediately asked to vacate by an 80-year-old relic of a man. As your ego is at an all-time low from the embarrassment of being so clueless, and the subsequent shoving and pushing, the stations go by, the train gets full and suddenly you are hit with another realisation: “Where the hell am I?”

You are stuck between bodies who interfere with your line of vision that has to pass through a tiny window with grills, or the door, towards a small board with the station’s name written in three languages.

Man for scale. Too bad if your first language is not Marathi.
Man for scale. Too bad if your first language is not Marathi.

This is problem number three. A new user would never guess when their destination is about to arrive if they cannot see where they are.

Compare the size of the board in the photo above to the one below in the Paris Metro. The whole board above is as large as just one letter in the picture below.

Seats for scale. The name of the station is clearly visible from anywhere inside the train.
Seats for scale. The name of the station is clearly visible from anywhere inside the train.

To be fair, the trains and metro have really tried to solve this problem using two methods:

  1. Announcing the next station and final destination in three languages (English, Hindi and Marathi).
  2. LED display boards indicating the next station and the final destination like the following (though dysfunctional) board in a train.

Unfortunately, not all trains have working announcement systems or display boards as the one in the photograph above. I guess it is not worth stopping operations of an entire train just because the display is not working.

After all this, if you still managed to disembark at Mahalaxmi and not Churchgate, congratulate yourself. Count your stars that you don’t have to figure out where is East or West.

You survived like the millions of others who survive Mumbai everyday.

Phew.

One can argue that designing the local train system for a better user experience, especially for newcomers, is not the most urgent matter. However, a team of artists recently decided to decorate Borivali station with some graffiti. It looks like this now:

Photo credit: Making A Difference Foundation/Facebook.
Photo credit: Making A Difference Foundation/Facebook.

Good job, but too bad that can’t change the horrible user experience design. I would have been happier if they had put some signs on how to reach platforms number seven and eight.

For a newbie, all this can be solved by just “talking to people” but if this was an app meant for regular use, which required asking regular users to understand it, it would never have regular users in the first place.


Disclaimers and notes

  • These were just some general observations. There are specific problems like there are no directions whatsoever how to get to platform eight and nine in Andheri, or the utter chaos in junctions like Dadar. You just have to know or stumble around to find your way.
  • There are many reasons that mess up the user experience design, like sweaty armpits of fellow commuters, shitty ads and inexplicable delays. I just wanted to talk about the ease-of-use part in this post.
  • I know I’m comparing local trains to the metro but the local trains are the biggest mode of transport in Mumbai. They desperately need a redesign. The Mumbai metro has its own design problems but they are not as pronounced yet because there’s just one active line right now.

How can Agile and UX play well together?

kinder-playmates-7

Over the past few years, I’ve been a lead UX designer in an Agile environment. To clarify what I mean by this, I’ll define Agile as a specific development framework designed for rapid iterations of functional software. This is accomplished by the use of two-weeks sprints where developers will tackle a particular user story with a chunk of software. When I worked with Salesforce, we were doing a custom implementation for a client who had a lot of specific requirements that were not immediately met by the out-of-the-box solution. The Agile approach was to break each specific element of the software into a user story with its own requirements and functionality. Each user story was assigned a velocity to determine how quickly it was to be accomplished, with all of the various user stories in the sprint forming part of a larger picture called an Epic. The software used for keeping track of this was Rally, one of the better Agile tools out there.

At Caterpillar, we were building a portal for the various dealers to manage their machines, parts inventories, repair orders, and so forth. There was also a need for the dealers to keep track of their customers. All this was built on the IBM Websphere Portal, a java-based platform of immeasurable complexity that has been the backbone of many American enterprises for years. The product owner and scrum master were based in the US, while the development teams were all located overseas. The tool used for keeping track of all this was Pivotal Tracker, another good Agile organizer.

So where did UX fall in with this? In neither case was it baked into the process, mostly because there was inadequate understanding of the role of UX in the process. A proper User Experience methodology relies on a lot of research up front as well as plenty of validation and testing throughout the process. The ideal is to not waste time designing and building things that don’t work for what the customer wants to do. This is vastly different than building functional software, which only needs to be able to perform the tasks it was designed for to be judged a success. I think of it like this: Agile is all about building working software quickly, and UX is about quickly determining what software will work.

In the case of Caterpillar, there was really no way to do any pure UX other than to observe the dealers wherever possible and ask them questions about the sort of things they did day to day. In this, I was able to help prioritize what the portal needed to do in context (for example, it was important that the rental portal have a mobile component that would allow the dealer to visibly inspect equipment and take pictures as necessary.) Largely, the job became more about applying UI best practices to a complicated interface.

In the case of Salesforce, a lot of the UX research was done up front and throughout the sprints. Development and UX were done in tandem with lots of field studies and specific task and journey mapping that allowed the users to access what they needed in the context and time frame most useful to them.

The biggest takeaway from my experience is that UX needs to be at least one sprint ahead at all times, and more if it’s possible. It also helps if UX is brought in from the onset of the project with a clearly established role and timelines.

During a recent Nielsen Norman Group training, I came across a great case study that I present here as an example of how UX and Agile can be integrated effectively throughout the project:

Doing UX in an Agile World: Case Study Findings

by HOA LORANGER on May 26, 2014

Agile development processes are popular among programmers, and for several years we have studied how to best integrate Agile methods and user experience methods to create great products that don’t abandon usability while chasing after speedy programming. Our earlier research considered the broad perspective, so we now dive into a smaller number of projects to collect deeper insights for our new course on Lean UX and Agile.

I recently interviewed eight professionals who work in Agile environments to learn about their journey, their successes and failures. I spoke with people ranging from User Experience (UX) designers to developers and product owners. All worked in an Agile environment for at least two years.

Agile Is Here to Stay

There is no going back. Everyone that I spoke with admitted that the process is not always smooth, but today it is much better than when they first started several years ago. Even at the 2-year mark, some people confessed that it’s not all roses, but it’s much better than it was before—no one wanted to revert to a traditional development process such as the waterfall.

In general, Agile teams agree that this framework facilitates transparency. Issues are identified sooner and features are delivered faster. Gone are the days when developers and designers spent months and months cranking away, working independently, and only identified issues at the end. Agile has minimized last-minute surprises and allowed developers to predict timelines more efficiently.

“We are working smarter. No more 14 hour days for an entire month. We are a team and we are releasing more often… Since we’re working with smaller chunks that are not monolithic, it is easier to predict than something that is huge and can take 9 months. Everyone is aware of progress sooner.” Victor, Software Engineer

“Before Agile it was harder to stay on track. There is more accountability now. Things are more transparent.” Anca, Software Engineer

Practice Makes Perfect

After a few years of trial and error, Agile teams are getting the hang of it. People are better at timeboxing or setting time limits on activities. Daily standup meetings that used to go on for 30 minutes or more are now getting closer to 15 minutes. Team members are better at being concise and sticking to the agenda. There is a greater understanding and appreciation for the “rules” and how the process benefits releases.

Time estimates are more accurate. In the early days, some teams took on more than they could handle insprints (or units of time), but today this is less of an issue because they have learned what is reasonable work for a given sprint.

“The awkwardness is wearing off. People had to get used to the funny way of calling things and the new activities.” Michelle, UI Designer

Communication Is Key

For some team members, the biggest benefit to using Agile is communication. The Scrum method provides the structure for cross-functional team members to contribute ideas, share responsibilities, and refine the process together.

“The biggest advantage to Agile is retrospectives. It allows people to air dirty laundry, improve, and try different things… At first I was very focused on following the rules. After working in different Scrum teams, I’ve learned that I have to work for those teams… Now we have a shared vocabulary, a shared understanding.” Jeff, Product Manager

“The value of scrum is conversation. Don’t beat yourself up over following all the rules. We do as much as we can.” Cathy, Product Owner

Agile Challenges Within Organizations

For many people the Agile road is still bumpy. Gaining company-wide support has been an uphill battle. Teams must work hard to show nonbelievers the value of Agile and encourage them to break out of their comfort zones.

Lack of Executive Support

One of the major challenges with Agile is getting support from the top. Some of the people I spoke with expressed their frustration with the lack of engagement with management. Without executive backing, teams are forced to cut corners and work less effectively. Misunderstandings about the Agile process result in communication breakdown and incoherent planning.

“Requests from stakeholders that are outside of Agile mess with sprint planning.” Julia, UX Designer

“We’ve had to work on stuff that is not part of planning.” Cathy, Product Owner

“Our group is embracing Agile, but our organization is not there yet. We’ve had a couple of Agile coaches, but the coaches were not great at swaying senior management. They didn’t have an impact to get senior management onboard.” Mandy, Senior Programmer Analyst

Inadequate Resources

The lack of executive support usually results in diminished resources. The practitioners I talked to agree on the merit of Agile and Lean methodologies such as Scrum. Each Scrum component is structured to address a process need. Some of the most successful projects occur when teams can commit to the methodology. However, almost everyone I interviewed didn’t follow the recipe or was forced to take shortcuts. The main reason: lack of resources.

Absence of User Research and Usability Testing

Our Agile panelists agree on the importance of validating designs. Unfortunately, most teams don’t conduct user research on a consistent basis, if at all. People cite tight deadlines and staffing shortages as reasons for deficiencies in user-centered activities. However, discount usability methods can accommodate short timelines as needed.

Skipping user research is extremely risky. Even the best design ideas are just assumptions. There are limits to a genius designer. User research allows us to test our assumptions and prevents cognitive bias from taking over and leading us astray.

“We work under internally imposed deadlines and sometimes need to push things out without testing, which is suboptimal for users.” Julia, UX Designer

“It’s really hard to make usability testing happen. We are short-staffed and don’t have a primary researcher. We’ve borrowed someone from marketing, but he doesn’t know the product enough or abide by our philosophy of ‘we love our users’.” Julia, UX Designer

“We don’t have time to run user testing.” Victor, Software Engineer

The good news is Lean UX techniques such as sketching, wireframing, and paper prototyping have gained support. Designers are encouraged to create low-fidelity prototypes as a way to demonstrate ideas and reduce heavy documentation. The downside is that many organizations are not testing them with target users.

“We try to be somewhat lean. My boss is encouraging us to not use wireframes—go with sketches. It was a difficult transition. People joke of me being a wireframing addict. Sketches helped me understand the idea of what we are all thinking.” Julia, UX Designer

“We’ve been doing quick and dirty paper and drawing mockups and collaborating with development more.” Mandy, Senior Programmer Analyst

Tips for Running Smooth UX Agile Teams

Keep Teams Consistent

It takes time to build a good, cohesive team with the domain knowledge to make the right decisions quickly. Each Agile team may work differently and have a unique team dynamic. Disrupting the system wildly interrupts velocity because knowledge and expectations must be reestablished.

“Team consistency is key. Stop reorganizing and shuffling people around. Teams that stay together, learn together, and keep getting better and faster.” Derek, Lead Researcher & UX Designer

“It’s a challenge for me because resources are not dedicated. One week we have this person; next week we have another person. We got an Agile coach onsite but if everyone doesn’t get the training or stick to a project long enough, then you have to start over again when you get a new person… Don’t move people back and forth between Agile and waterfall.” Michelle, UI Designer

Be Proactive Not Reactive

If you are used to working “head down” for long stretches of time, then you need to change your work style or risk being outdated. Collaboration is key in successful product development. The involvement of cross-functional team members facilitates transparency and allows issues to be identified early. Be involved in all aspects of the design process, including planning. Be prepared to share your ideas, show what you are working on, and contribute to discussions.

“Everyone needs to be proactive in improving communication. Be invested in your team and what you are creating. Be an owner not a renter.” Julia, UX Designer

“Developers need to ask, not just take orders. Everyone needs to be interested in working as a team.” Julia, UX Designer

Have a Dedicated Scrum Master, Especially at the Beginning

If you are thinking about going Agile or you are just starting out, make sure to allocate budget for a Scrum master. This person will ensure that the process goes smoothly. Without an experienced coordinator, there is a good chance that things will go wrong, leaving people feeling disgruntled about the process.

“Make sure you have a dedicated Scrum master. If you can’t do that, be clear about roles.” Mandy, Senior Programmer Analyst

“The Scrum master is a sheep dog, bulldozer, and coach. They make sure issues get resolved and the team is motivated. The danger of not having a Scrum master is that everyone thinks the process is disorganized.” Jeff, Product Owner

UX Must Work at Least One Step Ahead of the Sprint

Agile is development friendly, but that’s no excuse for reducing UX’s influence. Effective UX professionals incorporate themselves in the Agile process by actively contributing ideas—from backlog grooming and print planning to wireframing and user research. UX designers must plan activities before the sprint occurs, which means being proactive and testing assumptions and tackling designs ahead of the rest of the team. They conduct “show-and-tell” activities ahead of sprints to introduce concepts to users and team members so that, when development is ready to begin, the team has the designs that they need.

“The UX designer must be at least one step ahead of the sprint. In other words, do research and design work outside of the current sprint. I have to keep laying the tracks for the team.” Derek, Lead Researcher & UX Designer

“The UX person should go ahead of the sprint with mockups.” Michelle, UI Designer

“Design a little ahead of development. Development is more comfortable with that. They don’t want ambiguous concepts.” Jeff, Product Owner

Conclusion

Agile will continue to gain momentum as organizations discover the benefits. UX professionals must adapt to Agile and lean UX processes, which value transparency, collaboration, and responsiveness or risk being left behind.

The Agile user-experience process is more than just being a thoughtful designer; you must first know the user and continually test your assumptions. Don’t allow user research to run away from you during the compressed timeline of the Agile process. Get out of the office and learn from your users. It is possible to incorporate lean UX techniques into an Agile development process. Methods like online user testing can get you user feedback in minutes.

Superimposed Experience

20150527-moorhead-dq-cone-5-jackie-varriano

 

I’m writing this post is response to a prompt I found on the Toptal Freelance Interactive Designers Group website. They ask me to talk in a general way about I want to bring to UX. In short, it’s one of my goals to stamp out bad UX everywhere I find. My goal is to increase empathy and help people solve problems through better design.  Bad UX is not limited to terrible apps and crummy websites. It exists everywhere. Take this, for example:

Last Tuesday I got back from a trip to Seattle (where I was attending the Nielsen Norman Group UX training, which I may cover in another post) and we decided to celebrate by going out for burgers. We went the Starlite, a no-frills burger place that’s been run by the same family since the 1950s. The burgers are huge and inexpensive, taste great and are always the same. They arrive wrapped in customary white waxed paper and are served ála carte, fries and onion rings sold separately. It’s an absolutely consistent experience, and as a result the place is packed every night.

In the same parking lot is a Dairy Queen of about the same vintage. The establishment complies with the franchise’s expectations. Blizzards are served upside down or the next one is free, etc. They do a good business despite the fact that Cedar Rapids has a disproportionate amount of Dairy Queens for a city its size. I think we have about one per square mile, but I might be mistaken.

And as it always has been at Dairy Queen, the staff is comprised exclusively of teenagers, which brings me to my point.

Last night after our grease-fest of a dinner we walked across the lot to the DQ and got ice cream. My wife and I, both full as ticks in summertime, each ordered a small dipped cone. We were served gleaming towers of candy-coated soft serve, ten ounces at least, bulging over the sides of the cone like John Goodman in a t-shirt.

It was way more than we wanted or needed; we ordered smalls because we wanted smalls.

Why were the cones so big? I have a theory, and (as always with me) it is a UX theory. See, the guy who served us was a teenager. In his world. the only possible reason you would get a small cone is that you can’t afford a big one. He thought he was doing us a favor, even winking at me as he handed the teetering confections through the service window. “Here are your smalls, sir.”

You see, he superimposed his experience on ours. His world was all he thought about as he piled a pound or so of ice cream onto the tiny cones. With every good intention he harmed the business (infinitesimally) by wasting product and, especially, by not giving us what we wanted.

Of course, I didn’t call the manager and threaten them with legal action, nor did I organize a group of picketers to yell obscenities at their customers. In fact, I dutifully ate the entire cone, but I regretted it. I don’t need any help gaining weight these days. Will I be back to Dairy Queen? Will I be back to that Dairy Queen? Probably. This isn’t an actual problem, only a hypothetical.

This is the conundrum in design: we start by designing for ourselves, creating something that pleases us. How many times as I designer did I sit in meetings with a client only to watch them choose the comp I threw in at the last moment instead of the one I toiled over? Countless. But at a certain point, I came to the tremendous realization that I was often wrong. What I like is not necessarily what the user will like. This is why UX research is so important. In order to design from the outside in, I need to understand the user and what they are trying to do. If you add mobile into the sauce, I also need to know where they are trying to do it.

Southern_Vectis_311_HW54_BUO_and_Ryde_Tesco_bus_stop

For example, a public transit website could benefit greatly by having its mobile version prioritize the top question one might have while at a bus stop:
-When is the bus getting here?
-When will it arrive at the destination?
-How do I get a bus pass?

And so forth. This added dimension of empathy can lead to some surprising solutions, especially if a top-notch developer is roped into the prototyping process.

The best thing about the global campaign to eliminate bad UX is the amazing opportunities that you come across in day-to-day life.