Why To (sometimes) Rush Initial Design

Disclaimer–every agency, project, client, and designer are made differently and should not be treated all the same. The following is just one solution that I found unique. Written from a UI/UX designer’s perspective.


So you’ve just landed your agency a sweet gig, you’ve had your discovery meeting and you just sat back down at the office. There are several reasons why I believe (in certain situations) it is best to rush your initial design / wireframes and get it in front of your client as soon as possible.

 

1. Your Client’s Nerves

It is easy to forget that not everybody lives in this crazy project to project world that we do. In fact, unless the client is on retainer this might be their first experience with you, or even with the creative/software industry in general. If that is the case they may be very anxious to get comfortable with your work and process. If you have a discovery meeting and don’t show your client anything for several weeks, the client will probably experience some nervousness; are you going to make the deadline? Have you started working on it yet?, Did you just run off with their money? Also, the longer you wait, the more the client will expect. If you show them rough wireframes right off the bat, the precedence is set and the pressure bubble is popped. If you were to wait, the client may expect higher-fidelity mockups or finished products.

 

2. Your Nerves

The longer you wait, the more you feel that you should complete more prior to showing the client. However, its tough to begin working on details if the client hasn’t already ok’d the general layout/feel. The more time you invest before this initial design unveiling, the more is at risk for misunderstandings.

 

3. You Can Begin to Have Real Conversations

Having some design or wireframes can help drive productive conversations with the client. Post discovery conversations with clients without design will usually run stale, unproductive, and repetitive. But with design/wireframes/sketches, the client can begin to visualize their idea, and can help come up with new ideas, suggestions, and features. Designers should always do research on the client’s industry/field but the client will probably always have a better understanding of their own industry, and allowing your client to have part in these conversations is vital.

 


 

Where The “(sometimes)” Comes In

As I mentioned in the beginning of this post, agencies, designers, projects, and clients are not all made the same. If a client has hired you before and there is a trust there, the client may not want to see anything until it’s further along. Don’t always treat a client like a new client.

Sources — Andy Mangold from “On The Grid” podcast

Floating Labels– With Only CSS

Preface–I am not a developer. A designer, born and raised with some front-end experience, with limited JS knowledge, I like to find pure CSS solutions for fun.

Floating labels really took precedence with the launch of Google’s Material Design. They have been widely accepted because of solving the age-old UX argument between multiple form input field solutions.

 

What is a Floating Label?

A floating label is basically an inline label inside of an input field that floats above of the input box upon interaction. This enables the user to still see what the input field was originally requesting even after they have typed their answer.

 

 

Example of Google’s floating labels

 

Before these floating labels became popular, UX designers went back and forth between inline labels and right/left aligned labels. Inline labels were great for scan-ability and condensing information. But they fell weak after the user interacted with them and could no longer see what the input field was requesting. The floating label combines both of these solutions into an awesome user experience.

 


 

How

There are many ways to incorporate floating labels into your form. This way is CSS only (ofcourse) and it’s actually quite simple. So simple, in fact that you only really need 2-3 css classes.

My basic HTML:

The container div is optional. Be sure to add “required” to your <input> tag

 


 

This first class is mostly optional, the class for your <input> tag:

 


 

The second class determines how your <label> will look prior to user interaction:

 


 

The third and final class is just styling how the <label> will change upon user interaction:

 


 

And you’re done! Yay!

Below are some codepens that I put together to help you. The first one listed is a super basic example using the same 3 styles that I described above. The second is an example of how you can fit floating labels into your design.

Enjoy!