One of my first assignments was preparing a visual refresh for the Pixelboxx DAM application, which featured heavy visuals and a somewhat messy color hierarchy.
Before and after Pixelboxx DAM design refresh.
Next, I started working on a proper redesign of the application, which included a modern codebase.
Created mockups for new and improved product features.
Customized a CSS framework used by the frontend team for scaffolding new projects.
Collaborated with developers and QA engineers for validating feature releases.
Researched and coded a user customisable grid layout functionality based on AngularJS.
Wrote a tool using TypeScript and P5.js for generating perceptually uniform color palettes.
Design System
Established and owned a growing collection of UI components in our shared design library.
Databoxx
Collaborated with product owners and specialists to create a next-generation product enable companies to collect, transform, merge and output data between different applications in the asset management lifecycle.
More
Prototyped a Figma plugin which imported sample assets from our DAM library.
Drew simple illustrations for empty states and internal tools.
Refined the shape and typography of the product logo.
Coded a Figma plugin which automated the process of generating an icon library.
How we set to create a new, mobile-first experience for an existing product while having the entire team involved through the design process.
Summary
Client: Porto Seguro
Sector: Consumer, Car Insurance, Vehicle Monitoring, Services
Year: 2018
Duration: 3 weeks
Roles: Design Sprint Facilitation, Information Architecture, UI Design
Briefing
When Porto Seguro’s Protection and Monitoring product team approached us to design their new mobile app, they didn’t have a clear idea of what the process would look like.
The team and I had just recently been through a few hurdles — caused by constant scope changes, requirement misalignments, lack of product vision —, and we were committed to not let that happen again.
We proposed doing a design sprint workshop, an inception-like process that would include developers, designers, and product managers, bringing the experts’ knowledge, and leveraging a lean approach to design to understand the product requirements and create a well-rounded concept from the best ideas.
Our goal was to work for 2 weeks to create a working prototype that provided most of the features found in the existing desktop website and then hand it off to the engineering team for further development. Though, eventually, I’d realize there was much more work than I planned in the beginning.
Leading a Design Sprint Workshop
Before this project, I’ve had some exposure to the design sprint methodology as preached by the Google Ventures team, either by reading articles, books, or taking part in workshops.
The workshop facilitation role I figured out on the fly, I guess, thanks to my previous talking, and event organization experiences. The workshop structure, on the other hand, was very much an adaption of the original methodology, taking into account our needs and priorities.
The week was roughly divided like this:
Monday: understanding the product, customer journey mapping
Tuesday: brainstorming, sketching out ideas, voting
Wednesday: picking the best proposals, defining use case scenarios
Thursday: creating an interactive prototype, preparation for tests
Friday: testing with users, surveys, end-result presentation
Mapping the Customer Journey
Early on the design sprint, we knew that the existing web application — which was available only on the desktop — had some major limitations and inconsistencies in the perceived usability.
There’re several features, each aimed towards a specific user group, with different needs and expectations. In fact, some of them didn’t even work as intended. So, the best thing to do was to try and narrow down the product to its core features.
I walked the team through the customer journey for a typical use case scenario and, together, we explored the context, thoughts, feelings, and tools used by the user at each step.
Takeaways
We identified two distinct users-scenarios:
single-use customer: owns the car, shares it with a partner, safety comes first.
fleet or car rental manager: doesn’t own the vehicles; needs daily, comprehensive usage reports; financial costs are the priority.
Collective Brainstorming
It was crucial for this project that product managers, developers, the marketing department felt included and with a shared sense of ownership, from the very beginning and extending to the visual design of the application itself.
Naturally, that also fits well with the design sprint we had in mind. I briefly introduced the activity to everyone, touched on the proposed scenario, and also gave some tips on how to draw wireframes quickly. No hard rules, and made sure everyone was having fun.
Finally, after an exciting, electric brainstorming session, our table was full of sketches with many interesting, wild ideas.
Each team member had the opportunity to explain and elaborate on their sketches to the group and one thing we noticed was the convergence of ideas around the right UI pattern to use in the main navigation.
Some of the UI patterns we considered for the app: bottom navigation bar, navigation drawer, bottom sheet, floating action button (FAB), tabs, and hub. We tallied our votes, discussed and weighed in the options; there was a certain consensus on the bottom sheet UI over the other navigation patterns. In reality, though, things would get more complicated in the second week, but more on that later.
Platform Consistency vs. Brand Uniformity
Once we’ve decided on a direction and which features to include, I started working on the digital wireframes. I used a toned-down, ready-made UI Toolkit for Sketch to quickly put these screens together in an effort to get something ready for testing.
Early wireframes showing different parts of the app. Most of my design decisions and overall information architecture approach was based on Google’s Material Design documentation, articles, screenshots, and reference material from some of the best Android apps out there.
Still, product marketing wasn’t happy seeing a new app that didn’t mimic the UI of the other corporate apps or adhere to the branding guidelines in place.
The main issue here was the drawer and sheet navigation pattern we’re using and which wasn’t present in any of the other company apps. So, I had to scrap this idea and opt-in for a hub navigation pattern which was more common.
Lessons Learned
While I didn’t expect that choosing the appropriate navigation pattern would raise so many polarizing opinions it was important to listen carefully to what others have to say and look for the existing guidelines, apps, and whatnot, before committing to an essential design decision, such as navigation.
Expanding the Prototype
There was no time to waste, and while things were still being settled, I pushed into further detailing and improving the initial wireframes.
I moved on to a higher fidelity mockup model and created the base color palette, typography, component, and icon library that would be used across the project.
Icon libraryButton styles
I also took the time to define some alternative navigation paths for the new screens and screen states, to keep the navigation consistent across the different parts of the app.
Results
One of the most fun and challenging parts of the project was designing the map screen, from which the customer could check the current status of their vehicle or any of the vehicles they were managing.
From there, they also had access to a hub-style menu with which they could create notification alerts, set usage rules, edit their personal and payment information, and more.
Motion and Interaction
….
Wrapping Up
After two intense weeks working in different parts of the app, there was still a lot do, in terms of feature completion, that wasn’t planned in the beginning but which needed to be addressed somehow.
The client agreed to extend the project for a couple more weeks and then I was able to further design the remaining screens.
The next week I worked onsite with the client, asking questions and ironing out any issues I encountered. The result was a near-complete app prototype in InVision, which was ready to be handed off to the engineering team for development.
In retrospective, I am really proud of the work I did for this project, especially the part I was responsible for facilitating the workshop.
My Role: UX/UI design, front-end development, CSS, HTML, and JavaScript.
Background
At Wine.com.br, we’d known for some time that the store’s mobile traffic had increased day after day, sitting roughly at 25% of the total traffic at the time. On the other hand the mobile e-commerce conversion rate was lagging behind of what was expected, well below the measured for customers coming from desktop or tablets.
Admittedly, our mobile shopping experience was broken. I mean, it suffered big performance and usability issues because of our desktop website which didn’t support responsive layouts which required the user to pan and zoom to navigate whilst we had to support old browsers such as IE7/8, thus hurting page load times.
The goal was to improve customer engagement with a more thoughtful design and blazing fast loading times.
The Process
With that prospect in mind I started to sketch some pages and built a rough but useful paper prototype which helped me get sense of the device.
Cardboard iPhone mockup and sheets of paper.
Another cool thing I made was a couple of storyboards. At first they seemed a little silly — they featured some cartoonish star-shaped human figures — but after a while I realized they were excellent on bringing light to some of the context in which the mobile website could be used.
A quirky storyboard depicting an use case for Wine’s mobile website.
After some consideration I moved on to Axure RP to make some diagrams and draw the wireframes with a bit more of fidelity, perhaps adding some interactivity to make things swift and understandable for both developers and managers.
I’ve already used the software a couple of times by then and though it would be a no-brainer but the reality was that Axure seemed too complicated this time. I needed something with higher fidelity but still lightweight, which would allow me to mock pages with variable content, not just “Lorem ipsum” all over the place. Gosh, I hate Lorem ipsum!
So what I finally did was to build a live prototype using HTML, CSS and a handful of PHP and JavaScript functions to jumpstart the development, cutting off unnecessary Photoshop/Fireworks layout comps altogether. I worked closely with my colleague Hideki Katsumoto to pick the right colors, fonts, sizes and spacing for all page elements.
The project was well received by the stakeholders and was given the green light. From that on, we can easily reassess the pain points in the customer’s journey, tweaking and refining when necessary.
Diving into CSS and HTML
Fortunately, we were able to push some great improvements to our front-end workflow. To begin with, we ditched the monolithic, conventional way of doing CSS with a modular, component-based, BEM-like architecture that gave us more control over our style sheets, improving overall performance and maintainability.
The naming convention is heavily inspired by Nicolas Gallagher’s work with some minor additions. To glue everything together we choose LESS as our CSS preprocessor and Grunt as the task manager.
The process also included the creation of image sprites, icon fonts, touch icons, retina images and so on.
Results
The CSS work and development efforts to cut JavaScript footprint combined resulted in page load times twice as fast as the desktop version and a 25% increase in the e-commerce conversion rate over the previous months.
