Over the past 10 years of my career as a programmer, UI/UX designer and project lead with AppIt Ventures, I have taken part in building more than 300 apps. I want to share a few tips that I've picked up that can help designers heighten the quality of their output. Enjoy my UI/UX designer tips!
Over the past 10 years of my career as a programmer, UI/UX designer and project lead with custom software development company, AppIt Ventures, I have taken part in building more than 300 apps. Throughout those projects, I have worked alongside many designers, including those within our organization, from design agencies, from client teams and freelancers. In my observation, there are some very common mistakes designers make that can result in increased development costs, poor application performance, late-stage changes, and disorganized design files; so, I want to share a few tips that I’ve picked up that can help designers heighten the quality of their output.
Designers, whether they’re working as freelancers or at design or custom software development agencies, are always excited by the opportunity to work on multiple projects (or multiple items in a single project) at once. In addition, there is often an external pressure to work on as many projects as possible or get the existing ones done in a condensed time frame; unfortunately, this overload often leads to quality taking a back seat, which in turn hurts the rest of development process.
So, what exactly do we mean by quality? Quality in UI design doesn’t only mean good aesthetics. When you’re working on a client project, always keep in mind that you are trying to solve a problem – your solution should be well thought out, maintainable, and scalable, so that even when you’re finished working on the project, your work/solution still helps the client. Remember, it’s not about you, it’s all about your work.
“Quality is never an accident. It is always the result of intelligent effort.” — John Ruskin
Building great things requires intense focus, time and effort, so taking the time you need to do it right is not a weakness. When you’re under pressure, do not shy away from telling your boss(es) that you need a certain amount of time to produce a quality solution.
Clean — remove unused and group elements properly.
At AppIt Ventures, we use the SKETCH app to design mobile and web app UI. Hopefully, most of the tips that follow can also be applied to other tools like Adobe XD, Figma, Photoshop, Illustrator and other popular design tools.
Always have an appropriate name for the design files, pages, art boards, layers, groups and symbols you have in your project. Follow a naming convention that works well for you and be consistent. This sounds silly, but designers often tend to neglect these basic things, because it’s a non-creative task and takes a little bit of time up front. That is a mistake – grouping layers as required and having proper naming conventions in your design assets helps you, your team and the client in the long run. When your work is more readable, it is easy to maintain, helps instantly identify elements, and allows for quicker updates regardless of whether it’s you or another designer who steps in to do them.
Tools like SKETCH have useful features like SYMBOLS. If you have a component that is reused in multiple screens/pages, when you create a symbol and use that instead of copying and pasting the group, you’ll save lot of time on editing/updating that element. If you want to override the contents in a symbol, like text/image, SKETCH has a feature called OVERRIDES. These types of features were added to design tools to help designers manage their work better, save time and spend more time on the creative tasks they love.
Though they might initially take time to setup and organize, you’ll be more productive in the long run, saving loads of time and effort.
When building the UI for a mobile or web app, most designers ask the client which data elements need to be shown on the UI. For example, images, titles, descriptions and other labels. Once they confirm the data elements, designers start building the UI with placeholder text and images.
The problem with this is that while the UI may look great aesthetically with the place holder content, when you start developing and real time data comes in, you may notice that the app no longer looks the same. There are data limits that the designer may not have thought of. For example, can the title be empty? How does the UI look when the title is empty? Do we need to show anything like “N/A” when the title is empty? If we have a list of items and we need to display the description of each, what should be the max number of lines? What happens if the description is just one line long? Does the UI adapt to the situation? If the designer considers all of these cases when designing the UI, it can be designed to be adaptable; therefor, it is critical that designers pay attention to the details like data rules, behavior and limitations.
Designers often forget to consider the occasional UI state when there is no relevant data to be shown to the user, called empty state. Empty state may be indicated with such phrases as, “no matches found”, “no new notifications”, “empty inbox/trash” and so on. Error state is similar to empty state, but is caused by technical errors, like when there is no internet connection, when the API is broken or when there are errors in user inputs.
There are many instances of such UI states with real time usage, so if designers take the time to think through and design these states within the app they are building, users will have a better experience. As an added bonus, designers may choose to add delightful elements to these no data states to help create an emotional connection with users. As with no data states, designers should also put thought into how the successful states, like the welcome screen and successful transaction screen, come across.
In this digital world, mobile screens and web pages present designers with plain canvases on which to create UI elements representative of data or actions. As creative types, designers often become preoccupied with the newness or uniqueness of the aesthetics when they begin building an application’s UI, just for the sake of standing out. The fact is, you have to be creative only when it’s truly necessary.
For ex: Use custom fonts in mobile apps only when it’s required for the application. iOS and Android teams have put an incredible amount of thought into the default font each OS offers (Helvetica/SF and Roboto, respectively). These fonts have been specifically chosen for better readability on many form factors like phones, watches, tablets, televisions and the web. Never use custom fonts just for the sake of branding or novelty. If you do decide to use them for whatever reason, be sure that the font works well on all the aforementioned form factors/devices – if not, it’s better to stick with default fonts.
Some Android devices, like those from Samsung, allow users to choose a custom font for the entire phone. If your app uses its own custom font, it won’t adapt to the user settings. While neither exclusively good nor bad, this is something to consider when choosing between default and custom fonts.
Apple has it’s own Human Interface Guidelines (HIG) for macOS and iOS. Similarly, Google has its own Material Design Guidelines for Web and Android (even iOS, too). As a designer, you’ll need to go through these guidelines and refer to them when designing UI for iOS and Android. When designing an app for both platforms, every screen will have the same content but how you represent it will differ.
Input fields and Tabs in Android look and behave differently than those in iOS. Android incorporates a Bottom Navigation View and a Bottom App Bar. iOS has a Segment Bar, which is sometimes equivalent to Tabs and other times to Radio Button in Android. iOS has Data Pickers vs Android’s Bottom Sheets. Android has Checkbox, Radio Button, Toggle and Switch, where as iOS just has a Toggle. When you design for these platforms, you must be careful with these UI choices. Your app users are familiar with their own device and its particular OS behavior, so when you bring a new pattern or a pattern from another platform your app becomes an alien to that user. Respecting platform guidelines and sticking to them leads to better quality in design.
It used to be common practice for companies to ask their designers to create the UI first, without any input from software developers, and then hand off the design files to the developers to create an app or website. Though it’s no longer ubiquitous, it still happens.
There are several problems with this practice. For instance, designers may not be fully aware of platform restrictions, like how their creative UI elements affect the performance of the app. They may not know how much battery life the app will consume due to the animation they want to use. They may not know how the backend APIs have to be changed to meet their design, how their designs impacts the project timeline and how all these put together impact the final user experience due to the compromises that have to be made in the app architecture.
To minimize any negative impact of your design on the overall solution you have been part of, it is wise to involve the developers as early as possible in the design process. It will allow you to become familiar with how things work in the backend and understand the reasons why developers may reject a particular proposed design idea. Always remember that the final solution you all create as a team is much more important than your own design.
At the end of the day, your goal is to solve a problem for the client as a team. Designers and developers can create great products when they communicate well and work together.
In summary, try to get your developers involved in your design process. Get their feedback on your design ideas early on, and most certainly before sending it for client approval. Be open minded about the criticism you get – it will help you correct, improve, evolve and design great products.
There is one more way that creating custom design elements without regard for the implications can negatively impact a project, and it deserves a special mention.
Clients are often unaware of the impact that their ideal design ideas or features might have on the cost of the development. Designers should check with developers to find out what type of effort it would entail to create the wish list and inform the client before working on designs. This process will help set proper expectations for the client and avoided wasting time on designs that aren’t practical.
Further, many clients are also unaware of how design decisions affect the overall products. They share their personal taste or inspiration with the designers and want their product to look similar. This is not a problem so long as they give some liberty to designers and respect their final design decisions.
As the expert, it’s a designer’s responsibility to explain the reasons behind a particular design choice and remind the client that because every problem is different, it is important to design a unique solution. If your product simply copies a popular design approach, it won’t stand out in the crowd. Additionally, it isn’t just the aesthetics that make a product popular; a problem with a unique solution that has a positive impact on final user experience will be more memorable than a copycat product. As designers, try to brainstorm with the client about what already exists and how the new product will be different, citing proper examples and case studies.
I hope designers out there find these tips beneficial and help improve their design practices for better quality UI designs. If you have any opinions to share, feel free to drop them in comments.