It’s not uncommon for designers to introduce features that will overcomplicate the development process while bringing no additional value to the application. Focusing on the business objectives, project scope, timeline, and the way products are developed are all valuable considerations when prioritizing features for design.
If, for example, we’re designing an option for the users to upload a profile picture but we also add functionality to crop, scale, and rotate the photo, then this would unnecessarily complicate the design.
It’s effortless to add a “rotate” or “crop” button in design but would be trickier to implement in development. A safe bet is to avoid adding features unless they’re essential to the application. Always keep the business and user goals at the forefront of the design process.
When we’re designing a product or experience, we should take into account who else is going to be using our work. Whether our designs are handed off to developers or other designers, everything must be organized and appropriately documented.
Our design files should have artboards named and laid out horizontally how they would be clicked through.
We should have an organized design file that contains all the icons in SVG format and a high-quality version of any images used in our designs.
When I hand off my work to developers, Zeplin is my preferred method. Zeplin makes it easy for developers to grab code snippets, dimensions, spacing, font sizes, SVG assets, and so on.
There is a lot more that can be done for a seamless handoff, read Dorjan’s article on preparing for handoff if you’d like further insights.
There are various contextual factors that influence a user’s behavior when interacting with an interface. Consider where the user is when using our app, how much time they have, and what their emotional state is.
A perfect example of this is the sleep cycle app . The app has a calming dark display making it easy on the eyes and perfect for someone setting the alarm before going to bed.
You can see good and bad examples of this everywhere. Navigation apps have minimal reading or touching required, Kindle’s have no glare when reading outside, note-taking apps are available offline, and so on.
If our app is meant to be used while jogging, then some constraints and considerations need to be taken into account in the design.
The best way to ensure our interface and UX fit the user’s context is to test it in situations where it may be used and test it with users.
Shopify has a great article about designing with the user’s context in mind that I recommend for anyone interested in diving deeper into this topic.
Going straight to pushing pixels before validating our ideas or fully understanding the problem we’re solving for is an easy mistake to make.
This isn’t necessarily a wrong approach, but will often result in wasted time if the designs don’t work out.
Wireframing with a tool like Whimsical is faster and more lightweight when throwing ideas together and getting a feel for the layout and hierarchy of our design. It’s also harder to fall in love with a design when it’s only a wireframe so we can take criticism and feedback much more easily.
Designing a product is similar to building a public building like a library or a school — it needs to be inclusive to all. That includes blind, color blind, and visually impaired users.
Just ask Domino’s, they were sued by a blind man who could not access their website because it wasn’t accessible. Don’t be like Domino’s, design for accessibility.
Often we’re trying to design what looks good and neglect to consider the different users that will be interacting with our product.
As I’ve matured as a designer, I’ve come to terms with all the various constraints that will undermine my idea of a perfect design. ADA compliance is one of such constraints.
Shrinking text down to 8px because it fits our horizontal space better or using a light shade of grey because it looks nice is neglecting our vision-impaired visitors.
We can get away with this when we’re trying to score Dribbble likes, but it’s not a good practice when developing a product for real humans.
Web Content Accessibility Guidelines (WCAG) requires at least 4.5:1 contrast. There are also guidelines for motor, auditory, and cognitive disabilities.
To ensure you’re meeting these standards, download Stark which will check if your designs are accessible or not.
“Trends are like junk food for designers. Following them produces cheap solutions that offer some initial payback but little value over the long haul. Trend-following designers date themselves quickly. The reward for following someone else’s design path? A gnawing sense of professional emptiness.” — Micah Bowers, Designer
It is easy to get caught up in the Dribbble world, and all the pretty animations and gradients, then quickly forget about the objectives of our design.
I’ve certainly gotten hooked on a particular interaction or design style that I found on Dribbble and tried to make them work in my design. Finding inspiration on Dribbble and elsewhere is great, but being inspired and blindly copying a UI component because it has a fresh look is not the same.
“Any time conventions are broken, it takes more time for a user’s brain to process the new content. Designers need to take the limitations of human cognition into account, as well as the reality of limited working memory.” — Joanna Ngai, Designer
Users have come to expect similar experiences across the web. If our website, app, or software functions differently than what users have grown accustomed to, then it won’t be intuitive, and they will likely become frustrated with the experience.
An example of this is icons with an established meaning behind them. Icons like “search,” “home,” or “favorite” are represented similarly in the vast majority of interfaces. By using non-standard icons to represent these actions, we run the risk of damaging our user experience and causing a headache for users trying to use our software.
One thing every UI designer hates doing is breaking their designs.
Breaking a design essentially means to input data that would ruin the layout or aesthetic appeal of the interface. This can be uncomfortable to do as a designer, but it’s a crucial component to designing a flexible, scalable, and user-friendly product.
When the mockup I sent to production has a six-letter first name, it probably looks great, but what happens when Hubert Blaine Wolfeschlegelsteinhausenbergerdorff Sr. tries to use the app?
Test designs and take a step back while designing to ensure that the interface can fit a wide variety of use cases, not just the ideal ones.
When designing for development, missing states will either create a gap in the experience or will need to be filled in by the developer. This can often create inconsistencies in the design and hiccups down the road.
We need to account for all of the different states that are possible such as error, success, active, disabled, hover, empty, filled, loading — to name a few.
If I were designing a wishlist, for example, I would need to consider the state before a user had added anything to their wishlist: the empty state. Without this state, there will be a gap in the experience.
By leveraging components already built into products, we can provide users with a familiar experience and avoid input errors.
Regardless of how good of a designer we are, it can be hard to justify designing a calendar date picker from scratch. Even if ours is objectively better, the user still has to learn a new component when there’s a perfectly fine one built into their device. It also requires additional development and design effort to create a component from scratch.
Native components are a no-brainer — use them to save time and effort for our team and reduce friction for users.