Designing for the problem, not the feature

https://images.unsplash.com/photo-1587440871875-191322ee64b0?ixlib=rb-1.2.1&q=80&cs=tinysrgb&fm=jpg&crop=entropy

Overview

Arquivei is a company that was founded in 2013 by engineers and professors from USP with the mission of supporting tax compliance and transforming tax obligations into optimization and intelligence for companies, in a fast, accessible and reliable way.

My Role

I was the Product Designer responsible for the end-to-end design process in a multidisciplinar squad with product managers, engineers, business analysts and customer success (8 people). At the discovery phase, I partnered up with 2 designers to advocate for design.

Goals

Outcomes

Glossary

Untitled

Prologue

Designing or redesigning a feature is very common in every company, and there is nothing wrong about that. But we can be in some trouble if we don’t design thinking of the problem, just the final feature or solution. This work started being feature driven, with almost no data about what was wrong or user insights/feedback. We only knew that “we need to make a better NFSe Consulting experience”.

Context

We needed to offer more cities to the “NFSe Consulting”. Our competitors had at least 2x to 3x more available cities, and we were being left behind. This was an old decision because:

Discovery

The stakeholders wanted a prototype as fast as possible. After negotiation and advocating for design and the importance to go through the discovery and research phase, we started with an CSD Matrix (Certainties, Suppositions, and Doubts). We discovered the problem was waaaay deeper than just redesigning a feature. There where a lot of technical debts, ux flaws, and legacy issues. It was a problem that permeated through other parts of the platform, and had its center at the feature “Suppliers List”.

  1. The list was adapted from another feature (wich had a different pourpose), and wasn’t thought for this specific problem;
  2. All the technical debts and bugs from this adapted legacy feature was there too;
  3. At the same time we needed to increase the number of available cities (more cities as it was, exponentially more bugs and users unhappy)

People involved

Learn and take action fast, have an unbiased view. Mitigate as much risk as we could and to deliver the best user-centered solution as possible. To do that, I wantend to involve at least 1 representant of each area: engeneering, customer sucess, business, data, product and design. That’s how we conducted our brainstorming sections and design facilitations.