5 Mistakes to Avoid When Designing an Application

Introduction

Whether you design for clients or part of a product team, I’m going to share some of the pitfalls I’ve run into during my many years as a UX designer. Now you don’t have to be a designer to understand and share some of the agonies these mistakes have caused during the creation of a software product. All parties involved feel this, such as engineers. Try to remember, the designer-to-engineer ratio. It could be 1 designer and 6–10 engineers. Can you imagine your 1-month worth of work, could possibly turn into 3–4 months worth of development work that goes sideways? That’s why I’m writing this…to hopefully help you.

‍

‍

‍

Mistake 1: Don’t assume you know the product intimately

‍

As a UX Designer, we are detectives, investigators. Our job, when a new application lands on our laps or possibly a large feature, we want to first ask ourselves “Is our thinking aligned with the business and goals?”

These steps are not all required, and they depend on whether you’re building a product from scratch or redesigning an existing product.

• Become familiar with the expected users
• Interview stakeholders and understand what they are looking to achieve
• Interview users and identify their existing problems
• Invite others to some card sorting meetings to help identify and/or prioritize features

‍

We need to become familiar with all users, stakeholders, as well as the business goals and KPI.

Who’s impacted by skipping this step?

Design Team

• You could be asked to redesign from scratch cause your entire approach was assumed and was wrong
• You could waste the time of other resources investigating or having meetings, just to end up redesigning it all

Dev Team

• Identifying inaccurate backend development work
• Research time that takes time away from other priorities

‍

‍

‍

Mistake 2: Don’t rush the info architecture

‍

What I see so often, and I’ve done this myself, is automatically assuming that this step is possibly a one-round process due to its minimal effort. In these stages, many people might not be as familiar with specifics and the navigation, especially this early into the design process. So, you may get a lot of nods that it looks good which is also due to the eagerness of wanting to see some actual designs of screens. But this stage is critical for getting engagement from the product owner, stakeholders, and especially your lead developer.

‍

This is the stage in which your lead developer needs to be completely aware of what you’re proposing. They’ll also be a great partner in bouncing ideas off of.

Areas you want to identify:

• User personas
• Use cases / user flows
• Data that might require backend development (especially new data)
• Create a flow diagram to identify the navigation (aka sitemap)
• Create diagrams for flows that require complex interactions and features (i.e. Login, Account Creation, and 2-factor authentication)
• Discussions around 3rd party services such as authentication or payment submission. Maybe your engineering team has little resources and can’t build it all from scratch.

‍

‍

‍

Mistake 3: Don’t skip wireframes

‍

Maybe you have an established design system and this gives you a great excuse to jump into UI. And it is a great reason to skip wireframes. I even do it for pages such as a new list results page with standard filter and sort features.

However, if you have a new design that requires new features not yet explored, and a product team, and a leadership team, and possibly user testing — with all those factors, your time is best spent producing multiple options quickly and never focusing on pixel-perfect efforts.

But wait, that’s not the only excuse. When all teams involved and leadership review your options, you want them focused on the user experience only and not worried about any UI details. When you put UI in front of them, you could have one person ask a question in a meeting that derails the conversation for 20–30 minutes which is not what you wanted the focus on. You want everyone to focus on the user experience. I’m pretty sure many of you can agree on this situation happening.

‍

‍

‍

Mistake 4: Don’t skip creating a design system

‍

You may have direction from leadership or a product owner that you need to speed up your design process to meet deadlines so that developers can begin. Out of about the 5–6 times I have done this, it has failed.

Why does it fail?

• When designing from scratch (not using an existing design system like Material or Bootstrap), you’ll often run into conflicts such as a flyout menu not matching your side menu (as a small example).
• Once an engineer starts, it takes them much longer to fix the UI than it does for a design team to adjust the design (And I don’t mean changing color or font-weight). Thus, put the time in where it costs the least and that’s with a designer.

• When an engineering team or lead engineer is planning out overall page layouts and components, they are looking for all states of a component, and not one. They are looking for grids so they can adopt responsive behavior. They are looking for complete type and color libraries to apply across the application. What is sometimes unrecognized is the impact of missing basic elements in a design system and that compounded impact on engineering time.
• If you’re working with multiple designers, here’s where things get very tricky. Imagine both designers being assigned tasks without a design system established. Then having them handoff those designs to a development team. This will not only cause discrepancies in the code, it will cause inconsistent UI across your application.

As you can see, having a design system in place will reduce debt across your design team and engineering team. Plus, reduce some crazy meetings trying to figure out how to fix all the work that’s been done.

‍

‍

‍

Mistake 5: Don’t handoff to your engineering team without specifications

‍

Do you handoff your designs through Invision, Figma, a design file, or possibly GitHub? Do you expect your engineering team to review one page at a time, so they can see your design specifications? All this sounds great from a designer’s perspective, but you need to understand that it could be 1–2 months later when an engineer receives a task to start your designs. And our memories can only go so far as to recall conversations. And you may have reviewed the designs with the entire product team weeks back at the end of a sprint.

• Did you hand off your designs with no functional or thorough explanation of your behavior or interactions?
• Did you provide a link to a prototype that you expect the engineer to automatically understand your requirements?

‍

What to remember for a successful handoff to engineers

• Find one single place you can post functional specifications, a quick view of all your screens, links to videos, links to prototypes, links to Inspect Tools (CSS), and if necessary, a link to your Sprint Story/Task. This allows an engineer to not hunt, a QA person to make sure the build matches design, and your product owner to properly write user stories for the engineering team. Plus, a single link in the user story for engineers will make you succeed.
• Clearly write out all your functional and interaction specifications, including (if necessary) a flow diagram. Now I use Atlassian’s Confluence to create all our design documentation. This tool is perfect for your product team, cause it's a single scrollable page with a Table of Contents (It includes anchor links for the entire page) at the top for complete visibility to every screen. Here are a few tips on what you can be writing, and before you read those tips, you may be asking “Isn’t this what the Product Owner is supposed to do?”. Every product team or business is different, and I believe that every design comes with intimate knowledge that only the designer who created it possesses. And that’s you. If you leave it up to the Product Owner, then you run the risk of missing some very important details.

• As an example, you may want to note a variety of states after a button is clicked, as well as the sequence of events before and after (mostly animations)
• Another example may be to explain a time format such as 1 day, 2 months. Not always straightforward, since your time format could be unique to the user experience such as the difference between a news list versus an inbox for your email.

‍

My Disclaimer

I don’t want to sound like my suggestions here are perfect for every designer or design team. They are circumstantial, and over years of practice and many mistakes, I have learned that you are constantly improving the process. It never ends.

‍