How I became a UX designer and what I learned so far

Background

I design things since I can remember, but the road from graphic design to UX design wasn’t straight.

When I was a kid, my dad copied PC games for me and I designed the covers with magazines cuts and drawings and texts made by myself.

I used to do the same with music CDs, cassettes, logos for friends, flyers for bands, etc. You know, the usual stuff.

When I was 15 years old, I found a FrontPage 2000 guide left out on a shelf in my house. It taught basic and pure HTML, so I also tried out designing a couple of websites.

I will never forget how amazing it seemed to me to write some lines of code and BAM! Internet Explorer gave me back texts and images. I had created something new where there was nothing before.

 

front page 2000 book

CD included. Awesome!

Transition

As time was passing by I had to choose a career to study and I decided (still with some doubts) to start studying Graphic Design at the college.

I met a whole new world in there and found out the idea I had about graphic design was reduced to something trivial. I discovered identity design, packaging, typography, the Bauhaus, I became obsessed with Helvetica, modernism and the impeccable work of Massimo Vignelli.

 

Helvetica movie was a big influence in my view of design.

I learned that designing is much more than assembling shapes, colors, and text.
Designing is solving a problem that is affecting someone. 

Tweet this

Back to coding

But, I don’t know why, that ‘web design’ thing that I once ventured on my own was still there and had not disappeared.

Out of curiosity, and a bit because of not knowing what else to do, I got into a very intensive course where I learned HTML, CSS, and Flash.

Yes, Flash.

At that time I was not entirely clear about how this knowledge would fit with the graphic design I had learned in college, which by then had been in the past… Did I mention that I abandoned it? Didn’t I? Well, that story will go a separate way.

I followed my guts and a few years later I founded a multidisciplinary design studio together with a friend.

Scale

There we faced all kinds of design projects. We didn’t say no to anything.

The knowledge we had acquired in college plus my knowledge of, what I later learned is called front-end, allowed us to cover all kinds of projects.

Over time, however, this lack of specialization began to make me uncomfortable, feeling that we were doing anything very well at all.

I liked writing code and designing interfaces and brands but I did not finish perfecting myself in any, so I decided to leave it behind and create a studio that only focused on one service so that I could do it really well.

New stage: UX

Defining that service to get specialized was something quite natural.

Previously, programming companies had entrusted me with projects where all they needed was interface design. They, of course, would translate it into code.

In UI and UX design I found, a union between two disciplines that I had always enjoyed.

I could solve communication problems for users, be in touch with the graphic aspects of the design and in turn see that all finally embodied in a digital product.

I was still involved with the code as it was always a part of these products, I may not write it directly but I know that it will be affected by what I do and vice versa.

A new service

I was really excited about commissioning this new stage and learning a lot about a new discipline.

But real learning, that one which is not found in any book, blog or video, began a while later: the one that comes with the experience.

When I could see live some of the projects I had participated, I soon discovered several errors… and 90% were mine!

Today, I can reflect that the biggest mistake that encompasses all the others was assuming: not clarifying certain things assuming they were obvious.

  • I assumed that whoever had the honor to inspect my mockups in Photoshop was going to export the icons in SVG instead of PNG.
  • I assumed that they were going to interpret the layers names as indicative.
  • I assumed that they were going to apply different states for links and buttons.
  • I assumed that they would integrate animations.
  • I assumed that they would apply overlays from CSS, etc.

All this led me thinking: “Ok, maybe my work is not as clear as I think it is”

DELIVERABLES 101: Assets folder.

The first step was to avoid the development team having to go into a tangle of files and layers to get the asset they needed. I started to be more organized with the deliverables.

Folders and files named in an understandable way, in the required extension, size, and scale.

Deliverables folder

Pretty easy, right?

UI Style Guide

I came across UI Style Guides when investigating resources to make the implementation of designs more faithful.

With a link to the corporate identity manual, I found it as a valid solution to document the work done. Grids, font variables, colors, styles in inputs, etc.

It also allowed me to specify things that were difficult in a static mockup. For example, the hover and active states of a button; and even going a little further and begin to contemplate components that may not be in the current project, but could be required in the future.

UI Style Guide made for Quickpix

UI Style Guide made for Quickpix

Modals, toasts, validation and error messages, radio buttons, check boxes and other elements made the UI Style Guide begin to contemplate the scalability of a product. A product that may not have the size (or budget) enough to have its own design system.

Interaction design

The final product improved after applying this change when delivering my work.

It continued to perceive, however, that the final result was something rigid, lacking in life and revealing new flaws that affected its usability.

This is how I found that I could begin to contemplate and anticipate this type of problems through the interaction design and its proper documentation.

Column transition and fixed navigation sample

This animation served to indicate simple features like column transition and a fixed navigation bar.

Conclusion

This road I’ve been on taught me how difficult it is to propose a design, to get it right the first time and then forget about that project. The ideal, necessary and logical is having an improvement and constant correction. Not only of the final product but of the service provided as well.

Retrospective, self-criticism, and learning are key factors in all areas of our lives and of course, our work is not exempt from them.

It is my debt today, to find a way to solve the support we must provide to the companies and teams that entrust us with their projects.

Find a way to not forget about the products that have been created and to apply corrections to their possible failures, or ours.

Let’s not forget that behind all these projects there are humans and we all make mistakes.

Agility to deliver high-value solutions

One of the great challenges of any company is to understand whom they offer their service to and why they do it. So, why do we say we design for agile development teams?

The best way to explain this will be splitting the question into two parts.

Why developers?

A few years ago, when we started to work on interface design, we had different types of clients; some were programmers and others were design studios and advertising agencies. I remember that we had the opportunity to design a website for a graphic design agency in England.

When we finished the first round of designs, their feedback was: “I think it needs to be more pop kitsch”. Pop kitsch? That was not a profitable return at all! It clearly came from a less pragmatic designer/artist, and this was not the kind of feedback we used to receive when working with development teams. But, on the other hand, it helped a lot to clarify and define a little more with whom we wanted to make work teams and with whom we didn’t.

Design aims to ensure the effectiveness of communications. It is centered in the user; It is ethical because it is based on the knowledge of the “other” as different and respectable. – Jorge Frascara

Although the concept of “designer” is often deviated and is only thought to be someone who embellishes things, the reality is that designers and developers share very similar goals. Both seek the best solution to a problem.

We design for developers because we feel comfortable with their practical approach when developing a digital product, their passion for solving problems; they trust our work, they do not think about fonts or colors, just as we don’t think if it is more convenient to use Angular or Xamarin.

Why agile?

We believe that the best way to deliver value to the users is by taking small steps towards the final product. Observing, learning, correcting our mistakes and repeating the process again. We work together with agile teams because we consider ourselves agile, as designers, as a team, and as a company.

At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly. – Principles behind the Agile Manifesto

We are not talking about teams that use Kanban, SCRUM or XP, nor about teams that only want to launch a product as soon as possible, but teams that have the courage to take responsibility for their actions, recognize their mistakes and learn from them quickly to correct them.

Agile was not originally conceived as a series of rules and ceremonies, it was invented as a set of principles that guided teams to achieve agility, or the ability to respond gracefully to the change around them. – Page Laubheimer

That’s the agility we seek in our work process and the agility we seek to promote to deliver products of great value to the users. We believe that this is the best way to do it. If not, we will stop, look back, reflect and correct our course, always agile.