Case Studies

I am a principal-level UX designer, which is awesome because I love being involved in projects from the very start to finish.

I just love all areas of UX design, from talking to real people about their problems, to being creative and using problem solving skills to come up with dozens of ideas, to implementing them with my visual design skills.

In the following case studies I try to explain the process behind four projects from somewhat different areas of design: a web application, design system specialist, physical product and a marketing website. I hope to highlight that product design is about design thinking methods in whatever the medium or sector. It's about discovering problems and then solutions to those problems while staying grounded to business and tech requirements.


1 · User Centered Design in the Re-imagination of the Hibernia College VLE 2 · Design system upgrade for ESW (eShop World) 3 · Town Tales game: Game design with a product design approach 4 · Accent Solutions: Using product design thinking in a web design project

1 · User Centered Design in the Re-imagination of the Hibernia College VLE

Introduction

One of the biggest projects I ever worked on. Hibernia College has had an ancient VLE (Virtual Learning Environment) with some parts of it older than 10 years. User experience is far from ideal, with confusing information architecture, a lot of cross-page linking and user journeys that go really deep. Not to mention the crucial mismatch of the real-world Academic Programme and the structure of the learning content inside the VLE.

I believe that we did brilliant work on improving the user experience within constraints of our CMS - Moodle. Too see what role I played in this project, please read on.

Strategy

Hibernia College brought me in as a UX/UI designer, counting on my creativity and meticulous use of Design Thinking process and methods. Over the years I have developed my own hybrid process, something between the 4 stage Double Diamond and the Gamestorming 'Open > Explore > Close' methodologies. I usually divide my design projects into 3 phases: Research & analysis, Ideate and Testing & prototyping. I also always start with an Initialization phase or Strategy, as well as a Finalize phase for developer handoff.

In this strategy phase, I work with my stakeholders or team members on predicting some timelines, methods and activities that we could do and just kicking the project off.

Research & Analysis

Heuristic analysis

First I had to analyze the current situation. But in order not to make educated guesses and leave thing to my intuition, I made a checklist of common UX/UI patterns and ticked them off by going over the VLE system. Some things were immediately clear to me, like the lack of breadcrumbs, deep and nested information architecture but with a mismatch to the actual Academic Programme of the College. The image here shows the old system and its UI. Time is cruel, isn't it. :)

User interviews/observations

Then I talked to a dozen students of the college via Zoom. I made some preparations with a checklist of questions, some possible flows to predict where the conversations might go. This obviously falls through when the interview starts, but it did come in handy. I gave the students some tasks to perform in the app, first just as if it was a regular day for them, and them some specific tasks to check my findings from the Heuristic analysis. The observations as always proved to be immensely useful, as I gained a lot of insight into how they use the platform and what do they expect it to do. It was time to move on after I started seeing patterns in their explanations and behaviors.

Matomo analytics

I wanted to see if we could learn something from the Matomo analytics installed on our system. Analytics apps can be tricky to get a grip of, but indeed, Matomo showed me that users spend most of the time in one of 3 places > Calendar, Studying content pages and Assessments. This was important insight as I believed this is a north star for our information architecture and navigation.

Mental model

To help my colleagues and stakeholders, as well as myself, I created a mental model of various places and activities the students use in the app.

Once again, this is really helpful when starting to think about the information architecture.

User flows

I also made some 'as-is' user flows to show how the task flows were very long and with lots of confusing nodes - opportunities to get lost in the system. We needed to simplify this and make it more streamlined.

Shown in the image is just one of these flows for all of our locations in the system.

Ideation

Information architecture

It was time to sort out our information architecture. This was arguably the worst part of the old system, and I knew that with the deep nesting of all the academic content this needed to be very clear and logical. Although because of the constraints of Moodle, we couldn't change this too much, I still wanted our developers to hide some unneccessary views and pages that come out of the box with Moodle.

Wireframes

Now it was time to start sketching the wireframes. And also use Figma to make some quick, more detailed ones. The first thing I went about was to implement a simple, straightforward navigation menu, in which I obviously put all the most important locations where the users spend most time. Everything else flows from these points.

New locations and features

As I said, we made some completely new locations for users inside the IA/flows. We added the completely new 'Study Now' page that serves as the home page. It shows all the modules that students' programmes consist of, thus reinforcing the match between the real world and our design. This didn't exist before, and I think it's the first time someone put this into a Moodle app.

Inside a learning module, we separated the learning content from all the additional tools, resources and assessments, that we put on top into the so called 'Module Hub'. We also presented the lessons as tabbed pages, to have the learning content in one page and represent the progress and passage of time. We also streamlined the calendar.

New icons

Moodle originally has tons of different icons, but from the students' point of view they don't care if something is a SCORM package or a Database. They care about the type of activity they would be having to perform. So we made new icons, more modern and flat and also combined all the activities from 15 types of icons into 5-7.

UI ideation

Just to illustrate, there were a lot ideas and playing with the very color scheme of our new system, choosing from all of our brand colors. But in the end we went with our primary blue colors, just a little lighter and fresher.

All in all, I believe my team and I did a fantastic job on re-designing the College VLE. All the testing with old and new students, our staff proved that people were amazed with how easy to use the system was. Things were easy to find, you could navigate to anywhere in a breeze, and it looked fresh and modern.

We presented our work at the Moodlemoot UK 2021 conference and we got equally positive feedback, all from the professionals who use and develop Moodle apps all year long. Well done team at Hibernia!

On to the next project!

2 · Design system upgrade for ESW (eShop World)

Introduction

After working closely with design systems but only as a contributor, this was my first time as a fully pledged Design System specialist.

ESW is a world leader in DTC E-commerce, which means they take care of clients' Checkout process on their own websites. They also have a few other products: the full E-Commerce solution, the backdoor admin dashboard etc. For all of these they've been using two design system libraries, as well as a basic, third one. They were working on merging all of their design libraries into one, and my job was to make this transition smooth by analysing differences between the design systems, improving their structure and organization as well as the components themselves according to UX/UI best practices and using modern Figma features.

Strategy

I always try to start my projects with a plan. First, the client didn't know exactly what was needed to make the merger and improvements happen, but also to have a framework of reference for myself. I also wasn't sure of the scope of the project, which depends on the actual states of ESW design systems - number of components, quality of components both conceptually as well as how well the Figma components were built. So the first step was to make an audit of our design systems, and redefine the plan afterwards. I also knew I would definitely have to help designers by reviewing the components for UX/UI best practices and then create advanced, responsive components with auto-layout in Figma, and then finally implement all of this as a new component intake process.

Research

UI and design system preliminary audit

First I needed to take a look at what I was dealing with. Challenge was that there was a ton of components, spread across two different but similar design system libraries - all with sligthly different names, behaviors etc. The initial audit was relatively simple, count the components and their variants, check interaction states, UI stack states and similar basic properties. Oh and yes, the quality of Figma components.

Here's a table for one of the design systems, which gave me a pretty good overview of how long the upgrades would take.

User Interviews

In a sense, our own designers are primary users of the design system, because they are using it in their day-to-day work to create new features. That's why it was important for me to talk to them and see what they think about the design system, if they have any problems using it. As it turns out, the design system was fairly organized, with minor inconsistencies in naming conventions. The biggest problem was that Figma components were not built using best practices and advanced auto-layout features, so they weren't very user friendly. On top of that, the teams didn't really have a framework in place for the intake of new components into the design system as well as developers' roadmap. Alright, all of this was quite expected but it was nice to validate these problems.

UX/UI Best practices

Actual users of ESW products were the ones who were actually interacting with the components - so the customers. I wanted to perform an in-depth analysis of each of the components. Yes, a big task, but since we were merging the systems and developing from scratch, it was a really good time to improve the components. I trusted our UX designers to do their own research based on context of use, so I oriented my review on best practices - both general UX/UI and component-specific stuff.

To be honest, this was the scariest part for me. While yes, I have a lot of experience as a product designer, it is a different thing to tackle ins and outs of so many components. There were so many of them, and there are so many things to watch out for. I knew in order to fight this beast, I would definitely need to come up with some kind of a framework to guide me on this journey.

Ideation

Not neccessarily a real Ideation phase (it's important not to constrain myself with naming conventions), but the next step was to ideate a research and improvements process for all of our components. I first wanted to create a framework for myself. I've been seeing checklists for design systems online for years, so it was time to create something a bit more specific for ESW.

Starting with foundations - like colors

I had to start from the essence; the foundations (colors, typography, layout etc.). Here's an example of what came out of the analysis of colors. We didn't even have fully developed color palettes for most of the colors, and the range of darkest to lightest was quite low. I decided to fix both of those things to create future-proof palettes that we could use for any upcoming components. Some interesting tech requirements were that our developers are using Sass formulas to mix the colors - from a base color provided by clients, they could create a whole palette by adding black to get dark shades, or white to get light tints. That's why I used the same formula in Figma - even though this is not the ideal thing, especially for yellows. Always rotate your hues like a real painter! :)

Components detailed analysis framework

After improving the foundations, back to my research and ideation framework. I needed to create something like a checklist of questions I run each of the components through, so it's less guesswork and more consistent. I usually use Figma for dirty, messy research where I can put all of the screenshots, thoughts and quick ideas and have all of that at my glance. Here's an example page for one of the components. So the idea was to have a process like first research all of our ESW design and Storybook libraries and gain insights about structure and behavior of our components. Then do the literature review, some main resources such as the Nielsen Norman group, UX stack exchange and finally random internet search - also to find UX/UI best practices for that component. Then as a final step, check some of the main design system libraries out there - Material, Carbon, Lightning, Tailwind etc. and also learn as much as possible and apply to our components.

After doing the research, this would be a perfect opportunity to collaborate with designers and make improvements to our components, test them in our designs and then finalize each component upgrade by creating advanced Figma components and summarizing the component features for developers.

This was obviously a massive undertaking that lasted for a few months. I am enormously greateful for this opportunity because I learned so much about individual components and this was perfect for elevating my skills as a Product designer.

Not to mention it was really rewarding to use my Figma skill to create super advanced, responsive components with lots of variants - all to be more easily used by our designers.

New components intake process

It was also a good idea to implement some kind of a 'new component intake process'. After talking to our both our design team and UI development team, we came up with this general flow. When there is a feature request which gets its own Jira ticket, if designers create a new component, then also create a subticket for the Design system specialist (me), and once this whole research and improvements process is done, the subticket is closed and the designer can finish off their ticket. Then the component goes to the UI dev team for production.

Improved organization in Figma

A big part of this whole process was to actually create new Figma components, better organized and following the best Figma practices using auto-layout, nested subcomponents and plenty of variants. Here's an example of the old text input as well as the new text inputs.

Advanced Figma components

And here's a comparison of what was possible before the redesign (left image), and after the improvement. More logic to the variant properties, more properties in totall and a much more robust and user-friendly component, ready to be used by our designers.

Oh, and the circles are placeholder icons, ready to be swapped for any icon in our design system. ;)

Finalizing with guidelines

Little by little, once we would review and improve one of the components, I created some guidelines documentation to go along with the components. Each Figma page got a small 'How to use' tutorial, as well as full Guidelines and Requirements pages in Confluence, mostly to be used by our developers.

Phew, such a massive undertaking in redesigning two design systems and merging them into one. I learned a lot about the UX/UI best practices for most of the components that exist out there, I learned to trust myself and build a roadmap/framework/process, but not be afraid to iterate on it when things become difficult.

And equally as important, we've improved our components both for end customers, designers and developers alike.

3 · Product design of a sightseeing game

Introduction

This was a really dear personal project of mine. I wanted to make an inspirational and delightful game for travellers who visit my home town of Zagreb, Croatia.

I grew up here, I know every corner of Zagreb, so I wanted to share what would be a cool route to visit. But with a twist! The game is full of challenges that throw you into all kinds of unforgettable and unsuspected situations, where you meet people, learn about traditions, help others and most importantly have fun.

It would be my take on solving all those times when instead of having the time of your life, you are just feeling low-energy and don't know what to do.

Town Tales to the rescue!

Strategy

Concept & Idea

OK, so I've had this idea for a long time - to make some kind of a mix of a tour and game for sightseeing. We all love travelling, but if we try to remember the best times of our lives, usually it was some kind of a spontaneous adventure, an event where we met some strangers, did some fun things for a while and that's it. So I wanted to recreate that, no more boring sightseeing where every building is the same, but where we aspire for more adventure with challenges that take tourists around my hometown of Zagreb.

Plan

Since this is a somewhat older project, my process back then followed the more usual Double Diamond 4-phase process: Strategy, Discovery, Design and Build sequences. I would first have to validate my ideas by talking to tourists in Zagreb, then see if any new opportunities for solving their problems arise, and then design a prototype, play-test it and proceed to final designs.

Product Requirements

I knew my game had to be small, in a box that tourists could carry home. Nothing big, nothing fancy. Pure experience. Since this was a personal project of mine, that meant the budget was rather limited. That was okay, product that I had in mind was something like a small deck of cards with a map. Either way, it was time to go out and actually ask tourists what they really feel about Zagreb and what are some of their challenges.

Discovery Phase

User Research

I went out to the streets of Zagreb and started asking tourists some questions. General questions about traveling - what are they hoping for? What do they fear? Some specific questions - what they like about Zagreb, what they dislike about Zagreb. And so on. Based on their answers, I made some User Affinity Maps

These divide all the tourists into several categories like: Solo male traveler, solo female traveler, a couple, group of friends and elderly people. They all have different challenges and hopes when they travel. The most significat finding that also validated my thoughts was that they all love to do some mild sightseeing, walking around, learning a little about history, but as little as possible and that they all sometimes feel like they just didn't experience and learn about true local customs and people. I was onto something!

Design

Turning Problems into Solutions

I took all the insights about tourists’ challenges and wishes, and started brainstorming how to turn those into solutions and features of the game. For example, people usually want to meet locals but find that somewhat difficult to do, so the game will consist of challenges that will encourage them to do so. They actually want to find out as little as possible about all the landmarks - so my challenges will be always somehow connected to a landmark where they will be played, so players can remember the fun acticity with the landmark. In the end, I divided the cards into 5 categories: Landmarks, Learn, Contribute, Fun and Special Cards. I figured if I want to help make the world a better place, it's best to start with my own products that promote good actions and thoughts.

Prototype & Testing

Friends to the rescue

Next was making hand-drawn simple cards with proposed challenges and testing them with my friends in the city. I wanted to make sure there was a right amount of challenges of every type: scary, mild, physical, conversational etc. Thankfully my friends were here for me so it was much easier to test the game a few times. My friend Nina learning to tie a Croatian invention - the tie, from the master.

Build Phase

The essential part of the game design were the illustrations - they needed to be joyful, cartoony and inspiring. Here is a part of my sketches.

And some finished cartoony illustrations, with vibrant colors and joyful character.

Final Designs and Print

From all the layouts I sketched in the Design phase, I chose one that made most sense to me and proceeded to make the final visual designs. I sent all the cards to the printer and one final thing was to check the colors of our demo prints.

Finished Product

And here is a finished delightful box with a lovely adventure game inside.

Thanks for reading!

4 · Accent Solutions

Introduction

I was approached by Accent Solutions, one of the leading Property Management agencies in Ireland. They wanted a totally new, fresh website.

They just recently updated the look and feel of their even more ancient-looking website, but besides visual design, all the content, user flow and storytelling remained the same. In short, they needed a whole UX rehaul. They complained that they almost never received inquiries from visitors on the website, so they were wondering what might be wrong with their previous websites.

Strategy

As always, I divide my UX projects into 3 phases; Research & analysis, Ideation and Testing & prototyping. Then I go to UI work which follows the same phases, but usually much more stramlined and linear. Things overlap and I always need to go back and forth, but at least I have a structure of the project down so that makes things easier.

Accent's first and foremost goal was not only to make the website look more modern and professional, but also to try to see why visitors weren't contacting with them. They also wanted to present themselves as a modern, sleek company through their website's design.

Research & Analysis

Heuristic Analysis

From looking at Accent's both the ancient website as well as the new polished one, a few things were super clear to me at once. First, the website only talks about them, the Accent Solutions. It's 'me', 'me', 'me'. There is nothing about the users and their problems. In relation to that, there is no story or flow to the website. It just starts naming their services, along with some random, technical, 'inspiring' sentences. That actually don't mean anything. Also there are obvious bugs like the navigation not showing as soon as you start scrolling. Okay, writing all of this down.

Next, stakeholder interviews!.

Stakeholder Interviews

Talking to my clients, I told them about my observations, and they couldn't agree more. They did feel like their website was too impersonal, as if they should talk more about how their services help users. And obviously they really wanted a sleeker look, because they fear the previous websites make them look cheap and unprofessional. During this meeting they also mentioned that they would really love to have one subpage dedicated to various resources their clients might need, for example, some of their clients are hospitals and they participate in an energy savings competition. From time to time they want to showcase their results on TV screens throughout the hospital, so it would be really handy if they could just type in the url of Accent's website where the data is fresh and updated. That would be a nice touch.

Target Audience

Accent's website visitors are mainly from the private sector. They do have clients that come to them through the OPW, but most of the new clients are owners of companies and large properties that need to be managed.

Ideation

Now it's time to take everything I learned from my client, all their needs, wishes and problems, and turn them into something tangible. Hopefully a smart website with a decent story that will intrigue users, showcase Accent's solutions and then invite users to click and contact them.

Information Architecture

Since this a relatively simple website, constructing the sitemap was rather simple. Some things worth jotting down are that the main page is a long page. Of course, I think it would be easiest to put the new Resources page really visible on the Main Page, so that their clients can find the presentations and data they need without remembering the exact url.

Story Flow

Okay, so there were some obvious problems with their old websites, namely that they were talking only about themselves and also there was no flow to getting the users' attention, and then leading them to engage the call of action systems. That's why I sketched this flow:

I believe that the hero/heading should capture the attention and spark interest in the users. Old websites definitely lacked this quality. Next, we should have a flow of building their interest, first by getting them to self-identify with some of the problems we discovered in the research phase. We want to touch their emotions and get them involved. Next up, we take them further down the journey where users should now ask themselves if this really works, and how? We showcase some examples with social proof or real data. That's why here we use some of the succeses Accent's clients have achieved over the years. We want users to want the same for themselves! And then we tell them about our solutions to their problems, and those are our services. It would be best to name only a few so they don't get overwhelmed and explain briefly how each of these services will improve their lives. They can find out more details in the Services subpage. Immediately after that comes the call-to-action, in this case a fill-in form where users can address their problems and contact Accent. Voila! We have a nice flow that will take users from being interested, to self-identify with these same problems that Accent has so conveniently been solving for other users for years, and they will want to sign up.

Wireframes

Then it was time to make some actual wireframes...

Prototypes & Testing

We tested continuously with the team and stakeholders, as well as with several of their clients. Since this isn't really an application, testing was relatively simple and mostly about seeing if the users can find various parts of the website.

On to the UI design!

UI design

UI Design

With the wireframes in place, now it was a matter of translating that into final, visual designs. I played a little with the main colors, I knew my client wanted their Green color to dominate, but I also tried some things with a bit more bluish-green color, with hopes it might look a bit more modern. After some iterations, we finally decided on the green design they liked, which I then applied to all of the subpages. To showcase what the webpage would look like on mobile devices, only the main page was enough to do that effectively.

And there you go folks, I believe we successfully used design thinking process and methods along with good old storytelling to capture the main problems our users had with the old website, and then through iteration we came up with some ideas for new, friendlier, more usable landing page which is a key to any good business.

Get in touch

If you'd like us to work together, please send me an email on the link below. Thanks for visiting!

Go to home page