The scope & the team
Lifestyle magazine Sport360.fit mainly speaks to the women of Dubai. Its parent company already had a successful sports magazine read mostly by men. However, they realized a lot of women read their health and fitness related content, so they decided to create a separate product for them.
In October 2017 we partnered with Sport360.fit for a three-month project to design a responsive website and companion mobile application. Among Dubai magazines to this day, only they rely on influencer content, while in the app, users can contact influencers for advice, tips etc.
At UX Studio, we mostly work in pairs: a designer and a researcher. This vast project had a tight schedule, so we worked in a bigger UX team: four designers and four researchers. We also collaborated with a large team from the client in Dubai and their developers in Spain.
This UX case study will walk through all the challenges and learnings this project presented.
Before diving into the challenges, let’s start with a quick run-down of our UX design process. Two of us flew to Dubai for a two-day kick-off meeting. There we mapped out the project scope and potential fears, and gathered some knowledge about the market and the target audience.
Back home, we built up the information architecture and held several brainstorming workshops. After making the web and mobile prototypes, we designed the detailed UI – continuously testing them with users in both phases week by week.
1) Cultural differences
So why mention cultural differences in a UX case study? Actually, they posed one of the most exciting challenges from a design perspective. Since we mainly focused on the Arab market, we had to design all the screens in both English and Arabic when it came to the detailed UI.
Arabic user interface
Designing the Arabic version meant more than just changing copy. We also had to heed cultural peculiarities such as mirroring the interface (Arabic reads from right to left).
Some of us had already worked on Arabic projects before, so we had some experience on what UI elements to mirror and what to leave in their original form. When facing difficulties, the following resources helped us a great deal:
- Google’s Material Design Guidelines on bidirectionality
- Arabic apps / websites as reference
- Feedback from usability tests
And if we still remained completely lost, we luckily had the option of asking the client.
For a bilingual website, we assumed users would find the language selector quicker if we used flags. We chose wrong. User tests showed that some people found that offensive, as many countries use the Arabic language and one particular flag would not identify it.
So, we dropped the flags in the next iteration. Since we used only two languages, we got rid of the dropdown too. In the new version, clicking on the shortened written name of the target language would switch languages. The next usability testing sessions proved it a great solution because the users understood it very well.
In the English UI, we used some extra character spacing on some of the elements to make them more readable and more easily differentiated from other elements.
When we translated the UI to Arabic, we kept the character spacing. That distorted the font and caused readability issues.
In Arabic, each letter has multiple shapes, depending on context. To get scientific about it: “When adjusting intra-word spaces (i.e. the space inside the words) only these spaces can be adjusted.” – W3C Text Layout Requirements for the Arabic Script
Luckily, the Sketch app has a unique bug which handles extra character spacing in a right-to-left font: It simply fails to show some of the letters. That meant we always knew if we forgot to remove the character spacing.
2) Remote communication
Remote communication never comes easy but we have a method that works most of the time. We travel to the client for kick-off, then return to our office and continue communication remotely during the weekly meetings – usually Mondays. This time, though, it went a bit differently.
This short project (considering the amount of work) with strict deadlines required continuous communication, meaning one weekly meeting simply did not suffice. To avoid four-hour conversations every Monday, we sent out daily summaries via email and had a short 15-minute Skype call every day to speed up decision-making and reviews.
On top of that, the client gave us detailed feedback in a structured, color-coded Google spreadsheet, so our primary communication about design and features all happened in written form.
At first, this solution seemed overwhelming, but we had to admit that it went quickly, sped up the weekly meetings, and eliminated confusion about who said what on which Skype call.
Communication with the developers
Since the client’s developers worked in Spain, we had to make sure to create proper specifications to speed up remote work. Beside several Skype calls and emails, we left many comments in the Zeplin project and also created an extensive kit with all the basic UI elements’ different states (hover, active, inactive, etc.) and styles.
We also felt the need to create animations on how some of the micro interactions should work. Doing so came in very handy when it came to describing our ideas.
3) Big design team
During this project, we worked with a huge project team. We at UX Studio mostly work in pairs on projects, one designer and one researcher. Because of the tight project schedule, however, we worked in a huge UX team of eight, four designers and four researchers. Added to that, we kept in constant communication with both the client in Dubai and the developers in Spain. In this part of this UX case study, we will list the three main challenges we faced with these arrangements.
In the beginning of the project, we made a schedule ensuring that no designer would work on the same screen at the same time. So one week, designer A worked on the article pages, then the next week designer B worked on the article pages on a different platform.
Since we made the assets easily scalable and reusable, designing a finished page on a different platform went much faster than having to design each screen at the same time for different platforms.
Whenever we had questions, concerns or little problems, of course, we communicated on Slack. We even sat next to each other in the office, creating a little island, in case something came up.
This also helped us in the earlier phases in the project where we had to set up the information architecture and plan the first iteration of screens.
We usually do sketching workshops where we invite other designers from the office to ideate about a problem on a project. In this case we didn’t need to because we already formed a team of four. Every ideation session went like a workshop, so we came up with a lot of ideas in a small amount of time.
We used Axure’s team project feature for prototyping. Since we set up a sturdy project schedule in the beginning, the whole process went smoothly, apart from some minor glitches. Two designers worked on the desktop version and two on the mobile app.
The big design team definitely helped in the earlier phases, but then we reached the detailed UI phase. 😱
We had a meeting about what to use, Sketch or Figma. We collected pros and cons for each and tried to evaluate which would work better:
- Figma – great for collaboration, but new to us, and we dreaded slowing down our process a bit too much. Plus, Figma didn’t have Zeplin import back then, and we didn’t know how the client would react to yet another software change (we had worked on a different project with them before where we persuaded them to use Sketch+Zeplin instead of Photoshop).
- Sketch – libraries had just come out at that time, so we wanted to try them. We had also already gotten comfortable with it, so we knew it wouldn’t slow down our process.
So, in the end, we opted for the solution which would assure a smoother and quicker process instead of a better tool for collaboration. Looking back, we might have chosen wrong.
We set up Sketch with two layers of libraries. One basic library held atoms/molecules such as icons, buttons and any elements to use for all the platforms. Then we created three platform-specific others using the first as a base for web responsive, web mobile and for the mobile app.
We stored them in the cloud using Box because only this solution let us lock files, so we wouldn’t end up messing with the library while someone else was editing it. It worked but probably not the best by far – especially knowing how Figma handles everything.
4) Content types
The platform has many mix-and-matchable content types: articles, videos, slideshows and photo-galleries. While we could easily put a video in an article or make an in-text photogallery, we had more complicated content types as well.
The slideshow containing a whole photo-gallery on one slide caused us the most headaches, e.g. more complicated exercises had to be explained with a series of photos.
Check out this example of the structure of workout plan slideshows:
We started with the simplest solution and worked our way to the end result:
Version 1The gallery on the slideshow page looks exactly like the regular gallery, except here, little squares indicate slide switching. This solution didn’t work because users did not know if the indicator navigated the gallery or the slideshow.
To see the photos in the gallery, users have to open it in a popup. Navigation buttons came at the end of the article text. This version didn’t work either, because users did not find the buttons if the text under the slideshow stretched longer than the screen.
We made slideshow navigation buttons sticky at the bottom of the screen. Users could finally navigate properly on the page but the client insisted it took up too much screen, so we had to drop the sticky buttons and come up with a compromise.
We combined the first and the second solutions, placing small photos to indicate a gallery and moving the buttons up right above the slide title. Luckily, it resulted in a good enough compromise because users could still navigate through the pages
Look and feel
Since the site mainly targeted women, the client wanted to go for a light, friendly (even a little cute), fresh-yet-traditional look and feel. We created four different versions of the home page to show our ideas, then had a workshop with the client to get feedback.
After they told us which UI elements they liked from each version, we combined them to create the final version.
We pinpointed some steps in the user journeys where people experienced outbursts of emotions – such as excitement or frustration at the end of the influencer application process or when seeing error states.
We wanted the applications to reflect these emotional states. In harmony with our look and feel, we created some cute illustrations to make people smile or to lower their stress level.
So, what main takeaways came from this UX case study?
1. Always test with the right target audience
In most UX projects this goes without saying, but here it gained even more importance. Having limited knowledge about the culture and the market, our target audience gave us crucial insights which we wouldn’t have gotten otherwise.
2. Create a precise schedule for a short-term project
Plan out every team members’ task day-by-day if needed. This avoids two designers working on the same screens simultaneously. Plan so designers can use each other’s assets and screens to speed up collaboration.
3. Keep flexible in collaboration
We all have our preferred working and communicating methods, but if the client wants to introduce something else, don’t say no right away. Start using it, test it, see if it works. You never know, you might end up with a method you’ll love later on.
4. Don’t fear trying out new tools
Implementing new tools during a live project can overwhelm, but you don’t always have the time to try them out beforehand. If you have an inkling that another tool might work better, use it and avoid the infinite loop of “coulda-shoulda-woulda”.
5. Pay attention to details
Create a user journey and identify points to introduce little delights (illustrations, feedback screens). Forming a personality for a product is not only fun, but it will engage your users in a whole different way.
This process didn’t end that long ago. The Sport360.fit product has already gone live but still finds itself in the early stages. Check it out here.
We hope you enjoyed our UX case study!
Any thoughts, tips or ideas? Don’t leave without letting us know in the comment section! 😉
For additional reading, download our free ebook for product managers to understand our main processes better.
And did you know we also wrote a whole book about UX? Yes, we did! Check out our Product Design Book – now with free worldwide shipping!
Want to read more case studies? Here are a few that you might like:
- Organizing 100+ pages into a usable menu structure – Danubius Hotels UX Case Study
- How we designed an online fashion store? – Société Store UX Case Study
- How We Built A Mobile MVP – Wattler UX Case Study