How I completely redesigned my university app in three weeks

Elio Raineri
12 min readMay 7, 2021

With this article I would like to share my experience in redesigning the application of my university (Politecnico di Milano) as an exercise for a Design Studio. I think is important to clarify that I’m not a professional UX designer and the process presented is not necessarily correct, but it helped me a lot to achieve the final result. I hope that my experience could be helpful for other design students or people interested in the UX field.

First of all I want to thank my wonderful team: Elisa Manzoni, Fedele Cavaliere and Andrea De Bernardi that collaborated with me arriving to a result I am very proud of.

The Brief

Politecnico di Milano, in partnership with the design company Tangity, proposed the challenge to redesign the current application. The output should have taken in consideration all the functions already available, without adding more, but just giving a refresh to the UI, but most importantly improving and fixing the UX (the real pain point of the current app).

Just to provide context, the application was launched in 2014, based on the same architecture and UI of the online services of the university, available via web (Polimi web page). The flows are very hard to follow and the UI is kind of stuck to the early 2000s. Until today, it has received only few updates, all of them regarding the fix of stability issues and some minor updates.

Politecnico di Milano’s Online Services
Politecnico di Milano’s Online Services

Analysis — Our Strategy

To make the best work we could do, we defined from the beginning what would have been our redesign process. As designers we knew that, before starting immediately by thinking about the new UX and UI, we should have analysed the current one highlighting its features and pain points, and have a clear view about every aspect of it.

We decided to divide our analysis part in two macro activities:

  • Expert Evaluation;
  • User Analysis.

With the Expert Evaluation we aimed to deconstruct the app architecture and understand which Heuristic Laws (Jakob Nielsen, 1994) the application was breaking, in order to have a solid base where we could start to analyse the users behaviour through a User Analysis.

Expert Evaluation

As previously said, the first phase has been the Expert Evaluation, which aimed to define the main usability issues related to the architecture or to the UI.

Starting from an intense and individual use of all the functions, we did a sort of “reverse engineering” process to understand and draw the current architecture of the application. Each time a new page appeared, we took a screenshot, copying it and connecting all of them on a Figma board.

It is very helpful to visualise all the features inside the application, their flows, how they connect together and the overall style of it.

Example of Architecture Deconstruction on Figma

The application has 12 main functions which spans from the career overview, to the exams registration. The app should help the students to manage their university life without opening their online services through a computer. However we immediately noticed that the UX is very problematic: the flows are intricate and follow an horizontal development, making the user feel lost while navigating in the functions. It translates in a poor experience that makes the purpose of managing university related information in mobility vanish.

Once we discovered all the pages inside the application we started the so called “Heuristic Evaluation”, which consists in the analysis of all the screens in order to understand which of the 10 heuristic laws are not respected.

For the people who are not familiar with the concept of “Heuristic Laws”, they are, very shortly, 10 laws that should always be taken into consideration when designing a digital interface in order to give the best experience to the user. If you are interested in them, I suggest you to read this article. They are very easy, but also super useful for a UX designer.

  1. Visibility of system status;
  2. Match between the system and the real world;
  3. User control and freedom;
  4. Consistency and standards;
  5. Error prevention;
  6. Recognition rather than recall;
  7. Flexibility and efficiency of use;
  8. Aesthetic and minimalist design;
  9. Help users recognize, diagnose, and recover from errors;
  10. Help and documentation.

Going back to our analysis, we took every screen subjecting them to each of the 10 heuristic laws, in order to understand the issues the user could fall into.

Example of Heuristic Evaluation on the Study Plan function

For every broken rule we have defined the level of severity on a scale from 0 to 5, where 0 is not a problem and 5 is an issue that prevents the user to achieve his goal and should be fixed ASAP.

User Testing

The second phase we conducted has been the user testing, through which we wanted to have a confirmation of the output coming from the expert evaluation and, eventually, understand the user’s mental model that would have been useful in the redesign phase and more specifically in the design of the new architecture.

SURVEY

First of all we created a survey through which we wanted to gather quantitative information about the app usage, like the percentage of people who use the app, the motivations for the non-users, the most used features, and their satisfaction. Then we visualised the results with graphs easy to understand.

STRUCTURED INTERVIEW

User Testing

Before starting, we have created a protocol to follow during the tests. It is basically the script of what we should do during the time with the user, composed by an introduction where we explained what we were doing, the scenarios with task he should have done, and lastly some questions about the overall experience.

What we learnt is important during user testing, is to not ask for specific tasks, but try to make the user identify in a scenario and make him feeling like he was in the real situation.

For example: instead of asking to open the career section and look for the grade of a course, is better to ask: imagine to be in the middle of the exam session and some colleagues told you that the final grade of a course is finally available, how would you look for it?

It can seems stupid, or no-sense, but if we think about that, when a user uses an app, most of the times has a need that wants to fulfil instead of a specific path to follow. It is especially true if the system is new or he/she is in a rush and doesn’t have enough time to think about the flow.

For the test we have decided to use some tools that could give us some more insights, like the ECG and a custom developed software able to understand the user’s emotions through his facial micro-movements.

I won’t go in depth with the instrumental tools, but I will just explain the results of the user testings.

To analyse all the behaviour and the answers we collected everything on a single shared Excel file in order to have a clear view of all the results for each step (time of completion, actions, words etc.)

With a total of 6 users tested, we confirmed some of the issues emerged during the heuristic evaluation, like the information overload, the lack of a hierarchical order among the elements and the lack of affordance.

Outcomes

To sum-up all the outcomes and the process we followed during the analysis phase, we have created a detailed document which includes everything we have discovered and the detailed explanation of all the activities. It has been used as a proof of our statements that we presented to our clients (Politecnico di Milano and Tangity).

The Concept

As good designers do, the redesign phase started with the concept definition according to the outcomes of the analysis, the requirements of the users and finally, to the actual state of the art in the mobile applications field.

We based our UX concept on three main pillars:

  1. Customization:
    As it is now, the application is the same for every student, without considering the different needs and preferences. Being the career of each sudent different from the others, with customization we wanted to give a way to make the app feeling personal.
  2. Speed of use:
    The app should be a way to manage the main contents available on the online services, but in an easy way, mostly in mobility. Speed of use was fundamental to achieve this goal.
  3. Smart hierarchy:
    Differently from the current application, we wanted to give a weight to every function, making the most important easy to reach, enhancing the user experience and satisfaction.

The App Architecture

The first step towards the final information architecture has been a Card Sorting activity which consists in letting the users put the listed functions (the ones available in the app) together in some predefined categories in which they expect to find them.

Then, with the first version of the architecture, we tested it with a Tree Testing activity, which consists in asking the users to find a function, inside a nested hierarchy, in order to understand if the architecture matches the user’s mental model.

For both these tests we used an online tool called Maze. It is used for different kinds of user testing and gives aMAZEing (ok, that’s a bit cringe 😂) insights about what users do, their paths and failures.

For example: for the tree testing, it doesn’t give you just information about if the user was able to find the right path or not, but it also shows his path, so if he went straightforward to the solution, or if he did multiple attempts before arriving to the final solution, you will know it.

It is fundamental to understand, because it tells if the UX has to be fixed!

After the preliminary tests, we defined the final App Architecture with all the functions and information available in the application, linked together and cross-connected among the different categories.

Spending time to understand and design well the architecture is very important to create a consistent and easy to use app. A nice looking interface, without a good architecture is like a Ferrari with an engine of a Panda (we say it a lot in Italy), that for the user is translated in a bad experience.

Final App Architecture — All the functions and sub-functions

The wireframe

General wireframe

With all the architecture defined we moved on designing the wireframe.
The wireframe is useful as a first mobile prototype to test with the users and validate the app architecture once again, deciding also the grid and the overall position of the UI elements. Then we moved on creating all the pages of the architecture and the first mockup.

What we thought was very important is the homepage. Being the first page the user sees every time he opens the app, it should have been perfect and in our opinion, since from that screen he should already achieve some of his goals.

To follow the pillar of customization, we decided to introduce the widgets, one for each of the most important features in the application. With these UI elements the users can decide which information are more important, making the information easily reachable since the very first screen.

The widget element in one of the very first mockups

The final step of the prototyping phase has been the test. Despite some small issue that we fixed immediately later, the overall architecture was working very well and the users were able to reach the goals we asked for!

Maze is a very powerful tool and, despite the distance of user testing, we were able to understand the paths the users followed to achieve the tasks and their clicks on the mockup. It allowed us to understand the first issues about the UI elements’ positioning.

Heat map of users’ clicks

The UI

The last step was the actual creation of the final UI and the prototyping of it.

Even though it was the final activity, it has been one of the most challenging and engaging. I’ve previously said that a good UI with a bad architecture translates in a bad user experience, but is also very true the opposite!

A great UX without an intuitive and appealing UI can vanish all the good work on the UX. That’s why we spent a lot of effort also in this part.

STYLE DEFINITION

Firstly we went back to the Politecnico di Milano style guide in order to understand the brand identity and follow it also in the redesign. The brand book provides the colours, as well as the fonts, the logo etc.

We created then our first proposal of the UI with a style a bit different from the one of Politecnico, but that could have been more in line with to the last UI trends: bold colors, glassmorphism, glowing elements etc.

First UI attempt

After a meeting with our clients, we decided together that it was too distant from the institutional image of Politecnico and its brand identity, so we started to design other proposals, testing them also with the users.

The final result

After a few iterations, we arrived to the final solution. It includes all the concepts introduced with the first proposal like: the division of every screen into two parts by a blue “card” on the top; the widgets; a header on every page to make the user understand his position inside the app, a three icons navbar etc.; but with a more clear and coherent style.

The UI is composed by elements included in a custom design system that allows consistency among the screens and an easy scalability.

To present it also to our customers, we decided to create something different in addition to the presentation: a teaser! (I’m very proud of it 😍)

App redesign teaser

And finally we have the final result! The UI has been then prototyped in ProtoPie (advanced prototyping tool) to make it feel as real as possible with animated interaction and functioning variables.

We tested it with our users and they shared with us amazing comments. They were pleased by the fresh look and the intuitiveness of it!

Comparison

And this is the end!

I enjoyed a lot this short, but at the same time long redesign process. I improved my knowledge about UX Research and User Testing, as well as how to redesign an application instead of creating a new one.

If I had to give some advices to people who have to do the same I would absolutely stress 5 points:

  1. Plan every action in advance, time is precious and cannot be wasted;
  2. Spend enough time on the initial research, you can learn a lot of insights about what you shouldn’t do in your redesign;
  3. ALWAYS involve users in every step of the process. They know way better what you should do, you just have to apply what they say;
  4. NEVER think that when you finish a step it is closed forever. The design process includes a lot of iteration. Sometimes you just have to change a detail, sometimes everything. It is part of the game!
  5. Be brave and push everything beyond the limits of the conventional. As designers we should always try to innovate.

Of course the previous advices are based on a personal experience, but they have been useful during my design career and not only for this redesign.

Thank you for reading all the article. Let me know what you think about the process and also about the final result and if just one thing could help you with your work I could consider myself happy.

If you have any advice, comment or critique I would love to hear it!

See you soon!

--

--

Elio Raineri

Digital and Interaction Design student MSc at Polimi. UX Design Intern @IBM. Interested in anything electric-powered.