In addition to the misuse, misunderstanding, and bad implementations of perfectly good UX design patterns, we’ve long understood the concept of anti-patterns. These are things that we know don’t work well for users. We’ve clearly defined and documented them so we can avoid using them.
However, as much as I’ve studied the concept of pattern languages and libraries, as cynical as I am about how businesses use and abuse product design, I simply didn’t expect the rise of dark patterns. Dark patterns are design patterns that are effective, but evil. When they succeed, they drive users to make accidental or uninformed decisions against their best interests.
During the creation of dark patterns, there’s typically much argument that they are positive for the business, that they expose ideas and encourage behaviors that the average person would do. I don’t think I need to convince you that businesses often place their own success above that of users and that it is the job of UX professionals to remind everyone that user-centric design must also be moral, ethical, and unambiguously legal design. Read More
“A style guide is an artifact of design process. A design system is a living, funded product with a roadmap [and] backlog, serving an ecosystem.”—Nathan Curtis on Twitter
As Nathan Curtis described on Twitter, a style guide is a document that a UX designer creates to document a growing and ever-evolving set of design guidelines that arise from the design process. In creating a style guide, UX designers are basically documenting their own thought process as they design a Web site, application, or system. Thus, the essence of creating a style guide is documenting your own design decisions. Who is the audience for this document? In this article, I’ll answer many important such questions about style guides to help UX designers create effective documentation. Read More
A common complaint about bringing UX designers onto a project team is that they waste time creating design artifacts. This is purportedly antithetical to modern development methodologies that value code over process.
However, this is not my experience at all. I’m not arguing that creating design artifacts is all that design is about. I default to fairly light documentation myself—and not one in 100 project teams or clients wants as little design documentation as I would typically provide by default.
One of my more common jobs is to improve or replace the design for an existing product for a client. All too often, these projects have no historical documentation of any value, which frequently causes projects to take months or even years longer to build.
Good documentation allows consistency in design and execution and serves as institutional knowledge for organizations. It enables us to remember what we’ve built and why, to check reported bugs and new feature requests against the documentation, and to more quickly react to necessary changes or updates. Read More