“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
Universal-design principles (UDP) help UX designers create software that people with many different abilities can use, without their having to modify things or use assistive technologies. While the term universal design is more common in architecture and product design than in the design of computer user interfaces, the concept still applies.
In the 1990s, Ronald L. Mace coined the term universal design and founded The Center for Universal Design, at the North Carolina State University (NCSU) College of Design, to address the needs of an aging population and people with disabilities, meet the demands of new legislation prohibiting discrimination against the disabled in the United States, and adapt to societal changes. What exactly is universal design?
“Universal design is the design of products and environments to be usable by all people, to the greatest extent possible, without the need for adaptation or specialized design.”—Ronald L. MaceRead 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