Case Studies

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

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 of ideas and playing with the 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)

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 · Dell Technologies - Reducing work rate by 50% in creation of Offers and Subscriptions

Strategy

Dell's Design playbook recommends using the following, rather usual take on the Design Thinking process: Empathize, Define, Ideate, Prototype and Test so that was no problem for me.

Design Process

To put this more accurately, since we worked in an Agile environment, we had broken up our work into several Features, and for each one we used the same iterative process. It's just important to keep in mind that all of the stages I describe were repeated in agile iterations, adding functionality on top of the core features.

Empathize

I actually joined this team a little after they had already kicked off the project and started with the discovery. This proved to be quite tricky because everyone else on the team had worked at Dell for years and they were all well versed in extensive business terminology and processes. For me it wasn't so simple to look at their artefacts and figure out the current state of the apps. What do you do when you get a bunch of these super-detailed, business and technical flowcharts and maps?

Ecosystem Map

This is an example of an artefact I had to study; an ecosystem map that shows the complexity of our project. I had to spend a lot of time digging through our corporate intranet and talking to stakeholders and teammates understanding all of this.

Multiple Apps

After doing several research sessions with our users and stakeholders, it was clear that the current state was that our users: pricing and cost authors, had to use multiple apps to input all of the various data. In some cases, they would get enormous excel sheets filled with prices, selectors and other information and they would have to manually copy and paste into these apps. Most of the time there were many people working on a single Rate Card, and they had to wait for each other's work to be done, review and approvedetails, communicate via Teams and all of this made the whole process tedious and slow. Main two apps were the PAC (Price Authoring Architecture) and PDC (Pricing Design Center). Just a few screenshots of several places that our users had to go and use to get the jobs done.

Define

This is the analysis phase, where I absolutely had to define the user journeys and problems to both myself and other stakeholders because I noticed the team was not aligned on what exactly needed to be done. Requirements were written in a very conceptual way.

The power of asking why and root problems analysis

In order to identify possible causes of our problems, in talking with users I applied a '5 Why's ' method, which I find very powerful especially paired with a Fishbone diagram. This combination is extremely powerful in revealing bottlenecks and areas of weakness in a process, and the diagram itself is inavaluable in presenting to team members and stakeholders.

User Journey - Current State

The best way to understand user journeys and get detailed information is by sketching out user journeys. Nothing fancy this time, just a flow of the main user steps which both helped my team and me come up with questions and then spark discussion with the stakeholders.

Ideate

It was finally time to brainstorm some solutions to all of the problems and needs uncovered in the Empathize and Define phases.

Wireframes

Since this project already had a North Star of combining the PAC and PDC apps into one, it made most sense to start brainstorming the layout and flows as wireframes. Although Dell Digital Design team has a well established design system library, we still started with low fidelity wireframes, just to quickly test ideas with the stakeholders and users, and then driving the designs up to high-fidelity wireframes that convey the look and feel of the app better, especially since many of the team were new to product design methods.

Prototypes & Testing

After multiple meetings and discussions about the wireframe flows, it was time to actually validate the best ideas with interactive prototypes. This is just one of many iterations – I like to show start to end journeys for users to really get a feel for how a solution works, which can mean my prototypes amount a large number of screens. I also love adding interactive states with Figma variant interactions. But I do think all the effort is worth it, especially when working with people who are not used to various design deliverables – they need something tangible like a prototype.

Finalize - Dev Handoff

Mockups with Notes

As a beginner front-end developer, I know what is useful for our devs - mockup flows with UX/UI annotations so they don't have to guess too much what's going on. I always make sure to include additional screens for all of the states of a particular feature, such as: Default, Empty, Loading, Success and Error states, as well as screens with detailed spacings shown.

Speeding up iterative work with mockupframes

As I mentioned, this was an Agile project with several sprints and iterations, where we built on top of core functionality by repeating all of the Design Thinking processes. What I found really speeds up the process is working with 'mockupframes', lo-fi wireframes with our design system styling – because the whole team is by now very familiar with what our designs and components look like, so it's quite easy to get your idea across and validate with the team and users.

By the time our MVP was developed and we had first users, we asked the users to self report and estimate if there was a reduction in time needed for creation of the Rate Cards. Both the users and stakeholders were thrilled wtih how we merged the two apps into one, and especially with added functionality such as batch uploading, commenting and reviewing features that really enabled the users to collaborate much faster.

4 · Product design of a sightseeing game

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!