I like to start from real row data. It can be text in a google doc, or a raw html page with text, buttons and inputs. I will then play with typography, colors, spacing, polishing a bit by bit they way the content is displayed on the page.

In a traditional design process, designers use lorem ipsum or imaginary data that fits nicely the design they're producing.

When an engineer plugs real data in the designs it will start to look broken, since the design didn't account for the real shape of the data. For example a user name may be too long or too short, a user may have one address, or none, or many.

Often a static design doesn't account for all states because a designer is now aware of them while their designing.

By designing using real data, I can immediately see many of these possible states and edge cases. I will then optimize the design accounting for all of those.

I believe it is faster to design in Figma.

A designer in Figma is able to produce countless more designs and variations of a page in the same amount of time it takes to build the same page in code.

These quantity of designs presented will surely make a client happy, giving the erronous impression all of it will be built.

In the past, of all the quantity of designs I was able to produce at high speed in Photoshop and Sketch, only a handful would be built.

Building takes time and many of those designs were usually sacrifized. Very few were selected to be built within the available timeframe.

After built was complete, those few pages looked degraded compared to the original design. Since the real data is incomplete or different compared to the lorem ipsum used in the desing, an edge cases unknown during the design phase, a frontend engineer had interpreted those edge cases in a way that did not look harmonoius with the rest of the design.

I today prefer to focus on only one version of a desing and build it straight in code. It will upset managers because they won't have the chance to pick between different options as they used to do in the past. It will also take from the date I start work, to the date I'm able to present that single option, but I swear the end result will look much better then how it used to with the process used in the past.

That's how I feel about the pages I build today. They take longer, may not look as dribbble-esque as some designs I produced in the past in Photoshop or Sketch, but the final built page will look and feel much better.

In the past, I would have taken a week to finalize the design of a page. Then the design would waterfall to an engineer and it will take other 2 weeks to receive the page built in code.

When the engineer codes the page, would notice the design didn't account for edge cases. It accountent only for a "best case scenario", which is different from truth. For example, there is no user avatar available, or an user address is much longer then what accounted in a design, or a list is made of very long blocks of text next to short ones.

At that point, the engineer can choose to get back to the designer every time there is a state which is not accounted for, or tweak the designs to make it work with real data.

If the engineer decides to go back to the designer each time, it will delay significantly the delivery of the page. Each time, the designer takes some time to adjust the design. May need to revise a couple of unrelated things, based on new information provided by the engineer, to make sure the whole system is cohesive. It will then waterfall back to the engineer until the next unaccounted state is found.

If the engineer wants to move fast, may tweak the designs to make them work with real data themselves. Most of the time the designer will find, once the page is shipped, how it differs from the original design, they will feel frustrated as the added design touches seems to not fit as well with the rest of the design.

By designing straight in code, I stumble across different states and edge cases and shape my design immediately based on these new findings. The ping-pong between designer and developer is much faster, it just happens very quickly in my head. I can craft the design to make it look as good as possible with the real data available. I save myself the frustration of seeing a build weeks or months later which differs from the designs I initially invisioned.

Let's make a rough estimate of the total time it would take from design to build

• Option A

  Traditional design process with GOOD collaboration beween designer and developer

  1. Designer designs in Figma+1 week
  2. Engineer builds in code+2 week
  3. Back and forth between designer and engineer about edge cases and unaccounted states+2 week

  Duration

  Duration

  5 weeks

  Outcome

  Designer is happy. Developer is happy. Page shipped.

• Option B: Traditional design process with BAD collaboration beween designer and developer
  1. 1. Designer designs in Figma (+1 week)
  2. 2. Engineer builds in code and tweak the designs autonomously to make them work with real data (+2 week)

  Total 3 weeks. The designer is frustrated because the built page looks different then designs. The engineer did the best they could and feel their work unappreciated by the designer. The engineer thinks the designer did a bad job at designing.

• Option C: Traditional design process with WORSE collaboration beween designer and developer
  1. 1. Designer designs in Figma (+1 week)
  2. 2. Engineer see the designs and pushes back, because they don't work well with real data. (+1~ week)

  Designer is frustrated because their page doesn't ship. All is left is their visual to put in a portfolio. The engineer is frustrated because the designs provided are not realistic, can't be build.

• Option D: My design process
  1. 1. I design and build in code at the same time, using real data (+3 weeks)
  2. 2. A Full-stack Engineer help connecting to the backend parts that are out of my skill level. (+1 week)

  Total Duration

  4 weeks

  Final outcome

  I'm very satisfied with my work. I think I made it look best I could with the time and data I had available. I am happy because I am shipping stuff! Full-stack engineer helps connecting some data, he / she is happy too because it ships.

I feel overall my process, from design to launch, takes less time and leads to no frustrations, at least on my end.

As a designer, I've been most satisfied of the work shipped than most of the other times my designs remained unbuilt in Sketch, or built with a subpar way.

My objective is to build products that look good and are delightful to use. I try to create little wow moments via subtle animations and illustrations. Instill trust in a brand an product via a clean and clear ahestetic.

The design should "pop" and have some sort of energy to it.

The information should be clear and accessible.

The user should be pleased to interact with the product.

No, at least not immediately, when called on the spot.

I usually design by instinct. For certain design elements, I repeat patterns tried and tested before on previous projects.

I don't know from the top of my mind why I used a certain quantity of space around an element.

When suggested to try a different approach X, I realize I have already tried Xin the past and landed on a particular roadblock.

I would say I developed an instinct of how a component should be designed.

After designing the same component over and over again, I developed a muscle memory for which I already know which direction to go.

If I am asked to rationalize, I can think about it and finally find the reason, but usually I can just get going and design without thinking about things too much.

I would like to focus on visual design and frontend code, ideally as Principle Designer.

I would like to own a particular product and have freedom to develop its look.

I really enjoyed being the first Designer and Frontend Engineer hire at small seed stage startup.

It allowed me to setup design and frontend in a way that is compatible with my hybrid way of working.

I would ideally find a similar opportunity as Founding Designer and Frontend Engineer at an early stage startup.

When I was working in design tools like Sketch or Photoshop, I will sometimes add to my designs hover states and animations idea.

The engineer tasked with building the design will most of the time not have enough time (and skills) to implement them, so they would never make it into the final shipped site.

In the rare case an engineer would take the time to add a hover effect or animation, it would not look good when build in code.

For example, a designer would make a hovered background color on a button dark enough so that a difference is visible when the two buttons are next to each other in Figma. When the hover is implemeneted in code, when hovering the designer finally notice the difference between the two colors is too pronounced and jarring. That doesn't look good! And good luck now opening a ticket, asking to tweak the color based on revised Figma designs, just to find out it is still not good enough if the button is updated to the newer lighter shade!

For subtle little tweaks like this, one has to be in code, tweak in code, and take the decision from how it looks in code.

Other times, a designer would fade between two very different shades. When the animation is finally implemented in code, color A fades to color B by passing through some murky in between states. That doesn't look good either.

In the lucky case an engineer adds an animation, often time it is too slow. When seeing the animation live on the page, now it seems like taking too long, for example a button reacting on hover. For a button which a user will interact with multiple time, a much more snappy animation needs to be used. Unluckily, once the animation gets implemented and the page shipped, it is already too late for the designer to realize it needs something quicker. Both designer and engieer will most probably already moved onto new projects by then, and the animation stays like that, slow and janky.

Only adding animations in code I found I was able to get a real feeling of how it would look and feel. I would be then able to tweak it numerous time until reaching the right amount of snappiness and craft.

Pixelpushing is an art dear to the heart of visual designers. When I was working as visual designer in Photoshop I would take great pride in aligning pixel perfectly so that they looked as sharp as possible.

Looking at a blurry visual element, two lines of text not aligning vertically, an inconsistent padding, would trigger frustrating reactions in the eyes of an OCD pixelpusher designer.

Personally, I always tried to pixel push best I could, admired visual designs of peers that looked particularly crisp and precise, and "ribrezzo" at photoshop or sketch files that were messy, blurry, and unpolished.

In code, 99% of the times a website would loose all its pixel pushing. Paddings and margins would become wonky, text out of alignment, icons blurry, and so on. It is rare to land on a live page and be surprised by an overall clean ness and attention to details.

I feel for an engineer, it is more important a page works, text is visible, a button redirect to another page when clicked, functionality is assured.

Pixelpushing is a "frivolezza" that is very time consuming and doesn't particular contribute to the functionality of a desing.

For these reasons, I feel rarely an engineer will pixel push a live page. Most of the times, pixelpushing will be a frustrating experience where a designer sit behind the engineer back askign to move something few pixel up or down.

I felt myself many time how unpleasant it is to have a designer behind your back asking to move things around few pixel.

I found pixelpushing is something you have to do yourself. It require extra patience, time, and it is very personal in taste. What for me should be 6px, for another designer could be 8px. Just following blindly a proportional spacing scale may not work perfectly either. There are cases where an icon needs to be 6px left (rather then the usual multiple of 8), or an icon needs to be vertically shifted a pixel or two to proportionally align correctly with the element next to it.

There are ratios, proportions, mathematics, but also perception. Something needs to look like it is aligned and in order, doesn't mean it needs to be exactly a multiple of 8 all the time.

To conclude, pixelpushing is something most of the times you have to do yourself. If a designer design in Figma, can pixelpush the Figma design as much as he / she wants. But when the design will be recreated in code, it will be the engineer pixelpushing that will make it to the live product. Needless to say, as pixelpushing is an art not very popular within frontend engineers, the final built product will rarely look clean and crafted to the eyes of a designer. Unless is the designer that executes the pixelpush in code him/herself!

By designing in code, I can pixelpush the live page, the one the user sees. I can decide to spend extra time to make it look extra crafted. And all that craft won't be lost in the passage between design and engineering.

I wouldn't say I do UX. I think I'm strongest in Visual Design and Frontend code.

In a very small company, where I would be the only designer, I would rely on the Product Manager for insights on what feature to build next. I would prototype the requested feature and subsequentially iterate it quickly based on feedbacks I receive via the Product Manager.

As the company grows in size, I would leave UX research to a dedicated resource, while I would focus on Visual Design and Frontend Code, ideally in Pricipal Designer role or similar.

What today is expected from a Product Designer is to conduct user research, make designs of interactions, validate them with real users, send them to engineering. Then continue to iterate on it by doing more user testing and addressing findings with revised designs.

I always worked instead as visual designer. I would take something that already exist, for example a pre-existing older website, or a google doc with text, or a wireframe, and iterate on the design to make it more attractive.

In startup world, I can come and reskin a page that already exist, or I can start from a rough wireframe or google docs provided by the product manager, and prototype it into a better looking full fledged feature.

I feel this differs slighthly from the job of a Product Designer. I am usually not defining a problem and finding a solution. Usually I am restyling an already existing solution to make it look more attractive.

The tendency now in startups is to stuff the product team with Product Designers. As the Product Designer spans from research to hi-fidelity design, there is not much meat left for me except building the hi-fidelity designs of the Product Designer.

But building someone else's design means I will not be free to practice my own pixelpushing.

I will rather have a designer seated behind my back telling me how to push pixel left and right, and I will not be free to use my design judgement on the spot every time an edge case and unaccounted state appears. co

I have been working in agencies and startups overall for 15 years and most of the times they would place me within Visual Design. Although I have no formal education in Visual Design, I always strived to make something look good. The usefulness of a good looking design is hard to prove, but we all feel sometimes we want product X rather then Y because X looks cool. A cool looking car, or a nice pair of shoes, do not function any better then other cars or pair of shoes, although we feel an impulse towards a product rather then another.

For an agency, having a design look good is important. The client will be presented a campaign or site and there are good chances one will be picked over another just because it looks better.

In an agency, it is important to have Visual Designers. A creative idea may be concepted by an Art Director and a Copywriter, but still may pass through the Design Studio to make sure it is made look attractive enough.

The objective of a visual designer will probably be to make something look good, as for the sales person the most important objective is to sell.

The objective of a UX designer instead will be to advocate for the user need, make sure a site accomplish what the user wants to do.

Having both roles on staff, someone that responsible for making a site look attractive (the visual designer), and someone that accomplish user needs (the UX designer), makes sure both prospectives will be taken into account.

No. I always had negative experiences with take home tests, so I usually refuse to do them.

Portfolio, portfolio, portfolio.

What you see here is what I have done in the past. If you have technical questions about how I built certain components, I'll be happy to go into more details during a call.

It takes me a good amount of time to build and update this portfolio over time.

I have been evaluated many times, when looking for a job in advertising, by looking at my portfolio.

I have hired young design engineers by looking at their portfolio. I evaluate technical skills by looking at their past projects. I evaluate culture fit by talking over the phone about their aspirations.

If you don't see a particular skill you're looking for here, them most probably I don't have experience with it.

Luckily sometimes a company is in real need to hire, call it desperate 😂, and willing to skip the test.

90% of the times, I won't be able to proceed in an interview process because I refuse to do the test. Still, the remaining 10% has been willing to take a chance on me. I have been lucky enough to always find a new job within 1 to 4 weeks.

I feel those who believed in this portfolio and my words got enough value back having me part of their team, for however long it lasted 😇.

Few times I got let go or even fired. Funnily enough the same company that fired me reached out again years later offering me a new opportunity.

Once I received a terrible performance review from a colleague. A year or two later, the same workmate recommended me warmly for a role at their new company.

Recently I've been finding jobs through word of mouth. Past workmates would employ me at their new startups. Luckily this way I don't have to do any test.

I would examine the portfolio, look at past projects, and ask questions about the design and the technology used.

If the candidate does not have a portfolio, I would expect them to be able to shop a couple of past projects they worked on.

A personal project can work as well.

I would want to know what the candidate contribution was.

By looking at previous projects, I would not need to ask a candidate to spend any personal time on a test.

The candidate surely had chance, while working on a past project, to learn about it and iterate on it.

By asking the candidate to work for 8hrs on something new, we may not get the quality a candidate can offer when fully ramped up and familiar with a project. How can a candidate learn, in 8hrs, a new technology or a brand we interviewers have already familiarized with for months?

I can't think of any easy enough test a candidate could successfully execute in less then two hours.

Usually when asked for a test, they suggest me to limit the time spent on it to 8hrs, but if I feel like feel free to spend more.

Once the interviewer added "just do something like the work in your portfolio"

Well...most projects in my portfolio took days, weeks, months to get there.

Behind most visual on my portfolio, there are countless hours spent learning, trying, iterating.

I don't think you can get anything good done in 8 hours.

I'd have to be lucky to be able to go from nothing to portfolio quality in 8 hours.

If the interviewer is expecting me to return in 8 hours with a portfolio quality version of their site, surely they'll be disappointed.

I also have a full time job while interviewing for another company.

Taking 8 hours for a test means, after a busy week of work, using saturday or sunday to do the test rather then resting and spending it with your partner.

I usually interview with many places when I'm open to opportunities. I may interview with more then one company a week. If I had to do tests each time I'm asked I would have to spend my holidays and free time doing unpaid tests!

I have been asked to re-design the MTA website, design an iPhone to track a new born key moments (see here).

This is something I've never really been passionate about. I like to build, iterate based on cause effect, real things, that ship in response real to user needs or feedback. Unsolicited redesign is something I've never practiced. Very helpful for someone that just started her / his practice. Very useful to go on Dribbble and try reproduce a good looking visual, applying it to an imaginary product.

I have been asked to redesign a summary page listing user made learning resources (see here). Another time I've been asked to design a summary page of incident tickets a la jira (see here).

Another time I had to redesign a group chat mobile app.

I have have seen, as interviewer, the candidate be asked to re-design a page of our site. The page was a summary of the user personal information.

In this kind of test, the interviewer has history on that page, knows what it has been tried before, what worked and what not, why it did not, what the business, legal and technical constraints are. The candidate instead knows nothing about all those and will most probably land, by logic, on solutions that have already been tried before.

The designer solution will most probably end up being something already tried before, a primitive solution, lacking innovation.

The test has high chance to not land on any innovative solution, but rather fall into the same pattern already tried, or make mistakes already made, anyway disappoint the interviewer.

The solution will also luck craft and make some banal mistake, due to the shortage of time spent on the design.

The candidate also has time against.

While the interviewer's team had months to iterate on that particular feature, the candidate has the "suggested 8 hours".

8 hours never allowed me to have enough time to make a good research of competitors' patterns, land on something innovative and craft the UI enough so have a polished "portfolio quality" result.

In those 8 hours, the candidate has to be lucky to land on a good looking execution that the interviewer's team did not land on in months. I think this test is doomed to fail, especially if the candidate really spends just the recommended 8 hours or less, unless he/she sinks some real quantity of hours or effort into it.

I often get asked for tests after a successful first round with my new potential direct manager. When expressing concerns about making a test, I get reassured by saying the test is "just a formality". My future direct manager already liked me much, now it just needs this formal step to prove to the rest of the team I can get the work done. The rest of the team was sometimes other designers, or a co-founder / CEO, or marketing, or engineering.

In this particular case, the design team was all composed of UX designers and din't have anyone focusing on visual. I was being recruited to focus on design and UI, so that the product could look more bespoke and polished.

Assured by the fact the test was just a formality, I spent at least 8 hours of my weekend on a quick layout refresh for their summary page (here). When I presented it in front of the 3 other ux / product designers, I've been steamrolled on of why I picked a certain color for underlines and other design choices I made by instinct, rather then reason. Finally, the UX team was not impressed by my test and their manager that was so sure I was the right one had to pass on hiring me.