4 Habits of UX-minded Teams

Aug 11, 2021

 Scope creep is ready to jump out with these common design gotchas.

You may know that feeling when the sprint is about to end and you find out that there are several edge cases that the designer and yourself missed during sprint planning resulting in either (a) scope creep before the end of the sprint or (b) a sub-optimal delivery of the feature…

 That’s what we call a ‘design gotcha’.

It’s an unexpected (and unwelcome) situation that happens as a result of poor complexity mapping, superficial interaction design or confusing information architecture. It is the silent culprit behind wasted designs and coding efforts. 

The problem with ‘design gotchas’ is that they tend to pop up too late and then, unfairly, become a reflection of the developers' effort. Knowing it could’ve been detected upstream and wasn’t is frustrating which is why a shared understanding of UX best practices can help developers see the forest for the trees and ensure that the best possible version of a feature gets built.

 

Here are some common scenarios and tips for how to proactively address them:  

 

Scenario 1:

The UX copy in the mockups sounds weird and makes the app confusing to navigate - the designer needs to always add additional context.

 

Solution: Prevention / Mitigation

The phrase “copy is design” means that changes in copy will change the design. Don’t make these types of changes when you’ve already gotten to the point of implementation. Avoid using placeholder copy in higher fidelity mockups. Double check your labels throughout the product, make sure you didn’t add new verbs or nouns into the mix (ex. Button says GO but normally says NEXT)

 

Scenario 2:

User feedback is that it’s not clear that the task was successfully completed when they tried generating the report and so they kept trying to complete the action until they gave up. They ended up getting the report emailed to them 9 times.

 

Solution: Action

You need to be able to talk through the design logic and get feedback as early and as frequently as possible from your team and the users. Design decisions need to be anchored in a design rationale because it will force you to think of the flow beyond that screen and understand the full picture of what needs to be built. In this scenario, a good success state is what was needed for the user to have the correct context of what happened. 

 

Scenario 3:

You get to the end without mapping out all your behaviours and now the scope of dev work has increased or requires refactoring of the work completed.

 

 

Solution: Mitigation

Map out the interaction states of all the components - we often design for the ‘happy path’ i.e. for the success states and task completion. By mapping the possible errors and loading states, you’ll avoid design debt by a thousand edge cases missed. Ideally, you can do this step at the beginning, but it’s very useful even later when you’re in the weeds and need a sanity check.

 

Scenario 4:

The app doesn’t feel smooth to use - when you click on buttons, dropdowns or fill in forms, it doesn’t feel polished.

 

Solution: Testing

Don’t automate all your QA. You need to actually test all the interactions yourself. As a human. You’re going to know if something feels weird or off and things like this can get overlooked in the QA cycle unless you have a superstar QA on your team. Better yet, design the test cases before you start building and include QA in setting the acceptance criteria. 

 

Another benefit of design QA is that you’ll be able to test out the interaction states of each of the components (buttons, dropdowns, menu items, filters or inputs) and make sure that the success, error and loading states of each are covered before a feature is shipped.

 

 

Knowing the root causes of design gotchas lets you address those points of friction within your workflow without creating a ton of design debt along the way. It’s not all on you as the developer to catch these issues but you will be able to point them out to the designer much earlier in the development process when you know what to look out for. 

 


 

If this was helpful and you’d like to make sure you’re shipping the minimal delightful version (MDV😉)  of the feature you’ve been working on, our Design SOS course is a great refresher on some design fundamentals. Developers that have already taken the course have had some great things to say about how this course has helped them already. 

📬 Join the crew

Sign up for the latest:
hot takes 🌶 ,  fireside chats 🔥 & early access 📣 

We won't send spam. You can unsubscribe at any time.