Lucas Petes is a designer who isn’t afraid to code. With a deep love for design, he has produced countless clean and gorgeous interfaces. He talks about his career’s history, giving us a window to understand how it feels to be a designer working among programmers. He discusses the design-development complementarity, pointing that the two are sides of the same job.
WLAD: Tell us a bit about what you do, your work, and how it relates to IT.
LUCAS: I’ve worked with “web design” since I was 14. I was introduced to this job by a schoolmate that had a Harry Potter fan site. Many of my friends were doing their own sites too. One was doing a site about games, another about Dragon Ball Z. Harry Potter was also my interest at the time, so I did a website called “O Caldeirão Furado” (Portuguese translation of “The Leaky Cauldron,” a fictional bar from the Harry Potter books). I’d design the website during the weekdays and test it on the weekends, because at that time I could only access the Internet via a telephone dial-up link.
Almost every week or two, I’d change the website’s layout, and that taught me some tools and HTML. I used WYSIWYG tools (FrontPage at the time), and I was curious to understand the relationship between what I did in the tool and the corresponding changes it would make in the source. I learned HTML little by little, and afterwards, CSS. Then I decided I wanted to do a technical high school. In there, all these web things were a part of the syllabus along with other IT-related stuff, such as programming logic, Delphi, PHP, Pascal, databases, robotics, etc.
From this point, I started working mainly with design—or at least what I understood design was. I had no academic formation, and no deep knowledge about design, just maybe a good aesthetic gut. So I trained that, and other technical skills I learned in school. When I graduated from high school, I was already doing an internship in a company that at the time was one of the best in advertising design, 2XT. At that time, 2XT was very different from what it is today. It was a reference in advertising design along with Lazo, Bhtec, Volt and other top agencies. That sparkled my interest in the company; they produced designs that were well beyond what I could do, although their overall technical expertise didn’t seem to be too far from what I knew.
Code, Marketing, and Product Design
When I joined, 2XT was at a turning point. The partner with a marketing background, Fernando Suzana, had just left, and the people who continued on the company—Zamboni, Mateus, Gustavo (who later left for Intip)—were much more technical, and they took clients that were also more technical. For instance, Primus Turismo, which later became a system for corporate travel management; F5, a CMS system that was used by many major Brazilian newspapers for their websites. These were way more complex systems. I had an interest in complexity, in simplifying access to a great volume of data by the means of a user-friendly interface, even if it had a world of things underneath. I was always more interested in numerical data, and less in simpler projects such as corporate websites. I liked the visual aspect of corporate and marketing websites, but didn’t want to do that as my main work. After about a year and a half at 2XT, I was still delighted by working with design. So I decided to study design at college.
Later, I went on to work at another company called Paradigma. They worked a lot with matters related to organizing information. Bax, Paradigma’s owner, was also a lead professor at the faculty of Information Science at UFMG [Universidade Federal de Minas Gerais] and had a big expertise in CMS and related systems. That, plus the fact I had friends working there, made me interested in the company, and I worked there for a few months. They were a bit rough around the edges; I had to work from home for a long time because they didn’t have machines or computers for me at their office. Once they could finally accommodate me in the office, another big change happened in my career.
Starting a Company
A few old colleagues invited me to form a group of free software development. This group rapidly became a company. I talked to my ex-boss at the marketing agency I had worked before, and he helped us become a company, with the goal of developing an email marketing product. Today we have Mailchimp and many other similar solutions, but at the time we had nothing like it. So we set out to develop a product to send tracked e-mails in bulk, so we could know who opened it, who clicked on it, and other metrics. We agreed on terms with the agency; they were to be like a startup incubator for us. They would give us office space and pay us a very small wage that would barely allow us to pay our basic bills. Once the product was actually released, we would be paid and compensated for all the sacrifice.
With this, the three partners of our newly formed company left our respective jobs, me along with two other programmers, and we went to work on this project from this agency’s office. Again, I was the only designer amidst programmers. I always had very little interaction with other designers. Usually, I was the designer of the team. Anyway, we got started on the product, advanced it a bit, but almost always since the beginning, the agency had a lot of “fires” in their projects. I think it was difficult for them to price, plan and develop their projects. So we started to put out their fires…
WLAD: That’s going to be a polemical interview…
LUCAS: (laughs) By putting out their fires, we left our product development behind and started working with third-party projects, which was precisely what we didn’t want to do. In these cases, we gave them a quote for fixing the problem, forgetting the terms previously agreed upon. Once we had fixed their problems and started to get back on track developing our product, another fire would appear. We were in this loop for about a year, until we argued with the agency and decided to leave their office. The company, called Milk-it, continued to exist. Even though we were no longer part of the agency, we continued taking third-party projects to pay our bills for about three to four years.
We didn’t want to keep on taking projects, but we kept on doing it. Out of the several product ideas we had, none were implemented. We also didn’t have time or money to stop taking the third-party projects. That’s why I decided to leave the company and seek the position I’m at now. At the time I cherry picked Studio Sol and Webcitizen, companies that made their own products that were more in tune with me and what I wanted to work on.
Synergy Between Designers and Coders
I sent my CV to Studio Sol on a Wednesday. That day, Samuel asked if I was serious and invited me to their office Thursday. I went. I left my company on Friday, and started working for Studio Sol the very next Monday. All that happened when Sunday was New Year’s Eve. I didn’t even have time to contact Webcitizen. I wanted to work on a team of designers; I didn’t want to be the sole designer again. I wanted to work on creating products. I had a greater focus on user experience, and I wanted to work in a place where I had usage and access metrics plus user feedback, so I could analyze all that, compare metrics from different interfaces and improve the interface according to these metrics.
At Milk-it we used Agile methods. I was included in the programmers’ work cycle, and there was no work cycle for my design work specifically; usually I worked alone. But at Studio Sol, a few months after I joined, that was implemented there. There was a Scrum process to the team of designers that, at its height, had eight people. The process was the same: we developed stories, scored them, defined our sprints, closed them. We had peculiarities, such as an extra approval phase and a few other small differences in our Kanban board. Afterwards, the design team was reduced and later dissolved into other teams. Again, I became the sole designer in a programming team. My tasks were not part of their Scrum process, but we had daily meetings together, and I took part in the discussions. Looking back, at both Milk-it and Studio Sol I had the role that was kind of an informal Project Owner (PO), because I had lots of initiative. Many new ideas came from me, but they weren’t necessarily approved.
WLAD: What about the future?
LUCAS: I’m going to work on bim.bon, a startup related to architecture and construction. They have a very good product that is very well seen by students and early graduates, which would be their early adopters. Several stakeholders from construction and architecture also liked it. Their initial idea was to produce a plug-in for SketchUp, a software used in architectural modeling. They set out to catalog all the materials needed in a construction project. They got in touch with suppliers and sellers and built a catalog of how much each part would cost. When it’s an object—for instance, a sink or a decorative piece—they would also have a 3D model of the object, or its surface texture.
If you want to build something, a house for instance, you can use their plug-in to build a 3D model of it while also defining the types of materials for the walls, whether it’s drywall, or the type of bricks that the walls will be made of. The same for floors: you would define the type of floor, such as tiled floors, wooden floors, or hydraulic floor tiles. If walls will have a given wallpaper, this would be specified too, along with the type of luminaire, toilet seats, everything. You can parameterize all these materials, including the ones needed for the floor’s foundation, the toilet set’s foundations, and more. The software even has the labor force costs for installing these, to the point that in the end the program can calculate an accurate and complete budget for your construction.
And that is one of the biggest issues in construction. The final cost of building is always a surprise, and the budget is typically never defined in the first stages of the project: its architecture. Usually the architect delivers the project, and later on it goes into the detailing process, to get a general idea of its costs. For instance, the architect defines that a lamp will be placed in a given spot, but in a first stage, people don’t worry too much about how the electrical wiring is going to get there. A budget figure that is more or less precise is only given by the constructor, depending on the way you close the business with them.
With this product you can consider pricing concerns in the start of the project, such that the project fits a given budget right from its early stages. The way it’s done now, the client could state he only has US$100,000 to the architect. The architect then gives you a beautiful project, you approve it, but later on the constructor informs you that it’s going to cost US$200,000. The client won’t be able to execute that, so the project must return back to the initial stage.
Working as Product Manager
WLAD: Why did you decide to work for this company specifically?
LUCAS: My role there will be as Product Manager, acting mainly as a Project Owner for the development and design teams, with the mission of finding what will be the next focus for the product. For cultural aspects, and also market conditions, the product did not have the expected adoption rate; it’s not moving as the founders expected. They recently had a funding round with new investors, resulting in the company going public; everyone was very interested in the project. Now the challenge is to find the product’s new focus, what it is going to become. I presented a few ideas and insights during my job interview process, things that I had diagnosed beforehand. It seems that they liked it, or else they wouldn’t have hired me. But let’s figure out what will happen. So far I’ve been only a designer; it wasn’t expected of me to do these other things. These are things I want to do, skills and functions that I want to get involved with, responsibilities and autonomy that I haven’t had up to the present day. Of course, I feel the butterflies in my stomach, the pressure of taking on a new profession, but I think intuitively this is what I really want.
WLAD: What does a Project Owner do? What are the main responsibilities?
LUCAS: One of the PO’s responsibilities is to is to help the development of the company’s strategies jointly with stakeholders, the project’s entrepreneurs and the product itself. And also to dynamically adjust the path the company takes as it keeps on working, according to the present situation and current metrics, insights and results, to best progress towards the objective until it’s ultimately achieved. The strategies are always developed jointly with stakeholders and the project’s entrepreneurs. The PO’s role is to define the requirements necessary to implement the strategy that was agreed upon, to take care that these requirements are implemented, and to work with people responsible for executing it. And also to dynamically adjust the path the company takes as it keeps on working, according to the present situation, to best progress towards the objective until it’s ultimately achieved. Maybe, of course, as the project gets executed, we figure out that the goal itself is wrong. But in principle, the main responsibility is to discover what the requirements are, and to make sure they are met in the most effective way, and also help in the execution, and doing some operational tasks. And also approve things, take care of the work cycle. Check if everything is going well, redefine the work’s backlog from time to time, etc.
The Coder-Designer Complementarity
WLAD: During your career, you worked a lot in the middle of programmers. How was that experience? What is the major difficulty when dealing with developers, and what are the biggest difficulties programmers have when interacting with you? What you think programmers lack the most, in terms of skills?
LUCAS: Since design and development are complementary tasks, the more a programmer knows about design, and the more a designer knows about programming, or at least has an understanding of how the implementation process works, the less friction there will be during the work pipeline. Since I understand about development, it’s much easier for me to propose something that is actually reasonable to do, for instance. Also, I might propose things in a way that makes more sense in executive terms, so the plan I propose won’t need as much polishing, resulting in less going back-and-forth along the planning and design process.
The same is true from the programmer’s side too. Once the programmer understands more about user experience and usability, and gives more importance to certain details related to that, they stop seeing a given software requisite as an unnecessary affectation. “C’mon, that’s frills,” or “It doesn’t need to be that way,” are things we see a lot from programmers. So once the programmer understands the user experience requirements, it’s better. Also, the reverse can happen: the programmer can suggest trade-offs, like doing a small change that will disturb the user experience minimally, but will result in a great savings of implementation time. So today I have a very easy communication with programmers, and programmers that understand design also enjoy much better communication with me. Because I know a lot about programming, I also generate less resistance among programmers when we hit a wall. They know that I do understand their side. So even if they don’t fully understand my side, they trust that I’m being reasonable because they can see I understand their side well enough to consider it adequately.
Advice for Coders: Learn Some Design
WLAD: Got it. And how do you think the programmer can learn more about usability, and these other points you said that it’s good the programmer know to reduce friction?
LUCAS: There are several books and blogs that talk about this, from very technical aspects that are close to the programmer’s side, to very technical aspects that are much closer to the designer’s side, that are very specific. The resources I’m going to mention start from a broader point of view. I think it’s much easier for the programmer to read that instead of design-specific material; I think the programmer would find it hard to understand and apply things from designer-specific sources. So Smashing Magazine and the books they’ve released, the guys from A Book Apart, and a few others sources that I can try to add later, they tend to explain things in a better way for programmers. A programmer can also learn about design by simply understanding a bit more about CSS. The specification from CSS already includes many technical references to the world of design, so when you learn more about CSS, you inevitably learn more about design itself. For example, there are aspects of typography that are handled in CSS, especially in CSS3. Once you know these parts, you instantly understand more about typography.
WLAD: That process happened to me!
LUCAS: Right?! So not only basic things like font size and font color, but also the relationship between the kinds of measures in CSS—the m and other relative measures; the line height; all the spacings, for instance, between letters. These are all things that are handled in a book, or in any kind of editorial design. These projects require way more complex things too, but CSS offers a basic set of knowledge that is very interesting to know. There are relationships, for instance, between the font size and line height, that are very important. Another example is the relationship between the fonts that are bigger and fonts that are smaller; one tends to be a multiple of the other, and so on.
WLAD: Awesome. These things are mentioned in the book that I’m writing for programmers, in the interface and graphic design chapter. I put in many other very relevant concepts from typography.
LUCAS: Cool, cool. A List Apart also does this game very well. They really emphasize the aspects of design, but right along with it they also show you the relevant related code. Developers that work exclusively with front-end development these days must have a fair knowledge of design.
The Secret Behind Every Good Design
WLAD: What is the secret of a well-made design?
LUCAS: It’s the understanding of the problem. The definition of design is quite exquisite. As it’s a foreign word, for us it doesn’t encompass directly all the meaning that is originally associated with the word. Design is related to drawing, it’s related to project, and is also related to designation. And what is the purpose of any project? To fix some kind of problem or demand. Once the problem is very well understood, you start to realize some very important things, like for whom the project is made for; why; how it could be done; what are its limitations, including the technical ones; and more. These are also the matters that must be left really clear when you are doing, for example, an academic article. What is the objective, what is the motivation, for whom is the paper made, etc. With these questions clearly answered, it’s very hard that the design, the execution of the project, is outside from what was needed.
WLAD: I think, for instance, that the design of an iPhone is superior when compared to most other smartphones. I think both do have a crystal-clear understanding of what the problem is that a smartphone solves. Besides that, Apple’s design ends up being way superior. Why?
LUCAS: That is related to quality. And because Apple tends to be more proactive, and companies like Samsung tend to be more reactive. So Samsung, when seeing an already made Apple product, is unable to understand exactly the questioning and reasoning that led Apple to that design; they can’t do this reverse engineering very well. Samsung cannot comprehend which were the questions that led to the result that Apple created. That is very hard to do. Have you ever heard of the “Cargo Cult”?
WLAD: No…
The Anthropology Behind Design Mistakes
LUCAS: During World War II, the United States used a few nearly uninhabited islands that had a population of just a few natives as temporary military bases for their reach, proximity to the conflict zones, and other logistical reasons. And on these bases they made these improvised airstrips and airplanes would land. There was also a regular supply drop for the soldiers who were at these bases. It was usually done by air; planes would drop food supplies onto the island by parachute. A few of these would fall where the natives were living. Not understanding what a plane was, where it was coming from, and why, they would still love these supplies, seeing it as a gift from the gods. After the war was over, the bases were deactivated, the planes flew off the islands, and the military left. And of course, the air supply drops stopped. So what did the natives do? They built planes from wood and straw, resembling the military planes they had seen. In their thinking, maybe the gods would see these planes there once more in the airstrips, and once more give the natives food.
WLAD: Oh, yeah, I’ve seen that! The natives there, on abandoned airstrips, mimicking the gestures the air controllers would do to signal messages to planes, as if it were some kind of rain dance.
LUCAS: Exactly. So what many times happens when a company analyses a product from a competitor, in my vision, it’s almost like a “Cargo Cult.” They will try to make a smartphone that is similar to the iPhone, but not serving the same public, not having the same premises or values. And Apple is moved by a deep respect for the true properties of raw materials. That’s why Apple uses an excellent aluminum alloy with a spectacularly complex manufacturing process. The glass is really glass, and they deeply care about the glass’s purity. They don’t try to fake materials; they don’t work that way. So it’s part of the aluminum to eventually scratch, or bend a little. That relates to the normal use and degradation cycle of the product. And the product is very honest about that. And uglier than scratched aluminum is plastic painted in silver metallic ink that is scratched, revealing the plastic underneath.
At Apple there is a deep understanding that regardless of how much you might save by trying to keep the same visual while using cheaper materials, it’s not worth it. They don’t do it. Then you have a final result that has a much deeper impact. The user of an Apple product might not understand all that, but he or she definitely feels it. The product answers clearly these questions that were defined at the start, and that were observed since the beginning of the process. When you design an interface, or a system, or whatever, when the questions are well placed and very well defined, it’s very hard that the end product be badly designed because of these matters. If you are going to develop a system, who is going to use it? What is its purpose? Who are all the involved parties? How it would be better to join each of the pieces of information? What are the usage patterns going to be? In which machines will it be used on? Is it going to be used in a low-end computer? Maybe in a smaller monitor, or in a cellphone or in a tablet? By answering all that you start to eliminate possibilities. And by working with elimination, you can see that, for instance, in a given system it’s not practical to use an embedded font face, that it’s not realistic to consider a minimum resolution of 1920 pixels, and so on. By thinking in all these aspects, you start to have great answers to all your design matters naturally.
How to Survive if you Can’t Hire a Designer
WLAD: The holy grail of the average developer that has to work without the help of a designer is to be able to design a layout that is minimally well presentable to the user. So what do you recommend the developer do to have an eye-candy interface when they don’t have access to a designer?
LUCAS: I recommend using Bootstrap.
WLAD: What if it’s not a web project?
LUCAS: Then I think there aren’t many options. If it’s a mobile app, I think that you’ll really be limited to the default components; you’ll have to take the most out of that. Going back a little, if it’s about a new idea, and you want to test a business model, and you are going to make an MVP, if you try to answer clearly, “What am I doing?” and “For whom?”, having a basic understanding of how the app will be used, and with a little bit of aesthetic sense, any framework will do. For instance, Bootstrap, or even the default components of Android or iPhone toolkits, were designed to have a great level of usability. This is the best way out without doubt. You’ll be able to prove your concept, you’ll be able to test and have your first feedback, and then you can move on.
You can make a parallel of that problem with that of high-end construction without hiring a good architect, trying to build the house yourself. You’ll suffer from the same hurdles, you’ll have the same difficulties, and you are subject to the same errors and high risk of getting to a result that won’t satisfy you, at least at the same level of what a person who is a specialist—which is the architect or an engineer—would. The designer (or architect) is an investment that cannot always be made, but in these situations you must also question whether the work of the specialist is not being undervalued. Maybe if you’re on a tight budget it might even be possible to complete something without a designer, but I think in many cases it’s best to pay once for a good specialist at the start, than having to endeavor design efforts twice. Remember, you might compromise the results of the whole project by doing a design that has a quality that is way below what the project requires.
The Bottomline
WLAD: Any special message for our readers, any advice for the developers? What do you think a programmer can do to become an outstanding professional?
LUCAS: There is a very interesting analogy. A lot of people joke that the journalist is a professional with an ocean of knowledge that is just a few inches deep. I don’t think this is a bad thing. Expanding the analogy, if you have an ocean of knowledge, the things you’ve already mastered can be represented by a circle on this ocean’s surface. When you are a baby, you have a very small circle, and as you learn, you amplify the area of that circle by growing its diameter. So the more you increase this circle, larger your contact surface with the ocean is. The more you learn, more you become aware of what you do not know. I once heard that the teenager crisis, in which you think you know everything by the time you start to have a sense of your own personality, happens precisely because you realize that you do have some substance within, but you haven’t realized yet the vastness of what’s on the outside.
As you become an adult, as you study and mature, you start to gradually realize everything that’s outside, and then you’re always in an identity crisis, thinking, “I know that I know nothing.” The more horizontal knowledge you have, mainly the knowledge that is related to the things you know as a specialist, the easiest it becomes for you to relate to other people, and to perform the work in which you in fact are the specialist. So if you are a specialist in IT, have a notion of project management, have a notion of design, have a notion of computation at a deeper level, how the language you are using to program works, and in other related fields of knowledge, but not only that, you have a notion of politics, a notion of what you are doing in this world, a notion of psychology, of anything that interests you, I think it’s foolish not to run after it and learn a little bit. So in the same way, I say that knowing about programming helps me to do my work better. Maybe the programmer hasn’t realized this yet, but knowing about design can add more value than what he thinks it can.
