Everyone knows that the best error message is the one that never shows up. But no matter how good the design is, errors are unavoidable.
10 years ago, twitch (Streaming Platform) decide to create this 404 page that is really funny and confusing at the same time. In later years, there was a redirection bug that occurs if someone shared the twitch link with other users without http/https at the beginning. During this bug, lots of users ended up on this page. They got stuck because it wasn't clear and didn't explain what the next step might be.
When the teams build new user interfaces, they rarely think about error messages and they are not very keen on prioritizing issues with error messages. I hope the first article of this episode will prove you the opposite is also possible.
Please let me know your ideas about via Twitter, Linkedin, or email.
Now, onto fourth week’s episode.
Jenni Nadler explains everything from her experience at Wix that helps us understand whether an error message is good or bad, and why error handling should be a team sport.
🔗 https://wix-ux.com/when-life-gives-you-lemons-write-better-error-messages-46c5223e1a2f
I've seen a lot of articles about giving feedback so far, but it's the first time I've seen a good article like this about receiving feedback written by Andrea Mignolo. Enjoy reading!
🔗 https://medium.com/method-matter/the-art-of-receiving-feedback-1561aaa74d6c
Who doesn’t want to be that 10xQA which point out every edge cases in grooming/planning meetings? I know a lot of us struggle to keep ourselves and our test materials updated with continuous busy sprints. Robbie Falck shares his way to solve it. Give it a try!
🔗 https://medium.com/@robbie.falck/using-a-product-blueprint-to-improve-test-planning-41337412bebc
No posts
Comments
Nothing yet. Say the first thing.
Sign in to join the conversation.