11 years in the making

I’m a Product Designer and Product Owner with a background in UX design, research, analysis and development. I have experience in the whole spectrum of an online product from the low intent marketing campaigns, through the funnel optimization, to B2B tools and user interfaces.

I use empathy to understand the user’s frustrations, goal and motivations, to solve their problems and deliver an engaging experience.

With finesse I make sure that their experience is not just intuitive but visually pleasing and delightful. I iterate on creative solutions to find what works best.

With a psychological approach I optimize conversion and get evidence of my results at every step of the process. I collaborate with stakeholders and fellow designers, with one eye always on the the business goals the other on the spotless technical execution.

My Design Process with the user in the focus

Research

Gather available quantitative data (Google Analytics, heat maps, MySQL/Hadoop)

Get qualitative answers to your questions (surveys, dirty street user testing, website feedback, in-lab user test)

KISS — Keep it Simple, Stupid

Creating functioning user interfaces is easy. Creating simple UIs is an art.
Only give the users what they need, not everything you have.

Analyze

Believing in a solution is half success. The other half lies in the data — do A/B tests, keep your eyes on the data trends, ask the users how satisfied they are.

Learn, adapt, iterate.

Native in HTML/CSS

I’m from those good old times when freelance designers had to code what they put on their Photoshop canvas. 8 years later Sketch took over and made mocking up and prototyping much faster — but it didn’t take my passion for quick and precise HTML/CSS/LESS coding away.

It gives me independence and agility, which makes me able to deliver quicker, and start getting feedback from the users sooner.

From ideation to delivery. That’s how I roll.

Contact

Add me to your professional network via LinkedIn

Read my publications on Medium

Follow my #sixpackmission on Instagram

Feel free to send me a message via Email (szogyenyi.zina@gmail.com)

Check out some of my old work on Dribbble

Give me kudos on Strava

I create simple, exciting product that solve user problems was originally published in Rozina’s Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Background

Tripaneer sells theme vacations instead of destinations. The platform brings together numerous organizers and travellers across the globe who can find each other easily via themed websites, like bookyogaretreats.com.

Currently, only 10–15% of reservations happen instantly, the rest still requires communication between the parties to agree on availability and terms. I started working on improving the experience and business results of the organizer side in June 2017, this is the case of how I improved the usability and the results of the inquiry management.

Defining the problem

I used multiple resources to try to find the biggest pain points. From our operations team I heard that editing the offers was difficult, and the organizers often didn’t use the correct tab for their response.

With a simple look, it was clear that the mobile version was even more difficult to use, it was responsive, but not optimized to small screens at all, just a long page with a lot of options.

Research and finding signals

We know that mobile experience is important. But how important is it for our business?. I sought for the answer in our database. I compared thousands of inquiries from the last few months and grouped by their status and categorized by the time it took for the organizers to send the first response. The result was self-explanatory:

Statuses of inquiries grouped by the first response time from organizer

The conversion rate from inquiry to finalized booking dropped with every hour delay in the first response. I calculated the probable impact we could make there: if we moved every organizer to the previous category we could have improved the finalized bookings by 10%.

How to make this happen? Make it a lot easier for them to respond on mobile. So they don’t have to open the computer at all when they’re not at their desks.

The lowest hanging fruit

To make it bulletproof on mobile there were quite a lot of infrastructural changes necessary, as the template was overly complicated and very difficult to make meaningful changes. Many nested conditions, many different cases forked into one long big code.

Before we decide to redo all the logic and make a lot simpler structure, we had to get some signal that our ideas make sense and they actually improve the usability.

Having to pick a tab before responding is not an intuitive way to decide whether a retreat is available on certain dates or not.

The main entry point to the page is the notification email, why don’t we test the new actions in the email first? It’s easy, quick and it would take a lot less time to develop and start getting the feedback.

Old email with single action vs new email with quick actions and inquiry summary

It included changes like:

• clear call to action (please respond) in the header
• highlighting the customer’s message that required response
• summarizing the selected package details above the calls to action so the reader doesn’t have to scroll back and forth
• clear action oriented buttons instead of “click here to reply”

The result and the learning

The number of clicks was about the same in both variants, however, where we had multiple actions the click share were similarly distributed as the overall actions taken on each inquiry. The average response time decreased by 15% and the granted availability went up by 5%, both results were significant.

This experiment showed the usefulness of easy actions and backed up the research results of the importance of first response times.

Improving the mobile view

Even before we jump into code clean up and structural changes — which eventually would be inevitable — we can still do some optimization for mobile devices — making it a lot intuitive and delightful to use.

I decided to give guidance on how to process a request instead of just putting a long and complicated form in the front of our organizers.

Initial view, package editing view and message view of the inquiry approval process.

• I reduced the unnecessary padding from the sides and made the page full width — those extra 40 pixels worth a lot on mobile
• I took the request summary and put it on the top of the page for easier overview, and put the customer’s message right underneath, which used to be on the bottom of the page, below all the forms
• I added a big button to “edit the package” instead of a small link, so it’s easier to notice and use
• Created a title for the forms which instructs the organizer to take action
• adjusted the copy and the visual representation of the tabs to look more obvious which one needs to be selected
• I reflected the exact email content to be sent to the customers when composing a response for transparency.

The result and the learning

This view is still not perfect since it’s still giving too many options to the organizer, which makes the decision more difficult. But at least it’s a step closer towards our vision and gives us chance to get more feedback of our changes.

The experiment was a great success, we got a lot of positive feedback from our organizers. The variant was liked 100% times more than the old one while the experiment was running and got 70% less “bad” or “fair” usability rating compared to the old version.

The effectiveness of the page increased: we got the same amount of finalized bookings from fewer conversations. The correct “tabs” were used correctly and there was less need for our customer service to interfere with problematic inquiries.

The usability increased, the next step is to have it reflected in the business results too.

The feature overhaul — a seamless experience

Throughout time this page got a lot of new states and features (managing availability, messaging with customer, managing booking conditions, dealing with payments, adjusting packages to the customer’s needs), none of these extensions were properly well thought out. It was more important to have the feature somewhere on the page than making it available for whom it is relevant and when it’s relevant. This resulted with a very complex code, which is very difficult to experiment with.

As we have started rebuilding the templates as a part of the rebranding (you can read more about that project here) it was time to move the inquiry management into the new templates, and with that, finally clean up the logic and make the page useful.

I took a mobile-first approach, as we’d like to encourage the organizers to quickly deal with the inquiries.

Defining the stages

To avoid the confusions and difficult conditions in the templates I defined stages of the page, the actions organizer need to take at that point, and the information they need to make decisions.

[Pending status]

1. Customer wants response as soon as possible

2. Organizer wants approve request and customize package based on requests

3. Organizer needs:

• overview of request
• customer’s message
• be able to create custom offer easily
• ask and answer questions quickly
• accept or decline request

[Accept request]

1. Customer wants answer to their questions and payment information
2. Organizer wants to make sure that data is correct and send a welcoming message
3. Organizer needs:

• overview of request
• be able to create custom offer easily
• set payments and booking conditions
• write a personal message

As a result of this exercise, I wasn’t just able to clearly separate the necessary features on the page but also customize the copy to fit the context, which is key to create a delightful experience. When the user feels the human touch, not only the computer-generated forms.

On bigger screens now we can display the conversation above the fold for an easier overview, and on mobile, we make sure that only the most relevant items are on the screen at a certain point.

The next steps

As now we are confident that our inquiry management is a lot easier on mobile we can start working on stories that will shift the inquiry management from desktop to mobile — sending notifications on mobile channels, such as texts, Messenger, WhatsApp, WeChat etc., serve saved responses and previous attachments, and eventually, work on the instant reservations, which eventually will make all this effort redundant. Life of a designer :)

Inquiry management — improving on KPIs was originally published in Rozina’s Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

The sub-brands of Tripaneer, such as bookyogaretreats.com, booksurfcamps.com or bookallsafaris.com were developed to get really good ranking in the search engines, so the users with intent could find it easily without having to spend much on marketing. As a second step, the websites started working well with paid SEM, this still didn’t require much more than working functionality.

As the company slowly started to grow and bring in a meaningful amount of revenue the leadership team decided to prioritize a new and fresh brand for tripaneer.com and with that a new visual style for the web platforms, that reflect the companies mission and vision better.

And that’s how I became the lead designer of the redesign project.

Workshop to establish visual guides

At smaller companies there are a lot more subjective decisions compared to bigger ones, however, I didn’t just want to follow the CEO’s personal preferences. I organized a workshop with the leadership team to establish the basics of the new style together, with meaningful reasonings behind those decisions.

Everyone brought 5 websites they liked to the workshop, mostly e-commerce and travel focussed ones. I asked them to describe why they liked those products, which points I collected and summarized:

• clean white design — the platform supports the product
• simple and consistent design
• doesn’t look cheap
• mobile version — use all horizontal space
• simple base font, plus unique title font style to be recognizable
• lets the user zoom in on the content they’re interested in
• interactive, interested
• detailed view of the products

The next step was for me to translate it into visuals.
First I put together the following guides to discuss it with the stakeholders, then I started working on the mockups one by one, starting with the most important ones in the purchase funnel.

Imagery and layout

Typography

Iconography

Colors

The “before” state

There was a lot of visual noise I had to simplify: (1) boxes with different border radiuses and shadows, (2) multiple different styles of icons, (3) clickable elements with different shades of blue and green, (4) illogical information structure, (5) elements looking like something they were not, (6) elements looking clickable they were not, (7) lot of visual noise over the photos … etc. I could list it for hours. See it for yourself:

How bold changes shall we make in the new design?

So many things were broken (from UI point of view) that I wanted to fix with the redesign that it could have destroyed all the progress that the team had done with constant experimentation and learnings. This was definitely not my intention: even if I have a great idea on how to make the reviews more useful, probably it’s safer to test it separately from the new visual design. If we change too many things at the same time it’ll be really hard to find if we break something. It’ll be also difficult to see if we get something right.

With this redesign experiment, I decided to fix the obviously illogical behaviors and structures, and leave the improvements to a follow-up test.

Defining new visual guidelines to match a new brand was originally published in Rozina’s Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

I took the templates I created a while ago for email marketing, and is being used in Mailchimp, and turned it into a sample of templates that contain all the typical content sections used in about 20–30 different service emails. Instead of designing them one by one this system allows the developers to create reusable modules and use those when building an email content.

Examples for simple service emails

Due to the nature of these emails only technical testing happens, no experimentation necessary.

• they start with a big message that creates clarity what the email is about
• in case there’s a required action then the CTA is right on the top, it may repeat in the bottom
• in case button’s links would break there’s an easy way to retrieve the URLs
• doesn’t use unnecessary imagery, only if it helps with the goal of the email, otherwise keep it simple

Conversion driver service emails

With the emails that make the money (organizer giving availability, customer acting on it and finalizing booking) we can’t risk any changes without testing, therefore these improvements, no matter how obvious they are, go through an A/B test.

• they start with a big message that creates clarity what the email is about
• in case there’s a required action then the CTA is right on the top, it may repeat in the bottom
• summarize the request and only show the most relevant information
• give clear calls to action in case the addressee has multiple choices what to do

Redesign of service emails was originally published in Rozina’s Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

There was a giant white wall next to me as I sat down to my desk the first time and I immediately knew that this wall was going to be my best friend.

I spent my first few days going through all the steps, printing out the screens and putting them up on the wall. With masking tape, I indicated when there were multiple paths to go on and underneath it all I put up all the emails and push notifications that were built into certain steps of the job application process.

Finding the problems

With different colored post-its, I started putting up (1) questions and uncertainties in orange, (2) serious issues in red and (3) ideas how to make things better in pink. That’s almost like a backlog! All we needed was the probable impact we could make with fixing those changes.

Since it’s a long process — which includes recording a video as a part of the application — I wanted to know where are the biggest dropouts and which screens are engaging enough to continue.

First big dropout point — having to register

The widget with the job posts was skinned to match the style of the website it was embedded into. However, the register/login form was to a StartMonday account, inside the widget.

Why do I need to register? Who is StartMonday? Do I have an account already? What do I get if I register? Obviously none of these were answered, the whole screen was just a login form.

Second big dropout point — having to pick how to add video to the application

What video? Is it mandatory? Why did no one tell me about this? Can I finish it another time? So much frustration! There were only 3 buttons (upload, record, download app) and a small skip link, that’s all. This screen needed a lot of love.

Barrier — how can we make all the future improvements skinnable and customizable to the partners brand?

The question is: do we need to? If yes, in what level? We all remember myspace and the outraging custom designs with moving gifs everywhere. That’s what happens if you let people create their own designs. It won’t reflect professionalism we’d like to deliver.

Discard the full skinnable experience, detach the application from the jobs list widget, and everyone wins. The experience can be optimized when not restricted to a tiny widget and the process will be clearer to complete, there’ll be more applicants. And having to support only one version of the application will reduce development resources significantly.

Time for solutions

I started with low-fidelity wireframes, where I wanted to make sure that we are targeting the issues on the orange and red post-its. I added a sense of progress, meaningful names for the steps, descriptive “next” buttons to set expectations and tried to simplify the type of data we asked for in the process.

The video screen

For applicants it was important to understand the role of the video, and that there’s already an amazing app which guides them through the video recording. Since the webcam recorder is not reliable and very few people have pre-recorded intro videos, it was clear that putting the app download into the focus made the most sense. Of course, with a clear and easy way to the alternatives.

The CV upload screen was after the video screen, and it was not clear that they step was coming up, that is why many people dropped out on the video step. Why not bring the CV upload before the motivation?

Yes, the unique feature of StartMonday is the video application. Which is innovative and daring, but are the applicants ready for it? I decided testing switching the two steps. And the result? A significant increase in CV uploads and no decrease in video submissions. That’s a good first step.

The final design

The separated application flow has StartMonday’s branding but also has the visual elements from the employer, such as logo and background. The sense of progress and the expectations of next steps is a lot clearer. The form elements are simple and intuitive.

On the video screen, the order of the items are different on desktop and mobile devices, to embrace the context.

When the video is easy to skip, it’s crucial to follow it up

Employers love the short video applications as it reduces their time screening applicants. The more videos the happier the client is. I conducted a research to find out the main reasons why applicant didn’t submit a video, and these were (in order of frequency):

• didn’t know about it up front, not good timing to record video when applied, but wanted to try later
• didn’t want to add a video
• tried but couldn’t upload video
• has added video but error happened

The first group was the biggest, so I composed a reminder email to applicants who haven’t submitted any videos for 24 hours after starting the application.

With the “incomplete list” design I tried to make them complete the set with 2 items already collected. The closer a collection is to being complete, the more we desire collecting all pieces.

I composed the reinforcement as an opportunity to express their personality or feelings, which people seek for, in general.

This email increased the submitted videos by 10%. The next step is to send a reminder on the weekend, when people have more time.

Optimizing job application flow at StartMonday was originally published in Rozina’s Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

The control version of this test is very plain, a little boring, so I decided to be a lot more inspirational with bolder messaging and imagery. Result? Unfortunately less subscribers.

But was it the messaging or the implementation?

Right after that, I tested promising discount instead of inspiring stories. Guess what? 20% increase in the subscription rate. The only problem is: giving discounts in a scalable way requires quite some development. Something to prioritize with the marketing team.

Turning the plain text welcome email to something more interesting

Before I worked on this email it was really difficult to find out what the next steps should be. You actually had to read. This one not only is to the point but sets the expectations for the future.

Selection of my favourite ideas and designs was originally published in Rozina’s Portfolio on Medium, where people are continuing the conversation by highlighting and responding to this story.

Our content quality team, who reviews the provider created listings kept requesting them to upload more photos in certain topics, because they found the uploaded ones insufficient to publish the listing. This doesn’t only delay the time to put the content live, but also costs more editing resources.

What can I do on the product side to improve this?

Back in the days when we developed this process we added tips to guide the providers on the way. The information is there of what kind of photos we were expecting but no real restriction on the uploaded images themselves. And we know people do not read. So I had to find a more visual approach.

After doing research at some competitors’ and other significant players’ websites I found Esty’s solution the friendliest: they have a grid of examples which show what type of photos shall you upload of your product.

Too bad it’s only a visual gimmick, you can’t actually drop your relevant photos onto the designated drop area (it could feel like completing a puzzle, which is fun). As you add the photos they just start covering the helper icons and push the “Add a photo” call to action to the right.

It’s only visual, not functional, but it got me inspired.

What if we would have multiple drop areas for the different photo categories?

Whoa that’s a bold idea. Let’s do a little risk analysis before we jump in:

Cons

• not an existing UI pattern (or at least I haven’t seen it anywhere while researching), it could take a lot of brain bandwidth to process
• it could cause issues with the sorting if we separate the upload groups
• it could take longer to upload the photos, more providers might drop out of the process

Pros

• clear visual clues, providers don’t have to read the tips to know what we expect from them
• we can set restrictions on the number of photos uploaded per category

From the initial risk analysis it seemed that the pros and cons balanced each other out, so I gave the green light prioritizing the story and scheduled it into the next sprint.

Of course the little UX-pattern devil sat on my shoulder, telling me that it’ll be an instant failure. The angel on my other shoulder kept encouraging me that as long as we keep monitoring our relevant metrics and we understand what they mean everything will be alright.

So I put together a really quick prototype of the desired functionality and passed it on to our developers to build it.

Putting the actual multi-drop zone photo upload tool together wasn’t nearly as easy as the prototype itself. The original script was not ready to deal with multiple sources, multiple buttons, and saving extra information, such as the category the image was dropped to.

Two developers gave up on it, almost three times.

As a designer it’s one of the most painful feelings, acknowledging that your amazing idea might not be feasible. I did believe in the idea and wanted to see the results of a test, but not at all costs.

I sat down with the developers to find out what the main showstoppers were, and we adjusted the idea to something that still serves the original purpose and is deliverable within a reasonable amount of time.

Big thanks for xandi and Mohamed Samir Mohamed for hanging on!

The test, the metrics and the result

As the traffic exposed to the test was pretty small, we kept it running for about a month. Most of the recorded quantitative metrics were very unreliable with such a small test group (300 users in both variants), so we decided to seek qualitative feedback to bring to the table.

Before the test I picked the number of uploaded photos and the amount of providers getting stuck on this step as the main quantitative metric, and the feedback from our editor team as qualitative metric.

When the test ended this amount of information seemed to be not sufficient to make a good decision. The difference between the number of uploaded photos was not statistically significant (14 in the single zone vs. 16.6 in the multi-zone), and I wanted to find a few more metrics that could help me see the bigger picture.

Luckily, we record when an editor asks for photos with more variety, and the total number of requests for more photos were 40% less in the new variation! The feedback from our editors also reinforced this metric:

“I can also say that I haven’t used the improvement point for photos too much in the last 3 weeks either, compared to the past. “

“I also noticed that I used less improvement points for photo and do notice the variety of photos added is better now. I could say that I only use the photo improvement point to ask the organizer to provide better quality of photos.”

There was one metric which I wasn’t really comfortable with: the amount of time it took for providers to complete this step. Compared to the old version’s 14 minutes (including uploading, cropping and sorting) it increased to 26 minutes… Almost doubled.

Some increase makes sense, since now they have to browse their files 4 times, picking the relevant ones, instead of just going into their browser once and selecting all. But almost double the time?

This was the time to look into the engagement.

I watched all the inspectlet recordings to find out if there’s any struggle. I checked the drop out rate of this page. I digged deep into the feedback loop we integrated into this page for negative feedback. And I didn’t find anything. No struggles, no unhappy emojis. They just spent more time on it, to categorize their photos.

It seems that reducing the time spent on a step doesn’t always relate to better user experience and content quality.

Why the multi-drop zone photo upload works?

There are some persuasion techniques I applied in my original idea, which could have something to do with the result.

Set completion

The closer a collection is to being complete, the more we desire collecting all pieces — the fact that this is the last step of the process, the users wanted to complete it, that’s why there was no higher drop out rate.

Pattern Recognition

Our brains seek ways to organize and simplify complex information, even when there is no pattern — we gave them 4 drop zones, which is new, but the pattern and design was the same as it used to be, therefore it seemed to be less unconventional.

Appropriate Challenges

We delight in challenges, especially ones that strike a balance between overwhelming and boring — completing 4 fields with a few photos each is not much extra work compared to one big field. The investment is a little higher, but not too massive.

I would love to make it even more playful and look a bit more like a game, similarly to Etsy’s approach. As a follow up I’ll try to illustrate the drop zones with some icons, so the providers will need to read even less.

What do you think? What would have been your solution? Will you try this one at home?

A Photo Upload tool: invent the UX patterns, don’t follow them was originally published in Tripaneer Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The existing UI solutions

When you search for UI solutions for multi-selecting usually you find similar solutions: give them a drop down that they can both scroll through or search in, and display the items as pills in the input field. Like this.

Or you get the lists with checkboxes hidden into a drop down. Or two lists, and you move your selection from the left one to the right. Like these.

Our system already had a component from Select2, which was similar to the first example. Our developers started using it in multiple areas, as well as the listing creation process, which is made of multiple steps, right on the first step we ask our providers to pick 4–6 relevant tags to their listings from a very long list.

The problem with searchable multi-select

The list we display to our providers is very long. It contains about 300 items and most of them they are not familiar with. From screen recordings I saw that (1) users scrolled only a few times and then gave up on scrolling through the whole list and then (2) they started searching for what they had in mind.

The multi-select pill box is a good solution when the user is familiar with the content of the list and they know what they’re looking for. They can easily find by searching or just scrolling to the relevant part of the list.

In case when the content of the list is not familiar there are multiple issues. Scrolling through a list this long and read every item is extremely tiring. No one does that. Especially when it’s not even sorted alphabetically.

Then their search doesn’t return with any results 50% of the time. Either because they use a different phrase or word order than the strings in the list or the content just isn’t there. After a few trials and errors they give up and move on without actually picking the most relevant tags.

From our content quality team I heard that the overall quality of the picked tags was really low, very generic and not enough, it required a lot of extra researching and time investment to help out the providers and improve the content quality and ranking of their listing.

First idea for improvement

I was seriously considering the “Hybrid Dual List with Filter” solution, as the options are exposed (easier to read) and the selection is clear in list on the right. But how is it mobile friendly? We do develop with a mobile first approach even to our providers, and this solution didn’t fit.

What else? Let’s expose all the options to the providers in a form a tag cloud, like Foursquare does with “tastes”.

With this improvement, we hoped that it’d be easier to find the relevant tags and select them. We were aware that the tag list is too long and unstructured, but it was a good enough small step to make and start learning from.

This was solely an UI change, no data or sorting in the backend was touched. As you can see on the example the “Categories” are not ordered alphabetically, which concerned me a bit. Is it going to be good enough?

Before putting it in the front of our customers I gave both versions to colleagues with 6 items to pick (which I took from a real life example from a screen recording) and measured the time it took them to pick the items I gave them.

On purpose I gave them the list as the provider tried to search for them, not as they are in the list.

In the old version 3 colleague of the 5 gave up the task, 2 of them finished it in over a minute. In the new version they all managed to complete the task within a minute, with a combination of Ctrl+F search and scanning. That was a good enough result for me.

Learnings from this test

I exposed half of our providers to the tag cloud based feature for about a month (due to low traffic), but unfortunately there were no real improvements in (1) picking more relevant tags neither in (2) the speed of finding these tags.

I had to realize that only just exposing the options was not enough, especially when it’s not even sorted. It requires a lot more focus and brain bandwidth as the eye has to jump back and forth, up and down amongst the tags instead of just following a pattern.

Iteration: the next step is a bit bigger

As my belief towards exposing the options didn’t change I had to deal with bringing in order and pattern into the story. This required some changes in the infrastructure as well. Was it going to be worth it?

To make it a little smaller I reused an existing but unused information architecture design which created groups of tags based on similarity and relevance. This saved us a few days of thinking, and I could jump into the iteration with my developer immediately.

We created reasonable size of groups with very bold titles (so users can scan those first quickly and then look into the actual list if they find it relevant) and very nicely organized lists in same sized columns, which responsively changed width in percentage but kept the from-up-to-down reading direction.

First I built the columns with display: flex; which ordered the items from left to right instead of from up to down. The magic solution was column-count: 2; Resolving this was a win on its own! (Click for the JSFiddle for illustration.)

The two lists were even longer than with the tags though, so we decided to separate these fields into it’s own page instead of shoving it into a form with 4–5 more items. This gave us the chance to monitor the new feature and it’s usage more carefully.

Analyzing the result

After exposing half of our providers to the grouped and exposed list of tags vs the multi-select pill box I watched screen recordings to see how well accepted this solution was.

My perception was positive from the sessions I watched, people did scroll through the whole list but only 1.93% of them got stuck with on this page. I wanted to have some hard data on the number of tags picked (I wanted to see clear improvement) and the amount of time it took to complete the steps (I wanted to see decrease in time). Unfortunately, the experiment tool we use is developed to measure changes in the customer conversion funnel, and not at all optimized to measure changes in the usability of form in our admin area.

So I had to gather and analyze the data manually.

First I identified the listings created in the control group and the treatment.

For the control group (V0) I queried the seconds taken for each listing to proceed from Step 1 to Step 2 (step 1 contained the multi-select pill boxes), and the amount of tags picked.

The treatment group (V1) had the tag picking on a new step, in Step 2, so for them I had to query how many seconds it took them to get from Step 1 to Step 3, as well as the amount of tags picked.

I put them into a Google Sheet to start the analysis, and quickly did an AVERAGE on the numbers I got. And the result was surprising:

10000 seconds extra in average??? Almost 3 hours longer in the treatment group? That can’t be right. I’m not a business analyst but something came back from my college studies about statistics and removing outliers from data sets, so you don’t see the impact of — in this case — providers who left the process for a whole day and then returned.

So what’s the best way to remove outliers that Google Sheets can easily deal with? After some research I decided to use the TRIMMEAN function, which calculates the mean of a dataset excluding some proportion of data from the high and low ends of the dataset. In the calculation I excluded the top and bottom 20% to get a more real picture of the usage.

And the result was surprising!

The completion of the 2 steps combined in the treatment group was 33% faster then the one step in control group and there were 4 more tags picked in the new version of list. What a great improvement!

The conclusion

Design is contextual. It might be a simple task to pick your home country from a list of 195 items, even if you have to scroll for a while.

When it comes to unfamiliar items it’s better to visually expose the items instead of hiding them. It’s even better to do it in a logically organized way: create groups with meaningful titles, and let the users zoom in to the groups they are interested in.

With less cognitive load the task takes less time to complete and leaves the user with more energy to go through the whole process.

Improving the usability of multi-selecting from a long list was originally published in Tripaneer Techblog on Medium, where people are continuing the conversation by highlighting and responding to this story.

The responsive newsletter templates made it possible to display our content optimally on mobile devices, as well as making sure that it still can be read in long-standing desktop/webmail clients. A responsive email identifies the size of the device’s screen using a @media query and serves the styles determined for that screen size. Since most desktop and webmail clients don’t have this feature yet, we had to use a “desktop first” approach and modify it for mobile clients with support for @media queries. [2]

It’s pretty easy to find information about how the layout and the breakpoints of a responsive email should be built, generally by hiding content in the mobile layouts using something like this:

<style>
   @media only screen and (max-width: 480px) { 
        *[class~=hide_on_mobile] { display: none !important;}       
    }
</style>
<table>
    <tr>
        <td class="hide_on_mobile">Hide this content on mobile devices</td>
        <td>Show this content on all devices and clients</td>
    </tr>
</table>

How to show content on mobile but not on desktop?

What if we’d like to promote our app downloads on mobile or would like to show any other message that’s relevant to mobile only? How can we hide that on desktop?

The solution for hiding something on the desktop version and showing it only for mobile is not trivial. There are two email clients that often cause issues: Outlook and Gmail.

Outlook used to use the HTML rendering engine from Internet Explorer, but it changed to the MS Word engine in version 2007. Since then it has very limited support for CSS and HTML. For example, the CSS property display: none; can not be used in all types of elements effectively. Table cells can be hidden only if they don’t contain any other block or table elements. Simple layouts won’t have problems, but sometimes nested tables are the best way to display data and adding display: none; in Outlook just won’t work.

And frustratingly enough, Gmail ignores display:none; completely going so far as to remove this property from the source code. This we can overcome by adding!important to the declaration, but since CSS for email needs to be inline it cannot be later overridden.

Hiding content in Outlook

Elliot Ross, at Email Design Review, suggested adding a special class only for Outlook users and applying that for the elements to hide. Obviously in Outlook this isn’t going to work. But it does work if we add the conditional comments around the actual elements like so:

<style>
@media only screen and (max-width: 480px) { 
    *[class~=hideonmobile] { display: none !important;}       
}
</style>

<table>
    <tr>
        <td class="hideonmobile">Hide this content on mobile devices</td>
        <!--[if !mso]><!-->
        <td>Show this content on all devices and clients, except Outlook</td>
        <!--<![endif]-->
    </tr>
</table>

The solution was tested from Outlook 2003 to 2013, including 2011 on Mac, and all content between the tags shown above did not appear.

Hiding content in Gmail

Gmail’s treatment of display:none; means that we needed to find another solution to only show the right content. Here is the magic CSS we found that works the best:

width: 0; max-height: 0; overflow: hidden; float: left;

added inline:

<table>
    <tr>
        <td class="hideonmobile">Hide this content on mobile devices</td>
        <!--[if !mso]><!-->
        <td style="width: 0; max-height: 0; overflow: hidden; float: left;">
            This content won't show up on Outlook and Gmail (and some other more clients)
        </td>
        <!--<![endif]-->
    </tr>
</table>

Setting the width and max-height to 0 is important here. Without these properties the content disappears, but the empty area which has the same size as the hidden item will be still visible. This solution works in most clients and with adding display: none to it we can make sure that all clients hide our content.

Showing hidden content in mobile devices

Since @media queries and embedded styles work on native mobile email clients we can undo all of our previous CSS by overriding all of the applied properties:

*[class~=show_on_mobile] {
    display : block !important;
    width : auto !important;
    max-height: inherit !important;
    overflow : visible !important;
    float : none !important;
}

Displaying on mobile and desktop with the exact same document is almost complete, just needs to be put together.

Hiding content in desktop version of a responsive email

First, set up the @media query for the mobile clients to show the needed elements.

<style>
@media only screen and (max-width: 480px) { 
    *[class~=hide_on_mobile] { display: none !important;}       
    *[class~=show_on_mobile] {
        display : block !important;
        width : auto !important;
        max-height: inherit !important;
        overflow : visible !important;
        float : none !important;
    }
</style>

And lastly, add the necessary code to our elements to be hidden in desktop version.

<table>
    <tr>
        <td class="hide_on_mobile">Hide this content on mobile devices</td>
        <!--[if !mso]><!-->
        <td class="show_on_mobile"
            style="width: 0;
                max-height: 0;
                overflow: hidden;
                float: left;
                display: none;">
            Show this content only on mobile devices
        </td>
        <!--<![endif]-->
        <td>Show this element in all emails</td>
    </tr>
</table>

The final result means having greater flexibility to create better, more appropriate emails for our users without creating individual campaigns for each platform. We can save a lot of time and effort by focusing on creating more relevant content for all of our users instead of worrying about the logistics of individual campaigns.

[1] When talking about mobile devices, we refer to the native email clients listed on Campaign Monitor’s Mobile Email Guide
[2] Unfortunately Gmail Android App doesn’t support @media queries.

Originally published on Booking.com’s tech blog in August 2013.
Want to work with us? Check out www.workingatbooking.com

Responsive email was originally published in Booking.com — UX Design on Medium, where people are continuing the conversation by highlighting and responding to this story.