Pleexy is a no code integration tool which main goal is to save their user’s time and allow them to maintain focus on their tasks. We achieve this by integrating all different kind of inputs from productivity apps (emails, notes, cards, et.) into a task manager.

When I first joined Pleexy, they had gone through a website redesign & branding process. Their next step was to redesign the whole app, as the drop off rate was very high in different parts of the flow, specially in mobile. My task was then to redesign the whole interface.

As there had been a re-branding right before I started, there were some elements that had to be updated, like colors and typography. This was done previous to the re-design of the homepage.

Lean approach

Redesigning the whole app was a very big task to tackle, so we divided the project into smaller chunks that could be done sequentially.

We had all the analytics data plus some customer interviews that the founding team had done before. Crossing this information led us to generate the hypothesis that improving the homepage empty state (once a user had created an account and had to create an integration for the first time) would reduce the drop-off rate.

Expert assessment

Pleexy needed an optimised mobile view

Despite it is more likely for an integration tool to be used on a Desktop computer, a proper mobile onboarding is key, as it’s the first impression it generates on the user. Sadly, they didn’t have a proper mobile view.

There was to clear CTA

When the user created an account, they arrived to a page where they just saw a bunch of different apps with no indication of what to do. The first requirement I laid out was to have a proper CTA that should guide the user through the creation of their first connection (that’s the name given to the integrations in Pleexy).

Cognitive overload

Having all the logos in a list with different colors where there’s no clear indicator of what to do generates cognitive overload, which results in users just leaving without trying anything. Second requirement was to reduce as much as possible the cognitive overload.

Lack of useful information

The only link that kind of stands out from the interface is the “Request an integration” one, which gives little information or guidance to the user. The third requirement we defined was to add useful information for users to create a connection.

Redesign

Mobile first approach

As we were already redesigning the interface and the user flows, I used the opportunity to introduce a mobile first approach. This was important because the data showed that a big amount of the drop offs were in mobile, and it was one of the key moves to reduce the drop off.

Added a main CTA

The first thing in my mind was to add a CTA to guide the user on what they had to do. The coy clearly states Create your first connection, and it’s the element with the biggest color, shape and size contrast, which makes it almost impossible to miss it.

Added useful information

I added an intro sentence where it states what the user should be expecting from the interface. This gives the user the certainty that they are where they want to be, and that they will do what they want to do.

I also added 2 links below the CTA:

1. Visit the help Center Allows the user to watch videos or read articles related to how to use pleexy, how to setup the connections they need, etc.

2. Contact us opens the Intercom chat for the user to submit their question to support.

Reduced the cognitive load

I decided to separate the homepage in 2 steps. It makes the process longer, but it gives the user the certainty that they’re doing the right thing. The empty state invites the user to create a connection. The second one gives them the options to connect the app they use.

In the second step of the flow, the user has a clear CTA for each of the connection, where they get a bit of information that guides them through what they will do with each.

This decision was made to reduce cognitive load, and to have the users invested in the flow, reassuring them they were on the right path all the time and at the same time making it harder for them to abandon the flow, as they had already invested some effort on it.

Reaching the goal

After this was implemented, the drop-off rate for new customers was reduced in 70%. It’s important to say that there was also a website redesign and a marketing focus on this issue - which also definitely affected the result, but it was successful and something to be proud of (After this project they made me a partner and I’m still involved with Pleexy) 😎

Delightree is a SAAS company which focus was to automate Standard Operation Procedures) SOP for franchises - they have pivoted since I left the company.

I joined the company when they had just got funding based on an MVP, and my task was to re-design the interface to make it a sellable product.

One of the hypothesis the product manager wanted to validate was that tasks would be created by store managers, which were part of the Deskless Workforce. Hence, they needed a way to create a task for their team.

Discovery

As part of the discovery process we had client interviews and input from the Customer Success team. Based on it, we created a list of requirements we needed to fulfill when creating a task:

1. A title for the task

2. A description for the task

3. Any attachments that were relevant for the assignee to complete the task

4. There were 2 modes

   1. Simple task

   2. Task with To-dos

5. Had to be scheduled for a specific day

   1. Could have a specific completion time

   2. Could be a one time task

   3. Could be a repetitive task

      1. Repetitive tasks had a set of different variations

6. Had to be assigned to different people

   1. Could be assigned to individuals

   2. Could be assigned to the whole store

Decisions

As it was a lot of information, we decided to break the creation into a step by step flow that reduced the cognitive noise and help them focus on the task at hand. It ended up being divided into a 4 section flow.

Details

The details section grouped everything that was related with the information the Assignee needed to know in order to be able to complete the task:

• Title

• Description

• Attachments

To dos

During the validation process we realised there were 2 main type of tasks: The ones that were a simple confirmation task (I’ve made it), while other required more actions. The actions that we identified during our research were:

• Checklist (sub-tasks)

• Take a picture

• Attach a file

• Write something

• Multiple choice

• Rating

Based on this, the second part of the flow was focused on helping the user choose what type of task to create.

Schedule

Also as part of our research and the data we had from the platform, we realised users created more repeating tasks than one time ones. That’s why we made this the default option. Also, we added the “Advanced settings” feature, which gave the users the flexibility to schedule their tasks with very complex settings while keeping it simple at first sight.

Assign

The last step of the flow was who to assign the task to. Users had the option to assign the task to a whole location where just 1 person from that location could complete it (Close the store, for example) and it’d be completed for everyone who belong to that store, or to a specific individual. We referenced Whatsapp and Facebook’s way of doing this in mobile, and mixed it with our specific needs.

Conclusion

In the end, we came up with a flow that took users smoothly through the whole task creation process, assuring them they were doing that they wanted to do and guiding them all the time. This had a high rate of acceptance and rose task creation metrics, which made it a successful project.

CABB stands for Consorcio de Aguas Bilbao Bizkaya. They’re the ones in charge of providing Bilbao with clean water, as well as purifying the wastewater created.

As a product designer for DigitaLinkers, my task was to re-design their SCADA system (A SCADA is a central controller for industrial machinery).

This project is a continuation of a different case study. In order to gain a better context, I’d recommend you to take a look at that one before reading this case study.

The first part of the project was to design a dashboard that gave an overview of the plant’s processes. The second one was to improve the experience for the plant’s controllers, which is what this case is about.

*This particular software is only available for Desktop, and they have a fixed resolution for their screens, which made responsive irrelevant for this project.

Discovery

When this project started, we had already covered some ground as part of the discovery phase. Nevertheless, we were still missing to talk to the heavy users of the software: the operations team.

We had a different sessions where we went through the flows and actions of each of the different operation profiles. When we were done, we came up with rules and constrains we’d need to follow and also identified some data that wasn’t necessary and we could get rid of.

Requirements

1. Make the UI cleaner and easier to read. Almost everybody agreed that the UI was very heavy to the eyes.

2. Improve the way alerts were displayed. With some many graphical elements alerts were constantly missed or ignored.

3. Improve the flows and navigation. They had inconsistent navigation patterns which result in users getting lost in the interface.

Hands on

Navigation

The first thing we did was to map the software structure, so we could define a proper navigation pattern. In the end, we went for a tree structure with a Breadcrumb, that would always let the user know where they were.

Colors

As we had already defined a color palette for the Dashboard project, we just inherited it and keep working with it.

Flows

In order to understand better the flows they had, we went for a full deconstruction of the screens and try and understand what they wanted to show.

We set a weekly iterative process, where I showed my progress on Friday, we went over it, discussed it and got some initial feedback, and then they sent all the final feedback on Tuesday. Then I’d present my progress on Friday, and so on.

Iconography

After the flows were accepted, then we went to the icon design phase, where each of the elements should be clear, but at the same time abstract enough so that they could be easily placed in the system, reducing all the clutter the images they were using before created.

The biggest challenge here was to follow the guides and constrains from the software, so we had to come up with a system for displaying all kind of different status.

Design System

Once the iconography was put in place, we developed a system for the developers to follow it, so they could then build all of the software following it.

We also created a UI Kit that was shared with them as a PDF. You can check it here.

Final product

In the end, we created a design system for them to build their SCADA according to their needs (Alarms, different states, processes, CTAs, etc).

Made the UI cleaner and easier to read

Our approach was to make the interface as clean and abstract as possible, giving more importance to actionable items than to what was working properly. This gave the operations people a clear state of their process, and told them what they had to do.

Improved the way alerts were displayed

We reduced the clutter with alerts by creating a framework for categories of them. Also, we used the red color as the alert one, generating a lot of contrast and letting the user know when something wasn’t working, right away.

Improved the flows and navigation

As part of the Information Architecture, we blended some views and separated others. We also added a proper breadcrumb with a tree view of the site, where the users is aware of where they are, all the time.

Design system in place

When the project was done, the developers had a system that they could use to build the whole system by themselves. Until today, they haven’t asked for clarification or guidance for anything, which means the system is working properly.