Warning: this is a work in progress project with classified items (that are blurred), icon colors overruling and other flaws in the designs, because it's not final yet. I chose speed before perfectionism, as this was necessary because the team was in need of designs!
Level.works
Level.works is a scaleup that builds and provides a platform for Flexwork, where employers and Flexworkers find each other. Flexwork is a new work form, where employers could quickly fill the gaps in their work force with Flexworkers. It's a flexible shell around their regular work force.
Platforms
1 mobile app for Flexworkers (Android & iOS), 1 web app portal for employers (clients) and 1 webapp portal for internal users at Level.works.
Type of project
SaaS for B2B and B2C.
Project date
2022-2023
My role
UX Designer, UI Designer, Brand Designer, Prototyping, Design system, part of 2 teams: the Product team and the Marketing team.
Challenge
The challenge is to create a solid 2.0 version of both the app and 2 portals with some (minor) improvements, so we can improve the products in the future based on more (user) research. A lot of designs are based on assumptions and discussions internally and partially on research. Due to this situation, my focus was on producing fast instead of taking my time to do all the research that I wanted/needed, which was not top priority in this case from higher levels of the company. The process was not done by the books, but I adapted to it by doing what I thought was right.
Problem
Currently, the products are pimped MVP's (as I would say). A lot of inconsistencies, bad user experience with illogical paths, screens and interactions and a bad visual design are caused by miscommunication from the old design agency and the (dev) team trying to build with missing information. One of the main issues was inconsistency in the location of similar information, which made it hard for users to find what they were looking for.
Actions
The inconsistency and bad user experience was solvable by design. I've tried to create logical paths and gathered similar items in one place by brainstorms and labelling all the items (card sorting in a different way). This way, users have an overview of what they're looking for in an instance. Many of the items were discussed, following by 'small' workshop sessions, trying to create overviews of what is currently there, what is missing and why the users need it. To create a solid base that is easy to extend in the future, I've come up with a template-structure, which enhances the logical paths and putting everything in one place. This was the first step in the right direction.
Results
Since the project is ongoing, it's hard to tell what the metrical results are. We're releasing the portal designs step by step, working agile. The users of the portal did come up with positive feedback and are happy with the way it works in the newer version. The small improvements caused them to reach their goals faster and easier, without our support. The development team is happy with the new templates, as they got to build a new code structure to make it easier to release and develop from there on. The templates are also useful according to them, as it reduced all the cluttering noise. The app is currently under construction, which will take some time as we've just started with the app. So there's no data to track the results currently, but we've managed to talk to some users about the designs and they were happy with the new designs, because the app is easier to use in the new admired way. We're curious to the results after the new app is live and the portal contains more employers to work with it!
Tools
Figma, Miro, Jira, Notion, Adobe InDesign, Adobe Illustrator.
Fancy stuff to note: Design system, SDUI, Ladle.
Process
My approach to this all was to divide products into projects and deal with one at a time as much as possible. I had to start without user research and certain limited resources, but with a lot of information from the company internally and the Marketing team's research on users. From there on I've created structure in the chaos, by clearing the overwhelming amount of the information and size of the projects. I am the only designer for 3 huge projects and the branding, which is challenging and rough at times. First, I dove into the user information and company information, to get to know everything as good as I could in that phase. To do that, I've created 2 Customer Journey's for both user groups, based on information from users themselves and internal resources. From there on I've created a roadmap for project 1 first, the employer portal, so we had a clear vision of what was about to be done and to get stakeholders along and align everybody. This started with brainstorms for the product and with that information, I've decided which steps were necessary to get to the 2.0 version as soon as possible. The dev team was eager to start developing the new designs as soon as possible and there was pressure on this from stakeholders as well.
The first step was to do a design exploration, to get everybody aboard on a new visual design style for the products and get away from the MVP designs that nobody liked. So I started with both the app and portals, to focus on the portals after that because not all stakeholders were aligned with the app at first. Why? That's written in the Failure-section on this page! After the style exploration, it was time to create designs for the dev team to build, because they were waiting (note: they were in need of designs already before I joined, due to the previous design agency not providing the right materials for development and the company).
In a nutshell, the process looked like this:
- Gather information, with small researches, talks internally and some externally (with users)
- Build 2 customer journey's
- Create Design principles for the products, based on the new brand values from Marketing
- Design exploration; sketches, screen selection, typography exploration, wireframes, visual designs of wireframes, creating multiple styles for both app and portals
- Stakeholders agreement: go or no go on the proposed design styles (app was difficult because stakeholders weren't aligned, portal was easier and done faster due to less options)
- Create hi-fi wireframes with current live style for dev, so they can start building a solid 2.0 (more dev-wise with their architecture)
- Align with dev through BDD's (Behavioral Driven Development) and support them by providing what they need and be a source of information and sparring partner for them
- Create visuals
- Build a component library to start with, consisting of atoms and molecules, to align dev & design quicker and make a start with SDUI (Server Driven UI)
- Build a Design System from there on, by including standards, documentation and sections consisting of organisms, templates and pages (in progress)
For the app, there's a different approach:
- Talk to users via the internal User Panel to get a better understanding of their needs and behavior
- Create a new sitemap with small improvements as a start of the 2.0
- Create low-fi wireframes
- Align with dev through BDD's
- Create visuals
- Build a component library to start with again
- Extend the existing Design System from there on
Failures
Well, failures is a bit of a hard term, but these are mostly things that went wrong and where I've learned from:
Colors
Before I started at Level.works, the Marketing team collaborated with another design and development agency to create a new website. I was not part of this process and when I joined the company, they were already deep in the process. I was focussing on other stuff first, because it was big and overwhelming, and the new website was not part of my duties so I left it as it was. But what I didn't know, was that the design agency created a 'new visual identity' as well, which wasn't really an identity but a moodboard with 3 colors and a font, which I don't know the reasoning behind when it comes to arguments and decisions, that worked okay-ish for the website. It didn't work for the products I was working on, so I've tried to convince some stakeholders about what was better designwise. This was a long way with a lot of downs and some conflicts as well, because I wasn't taking these stakeholders on in each step of my process; I found this unnecessary because they didn't have knowledge about this expertise and it was not part of their responsibilities and duties. After showing multiple times why I needed different colors, I gained their trust and got a go on a few new colors. It's just hard to design a professional portal with yellow, black and white if you want it to be accessible and user friendly...
Styles overload
For the design exploration, I've created a lot of design styles (22 to be precise). I've scaled them down to 13 design styles for the app, and 3 for the portal. You can guess which one was easier to have a go on. Yup, the portal. With only 3 styles and a different user group it was way easier to make a decision. For the app, it was just an overload of options, so the stakeholders were overwhelmed and couldn't decide. The opinions for the app were so divided, that I had to park that project and hop on the portal (which was our priority anyway). The app style is still to be decided on, as it's a work in progress at the time of writing this.
Not fast enough
I am the only designer and I am part of the branding process as well. This means that I have to spread my time (which is 87,5% for the Product team) over multiple projects. Therefore, I was not able to build the brand book and all its templates fast enough so Marketing could get on with using that. This is of course a huge project which normally takes multiple designers and teams, but here I am on my own. This resulted in last minute tasks coming from Marketing, working around my other duties and priorities, where I did my best to deliver every time. And I did deliver. But it was chaotic, caused noise in my work and planning and was frustrating for both parties sometimes. Luckily I have a high work ethic, so I could always get the job done in time, but it's not how I work. The solution is to create all the templates and finalize the brand book of course. The reality is that I don't have enough time to do a job of 5+ designers all in 1 designer, which I'm currently doing. The result is that I was not happy with the designs they needed in between tasks, because there's no strong brand behind it. That's not how I like to work, but sometimes it's necessary. Progress over perfection is my philosophy!
Lead Designer
Yeah, that's what I was promised to grow to real quick and I was even seen by certain people as the Lead Designer. We needed more designers of course. But at the beginning I stated that I first needed to get a grip on the overwhelming load of work and projects. After that, I could predict what I needed and if I needed multiple designers in a team with me. Sadly, after certain circumstances that were out of my control, this promise fell into pieces and I am not able to grow to the Lead Designer. This saddened me because I really love to help people, and growing and guiding designers as a Lead would be one of my wishes. This also means that I have to do everything on my own as a designer, which is a lot, and that is tough.
These are not mine...
No, really! A design agency made these 'visual designs' before I joined the company. This is mainly for after MVP launched and dev already built a lot of this style. Then I joined and tried to improve these products.
Customer Journey
The 2 customer journey's that I've made for our user groups: the Flexworkers and the employers. I didn't work with persona's yet in this case, as there was not much time and the Marketing team already had made personas (which weren't useful for product design but valuable as a different source of information). I involved the departments as much as possible to gather all the right information, as time was limited and I didn't have the resources to research the users a lot more.
Flexworkers
I created this Customer Journey with interview data from the Marketing team, internal information from departments that work closely with Flexworkers and other stakeholders. The goal was to get an understanding of the user group and get a clear vision of which journey they go through from the first need until the last (repetitive) step, with a focus on our products. The journey and user group was more B2C. The idea behind it is to improve the Customer Journey in the future, but was not the main focus for now. That's why the opportunities are not filled in that much. It was an eye opener to see how the journey really was for these users and how many gaps we still have to cover!
Employers
This customer journey is also created to get a better understanding of the user and what journey they go through. It was different than the other journey, as this was pure B2B.
Research
It's good to state that there wasn't much room for research and it is not the current goal to dive really deep into the users in the phase that the products and company are in. The users weren't involved as much as I would like, simply because the goal and priority was to create a solid 2.0 version and build from there based on research. This is a compromise that was made before I joined. But I did research as much as possible though and tried to make the best of it. I want to setup more research in the near future when the solid 2.0 is live. Then I want to dive deeper into qualitative research with the users via interviews, user tests, persona's, behavioral researches (such as observations, task analysis etc.).
User Tests
We've done user tests with videocalls and screensharing to employers. Not ideal, but great for a quick verification and their first thoughts. During these calls, I got some area to do quick interviews and asked them about the 'why' for things they do, want/need, think and feel. This was an eye opener in some cases, as we didn't always knew how they use certain features or the product in general. Each employer was slightly different; with different needs, ways of working and motivation.
User Panel
I was part of a team that setup the first User Panel. We've gathered Flexworkers in our office and asked them a lot about why they do Flexwork, how they do it, how they work with the app, what their needs, wants, motivation and goals etc. are. This was also eye opening, as each user was different and they even shared their experiences together. So we discovered that we were onto something.
Interviews
The Marketing team has done multiple interviews, so I've done my 'desk research' part on all that information that was available.
Internal
A certain amount of info is also gathered by joining internal departments, to get to know what they do exactly and what they hear from the users. This way, I could verify certain things real quick, like what issues the department AND the users face and at what frequency.
Design principles
Based on the research I've done and the brand values that Marketing had provided, I've came up with Design principles that guide the products and align what they stand for with the brand. This way it is easier to make decisions and know why we do certain things.
Brand values
The brand values were made by the Marketing team right before I joined, so I've decided to translate them into Design principles as the brand values weren't usable for the products in my design opinion. The brand values are:
- Development & Perspective
- Personal & Transparency
- Freedom & Autonomy
- Driven & Dedicated
Starting with these values, the Head of Product and I went through a process and multiple iterations to come up with Design principles, as shown below.
And this are the v1 Design principles:
Sitemaps
To create a good overview of the products and what they have, I've created multiple sitemaps; from existing material to sitemaps of new material. This way, it is clear what we have, how it works and what we need in the future.
Design exploration
Finally. The big thing. This is what I love the most: create something from scratch. Stakeholders aboard, let's rock and roll. So I rolled; I started with exploring by sketching, making a selection of screens to design and having a variety of components in these screens to make a good decision for a style. From there on, I've explored typography. Do users (and we as well) want modern fonts or more conservative ones? Is readability important (yeah, duh...) and what other values are important as well? After that, I've started with some low-fi wireframes, and create visual designs based on those wireframes. Multiple visual styles, 22 styles eventually, spread over multiple different screens. Both for the app and portals. It's too big to display here, but I've tried to cut it into small screenshots/sections to give you an idea of what it is.
Sketches
I started with sketching a lot of screen possibilities for the design exploration. These are some of the many sketches that were made.
Screen selection
Most of these screens are not existing in the current app, so I've tried to be innovative with the research findings in mind.
Typography
From long lists of sans serif and serif fonts, on both light and dark backgrounds, to short lists and top picks to pairing fonts. All to see what has potential. Eventually, the decision was made once the fonts were active in the designs and were tested that way.
Design explorations
So from there on, I started exploring different design styles. And it was a lot, with well over 300 screens. Just for the app alone. The portal was a bit shorter when it came to visual exploration, as the stakeholders and I agreed upon a style quite fast.
Different styles
It's hard to show all the different styles, so I've picked a couple to showcase.
Sketches
These are some of the sketches from screens and brainstorms etc. People want to see the process, which is tough (and huge) to show, but hopefully this gives an idea of how it all started!
New templates in the making
These were made with devs to create new templates. They wanted to build a new dev structure in the portal, so this was really helpful for them as well.
Wireframes/templates
Let me explain this a bit, before you judge. You might already have judged based on these strange looking wireframes, you impatient bastard. So, because we're moving from a pimped MVP to a solid 2.0 during multiple months, development needs to build something of course. After some talks, we've decided to create "wireframes" who contain certain elements that are in the current live portal. These items are fonts, buttons, colors etc. This is why the wireframes are polished more than usual and look a bit like hi-fi wireframes, although they're still ugly. I know, I don't like them either, but they're useful and a step forward. And I love progress.
I've divided the screens in the portal into templates, as there were so many different screens with many variables. So this is where the templates come from, which is the idea behind our design system.
Visuals
After the wireframes, I've created visual designs based on the wireframes or with small improvements that weren't in the current scope of developing the wireframes codewise. This is also the start of the component library, that will transform into a design system along the way as we build it.
Progress
I. Love. Progress. To show what we've came from and what we're going to, I've chosen this shot about creating a new shift. You can see how it was, how it is going to be soon and how it will be after that step.
Component library -> Design system
Because all the visuals have components, I've created an extended component library. This is currently being build and filled with documentation etc. It's based on a 8pt grid. The sections, aka the organisms, are already partially made, as well as the templates and pages. We want a design system to build and develop fast in the future, especially after new research insights. It's also to align development and design, by implementing SDUI (Server Driven UI). This way, we don't have to release that often and can deliver changes in our products much faster than we do now. So yeah, dev and design work well together I'd say!
Design system
This is the overall shot of the design system as it is now (but it's work in progress). Everything is divided in different pages with its documentation. We want to implement this in Notion in the future as well. Dev is going to build this in Ladle, so they can develop faster once they get designs that are based on the new templates.
Atoms
These are some of the atoms and a start of the documentation. This is blurred because it's in progress and contains sensitive information.
Molecules
Some of the molecules, which consistent of atoms.
Organisms (Sections)
These are some of the organisms, which consistent of molecules combined. We call them sections, in line with SDUI.
Branding
I'm creating the brand book for the brand, with a focus on visual identity, to turn it into a Design Language with all the info about how to use colors, illustrations and tone of voice for example. Sadly, I was not involved in building the brand heart and the other things in the process before the visual identity. So I spend my limited time for Marketing on the brand book and visual identity for now. My focus is to create a solid workable brand book to guide people who work with it and create templates they can use for different purposes, like social media and advertising.
Dev&Design
The collaboration with the development team is based on trust and fun. They trust me in the process of creating designs with the right arguments behind it. Of course we have brainstorms and fun talks about the designs, and I value their input a lot. They keep me sharp and focused. Plus they challenge me sometimes with things I didn't know or haven't thought of. Yup, I don't know everything and I learn along the way.
So how do we do this? We have lots of talks; we have BDD's in Miro; help with the feature requirements; we brainstorm; I try to make the designs as easy to implement as possible for them with Figma; comments and calls to guide them through it before the BDD's take place so they know what it is already; documentation blocks in Figma to guide them through it and organize the file; page numbering done well so wireframes and visuals match perfectly; place designs in Jira tickets so they know exactly which design is the correct one. And have fun during calls all the time, cracking jokes and roasting each other. Yes, it helps and improves productivity. We've proven it. Here are some things they have to say about the designs.
Gringo
Since the name Gringo is placed a lot in the materials you've seen, I thought it would be good to explain why this 'term' or name is there a lot. Maybe you've seen it in my previous projects as well, but Gringo is my puppy! Here's a picture of this little big rebel at the Level.works office during a meeting.
