Zoll Data Systems makes a touchscreen electronic medical record program for fire and rescue and Emergency Medical Services (EMS) professionals working in the field. Their previous version was outdated and difficult to use. When the company followed a user-centered design process for the first time, the new version fixed a number of critical usability issues and resulted in an extremely successful user experience and a financial success for the company.

The software runs on Windows-based touchscreen tablet and notebook computers. The previous version was successful, but was built on old architecture and technology. The interface was an old-style Windows desktop application, with no workflow. It was not conducive to touchscreen use in emergency vehicles by users wearing gloves and caring for patients, often with severe medical situations.

The previous user interface (shown in Figure 1), used standard Windows desktop interface elements that were inappropriate for a touchscreen interface. Many of the interface elements were difficult to use. For example, there were over thirty icons in the toolbar, making it difficult to remember the functionality associated with each icon. Two rows of small tabs also made it awkward to navigate through the interface, especially using the touchscreen. The text area was also very small. Finally, many non-standard, custom controls were created for common data-entry UI elements, such as dates and times. These custom controls caused many usability problems.

Screen image of the previous interface. It is a busy Windows screen.
The previous interface

The previous interface

Phase 1 – Field Observation and Requirements Gathering

As a usability consultant, I acted as usability team lead for the new user-centered design process. We started by collecting f unctional and usability requirements from existing and new customers and users. The project manager and I rode in ambulances and fire and rescue vehicles in Florida and Texas for four days. We observed EMS and fire and rescue professionals using the product in the field, and gathered their feedback on the user interface. The results from this phase were used to further refine functional and user requirements.

One key observation was that a large number of EMS and fire and rescue professionals, like many others in healthcare fields, are not comfortable with computers and electronic data collection. Their primary role is to care for and transport patients in emergency situations. Many are used to using paper documentation rather than electronic data collection systems (see Figure 2). This observation led us to define additional user requirements regarding training, intuitiveness, and directed workflow navigation.

Photo showing EMS staff in an ambulance using paper system
Paper-based data collection in the field

Paper-based data collection in the field

Phase 2 – Interface Design and Prototyping

The project’s design phase involved iteratively creating and reviewing conceptual and functional prototypes. We also achieved tremendous end-user input and involvement through conferences, blogs, and design reviews. The new design incorporated these key interface design and usability concepts:

* System-driven UI for common tasks (wizard). The new design allows users to enter data in a customer-customizable, field-level and screen-level workflow. Users can also navigate the UI independent of the workflow.
* Auto-advance to the next field or screen when appropriate for tasks. Single-selection fields allow users to enter data and to quickly and automatically navigate to the next field or screen.
* High-contrast color palette (for daylight use). We conducted extensive research on interface design colors, fonts, and contrast for use in extreme indoor and outdoor lighting conditions.
* Buttons, icons, controls, and selectable items are large enough for easy touchscreen access.
* All list selection is made using large-font lists with custom scroll buttons (no drop-down lists). All lists are displayed with large, selectable targets. Large scroll buttons allow page up/down and top/bottom of list navigation.
* Data entry can be delayed until a more convenient time. A customizable “Quick Log” screen allows medics to time-stamp procedures with one click. Then, at any time, users can go back and complete the required information for each entered procedure.
* Immediate validation with hyperlink to error fields. When a patient record is completed, a validation screen displays a list of errors or incomplete fields. By clicking on an item in the list, the user is taken directly to the appropriate field for action.
* Configurable screens and a database-driven UI.

Phase 3 – Final Product Design

After prototyping each functional area of the application and each type of documentation data entry, we turned the prototype and a functional specification over to the development team. As the usability team lead, I worked closely with the developers to review the application interface and interaction as development progressed. We also asked existing customers to review the new application as it was built.

After market introduction, the new product has been extremely well-received by customers and users. Two years of user and business feedback shows that the return on investment (ROI) for the company has been tremendous.

The new product in use

A photo of EMS staff working with a patient in the field, and an overlay of the final product, with a swivelling monitor
The new product in use

The product has received rave reviews and exceptional user acceptance. Training time and costs have been greatly reduced, which is a major selling feature for products in this field where there is high employee turnover. Training time was reduced from one week to three hours. One large customer could not get a competitor’s product up and running for a year. With Zoll’s new product design, the customer went “live” in two weeks without any training.

The interface redesign project cost approximately one million US dollars. Within two years, the new product design enabled the company to gain new and larger clients. They doubled the product’s customer base, more than doubled the number of licenses, and more than tripled the product’s revenue for the company. This success also allowed Zoll to increase the product’s price and offer additional product modules that contributed to the overall product revenue.

While usability improvements often improve a product’s acceptance, the company actually closed many new deals specifically because of the product’s usability and user interface.

Because of the success of this project, new major products or product redesigns within the company follow the user-centered process described here, and incorporate ongoing end-user involvement.
The Evolution of the Design
1. High-level screen layout and navigation area prototype

Screen image showing controls around the outside edges

The new design introduced a new page layout with navigation areas designed to provide consistent and intuitive button location and interaction, while maximizing the main work area of the application.

* Top-level navigation buttons across the top
* Sub-section buttons displayed down the left side
* Application navigation to the inbox and to major actions, such as completing a call, accessing the Quick Log, Scratch Pad, and Options on the bottom of the screen
* Page navigation in the bottom-right corner

2. Prototype screen for specifying the patient’s gender

Screen image showing form to select gender

The vertical area in the left on the main area displays a summary of the data fields in the particular section.

Color highlighting helps users see the status of the data.

* Green fields indicate already entered data
* White shows fields that had not been entered
* Blue highlights the current field.

Selecting a value for the field automatically advances to the next data element in the workflow.
3. Inbox Screen

Screen image showing calls waiting for the ambulance team

The first screen shown after logging in displays the Crew’s Inbox, detailing a list of their current assignments.
Double-tapping an item or pressing the Open button opens that patient’s documentation screens.
4. Data Entry Screen

Screen image with a selection list and on-screen touch keyboard
In this typical screen, the user is filling in the name of the state where the patient was picked up. A list may default to the appropriate state if the company works in one state. A long list, such as state, displays an on-screen keyboard for users to enter letters to more quickly navigate than using the scroll bar area.
5. Graphical Body Navigation

Screen image showing a front and rear view ofa generic body to use for navigation. A list of symptoms is on the left.

Users were most excited about the new design’s use of body illustrations for graphical assessment, navigation, and selection. Users can touch a specific body area to navigate further or to select that area.
6. Body Type Selection Screen

The body type selection screen shows 4 options: male, female, child and infant

Users were able to select the appropriate body type for their assessment. Touching the Body Type button displayed a pop-up window showing male, female, child, and infant body types.

All illustrations courtesy of Zoll Data Systems

About the Author:
Theo Mandel’s background includes over twenty years in the field of user interface design and usability. He earned an M.A. and Ph.D. in Cognitive and Quantitative Psychology from the University of Colorado. He spent eleven years at IBM conducting software interface research, establishing industry-wide guidelines in graphical user interfaces and object-oriented user interfaces (OOUIs), and conducting hardware and software usability evaluations. He’s written two well-respected books in our field. The most recent is The Elements of User Interface Design (Wiley & Sons, 1997). Since 1992, he’s worked as an independent software usability consultant. He was also a co-founder and the chief usability officer for an electronic medical records software company in the late 1990’s. He serves as the healthcare chairman for World Usability Day 2007 and kicked off WUD 2007 at the UPA conference with the case study described in this article. He has worked in healthcare usability for the past ten years.

By Theo Mandel, Ph.D.
All rights reserved

Source

Source

Source

Source

Stop this process

Zaur Giyasov: Wow! In some cases user can do more than expects.

Article is written specially for the conference by request of organizers. October, 2009

One of the things I’ve been saying for years is that just because applications or services or device types change, the basic principles and methods that we use for UX have not and should not change. And, applying them when more and more every-day users are involved becomes even more important. We should still do good UCD and good user research and good user testing/evaluation/validation. But, what has changed over the years is how those things can and should be done for the most return on investment (ROI). Two things really matter when looking at which activities to perform and when: the cost of those activities, and the expected improvements you will get or the potential lost that might result by not doing them. In general, we’ve never had enough time or money or resources to do everything we wanted to do, so picking carefully, no matter what kind of project you are on, makes good business sense.

Discount Methods

Discount methods have been proposed and championed by such folks as Jakob Nielsen and Jared Spool for over 20 years now, saying, for example, that “the best results come from testing no more than 5 users and running as many small tests as you can afford.” (1)

The basic idea here is this: qualitative studies are less expensive to run than quantitative studies, and deliver faster, cheaper ROI. As Nielsen states: “you don’t have to measure usability to improve it…….When you see several people being stumped by the same design element, you don’t really need to know how much the users are being delayed.” (2) For example, in one of my tests this past year, we observed 2 users fail with the same task. Here, we didn’t even wait to test the other 3 users, but instead, revised the design, and began testing again with the new design. The next 3 users were successful in the task.

So, doing heavy-weight methods, even if you can, may not be the best approach. And, what matters more and more to the business is not just doing something right, but doing the right thing. It’s entirely possible to produce a product that is very usable, but is not one that your users want to use because it doesn’t do what they want to do. Being able to actually influence what is built in addition to how it is built is where we can have the most impact. And, to do that we need to be talking to our users. Early. Often. Continuously. And, three methods that are the most useful in discount usability are:

• Rapid usability testing using qualitative methods
• Quick-and-dirty prototypes to get things in front of users rapidly – paper is very good here
• Heuristic evaluation by your own team – you can catch a lot of things yourself

Now, the one thing missing from this list above is basic user research (e.g., task analysis, contextual inquiry, observation, interviews). As Hurst says, without talking to your users and knowing the direction to set for the discount methods, it’s a matter of “Ready-Fire-Aim” or, doing good things for the wrong reason. (3) User research has traditionally taken a lot of up-front time and does not fit in well with rapid iterations. But what if you start combining the methods, or at least combining their use with the same users in a single session?

While methodological purists may cringe (and even when I teach, I teach them separately), over years of experience, I’ve been blurring the lines more and more between doing user research and doing user testing. Recently, I’ve noticed others have been going in the same direction, so my assumption is that it has a lot to do with our evolving role and how we do our work.

In a recent article, Chisnell talks about using usability testing as more of a formative tool than how we usually think about it as a more summative tool. She asserts that usability testing should be done “wherever and whenever users normally do the task they’re trying to do…” (4) While I do believe that usability testing is a powerful tool for us to have in our UX toolbox, I’ve thought for years that testing in a lab is an artificial environment. You have to ask yourself how accurate the data is for everyday use of a product. Will those things that come up during normal use come up during your lab test using your scenario? Is it even less true for more consumer-type products? And, for that reason I really like trying to do more of this kind of evaluation on site with users in their own work environment.

Let’s take an example. Suppose you have an existing product that you need to do some major re-design for. In order to do that, you really need to find out what is critical to keep and what can be discarded – critical to what the user needs to do, that is. So, how might you go about that? Well, one way might be to do some site visits with your current users. Watch them use the current product for awhile. Then begin asking them questions about what they are doing, why they doing that, what they cannot do that they would like to, and the like. Then, moving from more of a user research stance to a testing stance, you might put a few alternative designs in front of them and ask if any of these might help them with that task or make it easier. Engage them in a bit of participatory design as well as a bit of evaluation of what you are proposing. Does it make it better? What else might they suggest? One of the really cool things about having a more open set of alternatives is that the users are generally more willing to engage in a conversation about their needs and wants as opposed to being presented with one design which they tend to say “yes” or “no” to.

Further down the road a bit, once you have something that is actually mocked up or coded, having them try to use it in their own environment with a task they were just doing also tends to tease out a bit more of the things they would encounter day-to-day rather than testing something rather more disjointed in the lab. One of the things I discovered, for example, is how much interruption one of my user sets was encountering. So, when they finally came back to the product to continue what they were doing, they could not recall where they were or what they had selected to get there. This highlighted quickly and clearly the need for more onscreen noting of these sorts of things so they could remain “grounded” in their task, something that had never come up in the lab. And users tend to tell you lots of stories about things like the last time Y happened to them. The stories are really powerful collateral for the design work.

Roughly 10 years ago, I started using more and more user stories and storytelling in my work. (5) The words and experiences of the actual users have a power to help us understand their needs and activities more deeply, and to more effectively be able to relate to them, and to communicate those experiences with others on our teams. Simply telling a developer to add Feature A is not nearly as compelling as telling them the story about how User X is currently doing their task, what frustrations they are going through, and what happened the last time they tried to Task B. It makes it more real.

How do you get user stories? From the users of course! In doing user research, you can prompt for them during contextual inquiry or interviews, and, you can also prompt for them during evaluations as I mentioned earlier.

Stories influence user scenarios and use cases, and can fit nicely into our development processes. But, then development processes for many teams changed as they adopted agile development methods.

How and Why Does Agile Change Things?

Agile software development processes vary, but generally they have in common the following factors:

• Customer input on an ongoing basis
• Rapid iterations
• Delivering work value quickly

UCD/UX designers, while they certainly favor customer input on an ongoing basis, also tend to work with a lot of up-front design and user research, hopefully well before development begins. So, when agile development mixes analysis, design, development, and delivery throughout the process, it means that the UX person’s work will necessarily need to adapt to this new model.

Now while there are some folks who believe that UX and agile development are at odds with each other, I look at it as a marvelous opportunity to have the kind of input and focus we’ve been wanting for years. How many times have you found something that is highly desired by the users but you are told by the development team that it will need to wait for the next version?

With agile development and doing re-prioritizing and planning for each iteration, it is much easier to get those important items considered and included. It also lowers our risk of delivering a bad user interface as we have early user input and several iterations to make substantial improvements. Using the concept of parallel UX and development tracks makes this whole process much easier. And, a similar process can work for UX consultants who are not part of the team as they can work on items in a separate-but-linked manner.

Working as I have been doing on an agile team has almost forced combining different activities in the same time slot with the same user. When we do a usability test in our lab, for example, we might do a number of things with each user while they are there. We might get their input on some design alternatives for features for the next iteration. These are usually done in lower fidelity to encourage discussion. And, we might get their input on some of the features for the current iteration – perhaps we have a couple of questions about some implementation details. And, we might have them test some coded tasks from the previous iteration to evaluate if it meets their needs and our goals.

The use of stories fits in nicely as we are supposed to be developing things that the user actually needs, in priority order. And, stories do one more thing really well: they help the team to look at the whole user experience for coherence instead of just looking at a single feature or iteration.

And those discount methods we talked about earlier? They actually work very well with the agile methods because you can test with a small number of users once or more per iteration, and, with many iterations, you end up running a lot of tests but refining and evolving your designs as you go. And, in agile development, as with the earlier waterfall method, using discount methods are a way to assist the UX person in their design work quickly and at more economical costs.

References

1. Nielsen, Jakob (2000). Why you only need to test with 5 users. Alertbox March 19, useit.com

2. Nielsen, Jakob (2006). Quantitative Studies: How many users to test? Alertbox June 26, useit.com

3. Hurst, Mark (2009). A lesson in strategy, taught by a Cat. Good Experience, September 24, goodexperience.com

4. Chisnell, Dana (2009). Testing in the Wild, Seizing Opportunity. In UIEtips, August 12, www.uie.com

5. Daniel Gruen; Thyra Rauch; Sarah Redpath; Stefan Reuettinger (2002). “The Use of Stories in User Experience Design” The International Journal of Human-Computer Interaction.

That was one project. Another interesting project concerns the physical spaces in the airline industry. Here we’re looking at seating design, flight experience, and in-flight entertainment. There are quite a few projects now emerging where we’re looking outside the web space and being driven more by our clients.

Dmitriy: That’s very interesting and I think important for both Russia and New Zealand. From New Zealand it takes ages to fly to another country! And it’s similarly important for Russia as our country is so large. Spending 10 hours on a plane, in an uncomfortable seat, is definitely a large problem.

Shailesh: Yes, that’s right. This project is just one example of the growing amount of work we’ve been doing outside the web space. It’s also been a lot of fun. The other thing we’ve noticed is that due to the worldwide recession, New Zealand companies have increasingly been looking at cost saving measures. A lot of clients have focused, as we do, on training internal staff. This is so that after a project has finished they actually wind up with a few more internal skills. So we’re finding a lot more companies building internal capability and performing their own usability studies that involve not only training, but coaching and mentoring. Rather than just sitting in a room and merely telling clients about usability, we actually work on projects together with them and help sharpen their skills. This is now an important part of what companies are looking.

Dmitriy: You recall Apala Chavan from Human Factors International, who presented at the last conference on cross cultural differences and about how people from different cultures use various products. We talked with her recently and she told us that it’s now easier, due to the global crisis, to sell usability. She said that a lot of people are interested in going online as it’s cheaper to advertise, and because they realize the necessity of making user interfaces friendlier. So what do you think? Is it easier to sell usability now?

Shailesh: Yes, I think there’s actually an element of truth to that. As the year started off slowly for our business, we talked to pretty much every one of our clients over a period of about 8 weeks. What we found was that when the economic crisis hit, a lot of companies halted a number their projects and began internal discussion about what their top priorities were. So now, instead of doing 15 projects a year, they may only do 7. They might halve the number of projects they take on. Following this, they re-committed to do these fewer projects really well in order to create a point of difference amongst their competitors.
That’s led to Optimal Usability being very busy at the moment. Part of all this new business is the result of these projects wanting to ensure that customer experience is a significant part of their design. So to some extent usability is becoming a bit easier to sell because when people want to do something, they want to do it properly. I think on top of that, and as part of the user design process, we’re testing products we deliver to clients as we design them. This means we’re now actually launching products that have a lot more certainty. So to an extent we perform risk mitigation for clients when we produce products that employ user centered design technology.

Dmitriy: We last met approximately two years ago. Do you think anything has changed in user behavior since then? As far as I understand, design needs to be based on certain conventions. Users are accustomed to certain standards. For instance, customers want to have navigation on the website, and a search function of some kind or a navigation tree onsite. And they expect to click on a logo button to go back to the home page, etc. There are many conventions. And we have to respect them in order to make a website user friendly. Are there any new conventions or standards that have emerged during the last two or three years?

Shailesh: Oh, indeed there are. I think we need to accept that as much as conventions exist, they will evolve over time. Part of what’s happening is that things are becoming more complex. And as we introduce more complex problems, we try to come up with very elegant solutions to eliminate these problems for the end user. What that means is that we must now do things in slightly different ways. The trick, and what we need to help our clients with if we’re going to change, stretch or even create new conventions, is the way in which we design in order to help our users learn to interact with interfaces or products.

I guess that’s the art of what we do. So yes, I think things are changing.

Dmitriy: Can you give us an example? Is there anything in particular, something new that has emerged in the interface design business?

Shailesh: Well, once again, what is a convention in one particular application isn’t necessarily a convention that applies across the board. So context is very important. I could say something, but it may not be a convention in a particular country. In terms of what we see in New Zealand, behavior is shifting. Even behavior as simple as how to search using a particular browser, and how browsers interrelate, is constantly in flux. It’s also interesting to see behavior change over time. But I think that’s the nature of what we do. We need to do research in order to understand behavior. And part of the reason we do it is because behavior changes over time. We’re trying to stretch the limits a little bit in terms of the technology we’re providing people. So we need to create new conventions.

Dmitriy: When you mentioned airplanes I was really excited about learning more. I was interested and curious about what’s going to be changed. Is there any particular thing you discovered that would change, for instance, as a plane’s interior convention?

Shailesh: Unfortunately, I can’t tell you [laughing].

Dmitriy: Ok, so it’s a secret. But you did find out?

Shailesh: Yes. But it’s a secret. I’ve signed an NDA agreement not to say anything about it.

Dmitriy: Ok. That’s very interesting. I’m really looking forward to the discovery one day! Another subject that I’d like to discuss is the conflict that we’ve experienced in our usability practices between business owners, managers and usability analysts. Sometimes we have a significant conflict this area. Usability experts want to make a site as user friendly as possible. They want all the functions to be easily available at the second click and the site to be easily navigable with the purpose of the website clearly stated. But sometimes business owners want to do the opposite, and not just because they don’t realize that user friendly websites are good. They behave this way because there are certain business goals that are achieved through making a website not so user friendly.

For instance, we all know that supermarkets and large stores are designed in such a way that you must go through many aisles in order to get to what you want. The reason for this is that sometimes by walking to the milk counter, for instance, you pass through a lot of other counters en route which sell goods you don’t necessarily intend to buy. But as you go through all these aisles, you recall the products you see as being good and helpful, and buy many more items than you wanted to buy in the beginning. We encounter similar issues in website design where owners want users to go through hassle and unnecessary steps in order to promote other goods.

I’ll give you one example. We had a beauty contest website wherein users were supposed to vote for beautiful girls. Suddenly, as we were testing the site, we noticed that it was trying to push you to invite your friends to vote. So there were two goals. The user goal to find the best girl on the website, and another goal the owner wanted to achieve. This was a viral effect to attract more users by having voters invite their friends to vote.

So what’s your viewpoint? Does this case illustrate a common conflict that we have to solve? Do we need to find a compromise? Or is there no problem at all as this was just an isolated case?

Shailesh: Great question. I think that certainly, in all my experience, this conflict between usability and business goals is a major issue we have to deal with. I don’t think we’ll ever get away from it. But I think in certain cases the conflict, rather the tension between user objectives and business objectives, is a question of how great that tension is. It’s usually not that big. But many times the problems we’re given to solve are much bigger. Part of our job, about which I was talking to my business partners a few days ago, is not only the art or science of usability. A huge part of our job is actually managing people, knowing how to persuade them while understanding how to manage this very kind of conflict.

So I guess to be a good usability consultant is not just about knowing usability methods and carrying out user profiling and user testing plus all the other things in the toolbox. It’s about being able to understand business objectives, about what clients are really trying to achieve and about understanding user objectives. Then part of it, if we choose to ignore user objectives, is being able to explain to the client that these are the consequences. Part of the challenge is how to present a solution where clients understand they’re getting the best compromise between business objectives and user objectives. So I think that the skill set of the usability consultant should include the ability to look at situations and come up with different options, plus be able to present them in different ways.

Dmitriy: That’s good. What you’re saying is very much in tune with what we’re doing here as well. I also recently talked to Eric Shaffer of Human Factors International about this. They have something called P.E.T design, which stands for persuasion, emotion and trust. We’ve also coined the phrase ‘Catching a customer’s gaze’.

What we’re trying to do on the website is catch the customers’s gaze and focus their attention on particular functions. We try to lead customers to product conversion. That is to try and persuade them to purchase as a customer and become more than just a visitor. So I think the overall trend in usability is not just building sites by standards, and not just becoming user friendly, but becoming efficient both for the business and the users.

Shailesh: A rough example of what I mean…Users would typically say they prefer a website have no advertising on it. They would favor to just look at content and explore. From a business perspective, revenue is likely driven by advertising which clients sell on the site. So they’ll say “I want advertising everywhere. I want big flashing banner adverts. I want skyscrapers here. I want those flash ads to come across the screen and grab people’s attention” and so on. From that angle, as a professional, you would say that this will really cause a problem with users. As a professional you realize that the business I’m representing wants to generate as much revenue as possible, while users are coming for content. So the problem that we essentially have is how to present advertising on this particular site in such a way that’s non-intrusive for the user, and may actually be helpful. You might start looking at how to provide contextual advertising, or how to manage the animation that occurs on advertising so that it’s not intrusive. It may be that instead of animating an advert repeatedly, you may actually animate the advertising once. Or you might have rules where you don’t have multiple animations appearing on the same page.

There are numerous things you can do that allow you to minimize the annoyance to users and still deliver the business goals. And part of this is explaining to the client, with the use of behavioral research, that the actual aim is to get users to come to your site. The purpose is not to scare them away, but to make sure they keep coming back. To accomplish this, one must present content that is useful and advertising that’s not annoying. This simply needs to be done in the right way.

Dmitriy: So what would be your suggestion or message to those in attendance at User Experience 2009 in Moscow this coming October? We plan to have a lot of participants. At this point we already have a large number of registrants, which is encouraging because people usually don’t start to register until a few weeks before an event such as this. So it’s going to be a big conference. Do you have a particular message to the conference? Something you would suggest to the industry?

Shailesh: I think it’s safe to say that the field of usability is broadening quickly into a set of organizations that look at customer experience. So my message to the conference is that they should think quite holistically about things. Usability is going to be viewed as cross-channel experiences. People are going to have to look holistically at its problems and must become creative in the way they solve them.
In particular, we’ve had clients present us with problems such as the flight experience project I mentioned earlier. The client came to us knowing we’ve never done this before, but knew we could figure it out. I guess that’s the message. The more clients understand the importance of customer experience, the more they’re going to present very complex problems. We need to be creative in the way in which we approach these problems, and push the boundaries of our knowledge and learning to make sure we’re able to effectively tackle these difficult problems.

Dmitriy: Sure, I think I’m getting your idea because we’re also looking forward to testing more offline products and the various issues they bring. We’ve been testing different things here in Moscow such as customer experience in banks.

Well, Shailesh, it’s been great talking to you. Thank you very much for the interview. We really hope to see you here in Moscow soon!