How to Work with your LPL Designer

First off, we designers really do want your feedback. It’s the only way we reach our objective. In a perfect world, designers would receive a project brief, have a kickoff meeting and then two weeks later come to the client with the perfect app that suits all their business goals and needs. That’s not plausible. The only way we reach our objective is when we receive your comments and feedback early and often throughout the process.

For us designers, a good critique can help us stay within scope, keep us from veering away from the clients objectives and goals, it helps the other team members by investing them in the project early on, and lets us know where there may be user frustration or confusion.

DESIGN FEEDBACK

Always bring the conversation back to the problem you’re trying to solve.

When giving feedback, consider this question: “How will what I am suggesting improve the way the audience interacts with the business?”

Don’t just mention the things that you like or do not like, this is just straight up lack of clarity. Ambiguity may feels safer when you’re mentioning things, but it doesn’t do anything for the conversation or the design. So, be specific about what you like or don’t like. I’f you’re having trouble articulating, express the feeling that a particular element invokes. if you say “for some reason I’m frustrated that the login button doesn’t exist in the nav” or “it doesn’t feel right to have this many CTAs on the landing page”… that is much more informative to us than “I don’t like it”.

Another form of design feedback that isn’t super helpful is when you take the design personally. For example, if you say “I don’t like purple” well, thats great, but the clients logo is this exact shade of purple and it makes sense in this context. Again, alway’s bring the conversation back to the problem you’re trying to solve.

Something else to avoid – design apathy. “It looks fine as it is, lets just go with it.” This may be something you default to because you’re not comfortable talking in visual terms. If you say this, your designer will probe you to dig a little deeper to understand your reluctance. Be warned.

Another thing to keep in mind – be careful not to make contradictions when giving your design critique. An example would be to say “we want a super minimal and straightforward homepage design, but we also need these 5 CTAs on the landing” A lot of the time this is the type of feedback a client will give, because they want to appeal to every type of person. Put yourself in the designers shoes, it’s not easy to hash through design feedback riddled with contradictions.

When you present a problem or concern to the designer, that doesn’t mean you also have to offer a solution.

You don’t need to have all the answers. In fact, when you do voice your concern, it’s good to let the designer make a suggestion. It’s our job.

LPL designers love when you use InVision. Simply put, it’s a tool that allows for problem solving constructed around a conversation of collaborative feedback. It’s a great place to make your comment directly on the UI, and then allow for the designer to respond with a well thought out defense, or suggest an alternative method of design.

Remember, designers are people too

Of course we want your feedback, but remember that we work very hard on what we do present to you. Try to understand our experience, everything from our frustrations to our goals within a project. We will work on doing the same for you. At the end of the day, this will help us create a report built on trust, and then we also don’t have to spend time trying to read each others minds and make assumptions about how everyone is feeling about the project.

CODING DONT’S

Try not to say this: “There were some problems with the front-end styles. Don’t worry, I fixed them.”

In general, it’s not the best practice to make changes in the final stages of a project without consulting the designer first. A seemingly innocent visual tweak can actually become an app-wide alteration. Why is this? Well, we front-end dev’s also appreciate super efficient code, and so we typically create a ton of reusable components all over the application. You can alter the pixel value of a property in just one class, and that change could be reflected in multiple locations in the browser.

&nbsp

The html files in a project are usually a communal space for front and back end code to live. Using “&nbsp” may solve your problem in the moment, but it ends up cluttering the code in the long run. Instead, articulate the issue you’re having to your front-end dev. They will know how to fix the issue targeting the right classes and using correct properties.

!important

Again, this is just a shortcut that may work for you in the moment, but the is almost always a better way to fix the problem. Communicate with your front-end team, people.

the break tag

Same as before. And the break tag especially is not very responsive.

×

Subscribe to Our Newsletter

If you made it this far, you should sign up for our monthly newsletter. Get our latest articles and insights delivered each month.

First Name*

Last Name*

Email*