Denes Hetenyi
Product Designer

Overview

Throughout 2017 and 2018 Vodafone Hungary has seen a complete makeover of its entire digital ecosystem, from all of its user-facing digital platforms through the related systems to the teams working with and on them. These presented a myriad of challenges within the company, some of which were our own digital design related ones. This writing, more like a Medium article than an actual case study, aims to present you with these challenges and how I and we answered them.

While I will be talking about one big redesign project, in reality this term covers a chain of projects linked closely together, but with two coherent major outcomes:

  • All digital platforms of Vodafone Hungary have been redesigned from the ground up: revised journeys, optimized user flows, and a unified look and feel;

  • User-centric design as a concept and the Design Team itself established its own place within Vodafone Hungary and the product development workflow. We became a team to which people started turning when they were looking for solutions.

And, as the Head of Digital Team put it afterwards to many of us, to convey how it also benefited us individually: "not much will be able to surprise you in your career after seeing through a project this complex in a business sector as complicated and as over-regulated as ours".

Contents

This writing is much longer than a usual case study. Throughout it you'll find some cross mentions, as it'd be almost impossible to present these thoughts in a completely linear fashion. That said, you'll find the contents grouped into the following segments (and please, feel free to skip ahead in case you're only interested in one part ☺):

Team challenges

Establishing an internal UX team

My manager brought me on board the Digital Team originally as the main internal designer for the redesign project. But only after a few weeks the need for more and more design work and our discussions about future of design in the company led us to see an opportunity: forming a Design Team within the Digital Team by riding the project's wave, with me as design lead. This presented me with a new challenge parallel with the already-huge redesign project, but it was also clear that one couldn't succeed without the other, and vice versa. I could break the new task ahead of me into three parts:

  • build a competent UX & UI design team and ensure their professional development;

  • develop future-proof design workflows riding the redesign project, workflows that integrate well into the forming agile processes;

  • introduce and advocate UX principles to Vodafone Hungary with the project, and advance the role of design itself in the company from simply producing outputs to achieving outcomes.

Summed up, me and my team had to convince through project results the marketing teams and the whole company that UX indeed brings something to the table, even in the future. I'm proud to say that over the years and as presented in this study, through constant improvement to our workflows, by delivering performant designs, and by bringing valuable user-based insights to projects, the above goals were fully met.

Agile transformation

Multi-year transformational mega-projects like our topic are usually a hybrid waterfall-agile structure. While the overall of the project was managed as waterfall, development was handled as an agile structure. This also marked the start of general agile transformation within the company, and our greater Digital Team spearheaded the change – our teams were to serve as the model for the transformation of other teams later on.

As mentioned above, this meant creating new workflows and forming squads, and integrating design into these processes wasn't self-evident. The first couple of configurations proved to be too rigid after a few sprints each – we needed flexibility. After reviewing the problems with our competent agile coach, we started working in one-week quasi-sprints, with weekly design reviews, which allowed two design cycles in one two-week sprint of the product squads. This meant one additional design iteration based on feedback coming from them mid-sprint, and more importantly an interim point where I could (and often did) reassign ourselves to the tasks needing more design resources. While looking back and written down like this, our solution might seem evident and simple, finding a way to integrate creative workflows with standardizable ones of other disciplines is never straightforward. The success of our new process was proven by the fact that this configuration stayed in place even after the project.

Technological aspects
Vodafone

Before continuing on to the design challenges, I'd like to take detour to show what happened 'under the hood'. While their impact on design is indirect, the changes were significant. Technological changes were actually the greatest part of the mega-project as a whole. The scope included changes to all of the systems running our digital platforms.

My Vodafone App

The "old" Vodafone App served mostly as a one-way dashboard for following data and talk/text status, with very limited interaction capabilities. The redesign project envisioned evolving it into a fully interactive self-service customer dashboard. This meant publishing the app as an entirely new product, as updating the then-existing application package was not an option. This move had its own risk, as a new user base had to be established from zero, and existing users had to be encouraged to switch to the new one which proved to be a pain point ("why are they bothering me with this?").

In order to get over this first hurdle the soonest possible, the initially released app package was decided to be the code-for-code replica of the Vodafone Group (see design challenges) generic MyVodafone Application, with features trimmed to local market needs and base user journeys. All further features and design changes were then released as frequent updates for the already growing user base.

Web ecosystem

Reducing the fragmentation of the initially complex web ecosystem of Vodafone Hungary was actually one of the main business drivers of the project.

Originally, static web content ran under a CMS, with two separate streams and two separate domains: one for desktop and on for non-responsive mobile content. This CMS also served as the platform for the customer self-service dashboard, linked to a large array of back-end systems from billing to subscription handling. E-commerce ran on two parallel, separate webshop systems.

With the transformation project, a new Liferay DXP CMS was chosen to operate the portal and the self-care branches (both responsive), with a unified code-base. Design-wise, this decision allowed for much more liberty, but has also brought the burdenful task of defining and coding every design element from the ground up. Also, the back-end connections and the data made available by them imposed design limits on many occasions, sometimes hindering good user experience.

E-commerce-wise, our managers succeeded in pushing through a decision we were backing: switching the (botched) 'new' webshop off. This enabled my team to focus our resources on redesigning the much more stable old system, to fit the UX and UI design framework already used for the CMS and the self-service – basically bringing it up to speed as the last piece of the puzzle.

Design research challenges

As mentioned above the project aimed to redesign and rebuild (see the technological aspect below) all user-facing digital platforms of Vodafone Hungary, which is a significant task, even when broken up into 'smaller' but still huge subprojects.

Diving into it

Tackling the design research for a task this big is not really self-evident – there aren't really any best practices for it. Our solution to get a hold on the project was to research and define 10 key journeys for the platforms (such as prepaid top-up, bill payment, or data add-on purchase for the self-service; roaming info search for the CMS; and subscription renewal with handset purchase for the e-commerce), and view the whole project through the perspective these journeys provided. Naturally, the journeys intertwined, which resulted in a tree-like structure.

But we couldn't just focus on our journeys: existing content and pages were essential too, for marketing, legal, or other purposes. Thus, we sifted through the more than 1200 existing individual URLs. We sorted out what we had already addressed in the previous step, and coordinated with the business owners of the rest in order to understand their place and the related user flows. As a result, we could place them as well on the above structure (a little like gluing leaves back on a tree), and eliminate a significant amount of individual pages by simple deletion, or by merging them together to create a more consistent page hierarchy. In the end, we succeeded in ending up with only around 300 individual URLs, many of which were just redirecting or parent URLs. The final sitemap and URL hierarchy was later organized around the page menu, discussed below.

To get a better view for the e-commerce redesign phase, I created an interaction map covering all possible user flows and conditions (which are plentiful in a complex environment such as this, offering an interlinked system allowing service and product purchase and the user's self-management of those services), with the above journeys as the backbone. This then served as a base blueprint to optimize user flows, and to design the interactions, screens and UI modules.

Establishing a proper design cycle

The previously described part of the project was more on the waterfall side of things, albeit with sprints leading forward through it. After the launch of the first redesign platform (the website) though, we were determined to follow design thinking principles and establish a feedback loop of measurement so we could improve those products based on the results. Due to the organizational structure we had limited testing possibilities and no separate budget – our only data source within the greater Digital Team was the quantitative metrics provided by our very competent Funnel Team. While quantitative aggregated results from Adobe Analytics and Hotjar are useful, they only allow for limited insight compared to qualitative data.

As a first step to overcome this, we managed to cooperate with the marketing research team in order to conduct joint research, and in some cases even usability research for some of the above-mentioned journeys that were now in the care of dedicated agile product squads. Later, as my team and our methods grew to be more and more accepted due to our effective results, with the significant help of our group manager we succeeded in securing a regular budget for a research contract with an external user research firm. This brought us into an position where we could conduct proper user research, get meaningful insights, and base our future designs on them.

One of the good examples of this was the restructuring of the website menu, which unfortunately we had to postpone until after the first platform launch anyways. But this delay eventually allowed us to conduct proper research. After short stakeholder interviews, analysis of click rates and page visits, and the review of key user journeys we were able to eliminate the unnecessary menu items – in cases, they were replaced with much more user friendly in-page navigation. The remaining menu items were ran through a closed card sorting test organized with the above mentioned budget, which in turn gave us the final structure.Site performance measurements later showed clear improvements: all menu items showed normal usage rates, back-click rates decreased, and and "click-all-the-menu-items-to-find-what-I-need" phenomenon basically disappeared.

UX & UI Design challenges

To put the design process into perspective for you, I need to take a small step backwards: the cooperation between Vodafone service providers of each country and also the parent company, Vodafone Group, is quite close, and also covers cooperation between respective teams. The Vodafone Group Design team is the key business owner of the Vodafone design that the local subsidiaries use. At the time of the redesign project, Vodafone's digital design "structure" was in its second generation – and one major aim of our project was to jump from the existing first generation design to the second one.

While these design system generations are discussed in detail in another case study, the important part here is that we didn't have to start designing with a blank canvas. Not only we had a brand design guide at our disposition, which is fairly common, but also a design library containing general UX patterns and a quasi-atomic design system of UI elements, up to page template level. Nevertheless, our work was very far from just copy-pasting and applying the existing library elements in our pages.

Applying generic design to specific products

The generic Group design library could not (and justifiably so) take into account the individual aspects of every Vodafone country and their specificities. There are no one-size-fits-all solutions in UX, especially across cultures and languages. In our case, this meant that it was our task to take templates and elements of the library, often even deconstruct them, and build the flows, interactions, and pages that we designed with them. It can be imagined like a lego kit: we did have the pieces, but the house we wanted to build was different from the one that can be done with the instructions in the kit.

Throughout the project, it was my responsibility that the final designs stay within the limits of the Vodafone brand UX and UI-wise, all while allowing to push these boundaries to their limits so we could end up with the best solutions possible in this space. In most cases where our needs differed from the provided pattern, the rearrangement of elements was enough – which is just the usual industry practice of applying a design language or design pattern to a new product.

The top-up module: one example of a snowflake (non-design-system) element. Driving factors were legal requirements, technical limitations, culture-specific aspects, and user research input.Above: original, below: country specific design

The top-up module: one example of a snowflake (non-design-system) element. Driving factors were legal requirements, technical limitations, culture-specific aspects, and user research input.
Above: original, below: country specific design

But in many instances, the only option was to design custom-made elements (which would be like 3D printing your own lego-compatible blocks for the house). Justifying the decision of where to create such elements, aka. snowflakes, or where to try and rather remodel our own UX pattern or UI component to match already existing library elements was also my team's task. Our principle here was pareto-efficiency. I surmised that by choosing to create only a handful but crucial custom elements (the rule of thumb was anything that had a main interactional role in that specific step), we could achieve a compromise: still be close to optimal user experience levels for the journeys, but keep the design library and the code-base simpler.

In rare cases, most of the more complex rulesets (such as templates and patterns) had to be entirely broken due business and product requirements, and only the wider but stricter design rules could be respected – the subscription management dashboard described in the next part is a perfect example. In the case of these super-snowflakes, the pattern was usually so complex and special that no existing flow or layout could be used. As a consequence, we had to create designs that enabled the best user experience for it – but this meant falling back to lower 'levels' of the design system and only using its base elements (cards, buttons) as the building blocks and creating entirely individual designs. While visually these solutions fit the Vodafone world, they provide a different layout and interaction model, and as such can lead to pain points. The example described in the next part even took this problematic situation to a whole new level, unfortunately. On the other hand, the next, third generation of the Vodafone design system later brought solutions to prevent having to make super-snowflakes like these in the future.

Design Reality Check

While design as a field is about finding ideal, or at least optimal solutions, business decisions and other limits oftentimes provide a hard reality check. Many times, a designer finds itself in a situation, where there are only suboptimal or poor solutions within the set limits. The key there is to make all stakeholders and decision makers aware of the exact trade-offs in user experience or in key metrics that these concessions will entail.

One screen of the Family bundle expansion mode of the subscription dashboard. Most buttons lead to multi-step interaction loops, since the checkout step next has to be started from here legally.The black summary bar is a floating element at the bottom of the viewport

One screen of the Family bundle expansion mode of the subscription dashboard. Most buttons lead to multi-step interaction loops, since the checkout step next has to be started from here legally.
The black summary bar is a floating element at the bottom of the viewport

When there is no wiggle room

One of the "super snowflakes" (mentioned above) where only the basic limits of the Vodafone design patterns could be respected was the Vodafone Family bundle expansion mode of the subscription dashboard. Without diving too much into details, the Family product offer had a discount logic that wasn't hard to explain in a human-to-human interaction, but incredibly difficult to represent on a digital channel. With its complex rule for calculating the discounts, it had around 13 million combination possibilities!

So the already complex base situation where a user expands its existing bundle on the dashboard was rendered more convoluted by this logic (the discount rule even modifies existing subscriptions). And on the top of it, users still had to be able to purchase devices for new subscriptions, and be able to upgrade or renew existing subscriptions, with all the info display and legal requirements that go with these.

From their side, Vodafone Group Design was resolute that the basic design limits should be respected: typography hierarchy, buttons, margins, etc. The design system was conceived to give a modern, airy feel and a high accessibility – and its limits made impossible any attempts to rebalance font sizes, reduce button sizes or paddings, or otherwise optimize the very crowded layout.

Modifying the Family product itself was categorically out of the question for that time. I tried to optimize the user flow, but all my attempts to break down the process into simpler steps and better interactions needed were rejected by the business stakeholders, despite showing them how complex the screens get and warning them how poorly the end product will probably perform.

All in all, after five full round of iterations and tests a "least bad" solution took shape. The design I delivered here is one that I feel very ambivalent about. I cherish it because it reminds me that it's possible to solve situations where there is no wiggle room whatsoever. But I despise it as well, because I had to rule out so many better solutions in the process and consequently I consider it one of my worst designs that got shipped. It just simply provides a bad user experience overall, and I still wish a better solution would have been possible.

But, all the work that went into this and other related compromises did not go to waste in the end. One one hand, my line manager and I convinced the stakeholders that the Family product and its discount logic should be rethought, and later our design team was the first that got invited to that table for the sake of making a digital-first new Family product. On the other hand, all the learnings were turned into feedback towards Vodafone Group who incorporated some of it in its design library and design system.