Process: Design Process

In this edition of Ask UXmatters, our expert panel looks at the importance of considering the fundamental principles of great design—not just UX design principles, but design principles in general. Our panel also discusses how great UX design takes place within organizations, looking at this topic on many different levels. How can you create great designs when working with a variety of designers with different backgrounds and while working within the constraints of project-defined goals? How can the presence of User Experience at the C-level and, in general, garnering support from the C-level affect our ability to implement great designs. How can we produce great designs in a repeatable manner? Keep reading for the answers to all of these important questions. Read More

In my previous columns, I’ve framed my discussions around the practice of information architecture. To recap, the DSIA Research Initiative—of which I am the curator—defines the practice of information architecture as “the effort of organizing and relating information in a way that simplifies how people navigate and use content on the Web.” While the practice of information architecture can surely extend beyond the Web and its content, this IA practice definition eschews theoretical language to resonate with businesses looking for concrete Web solutions and practitioners who want to make a living off something tangible.

In the end, business clients don’t pay practitioners to practice information architecture; they pay professionals to produce IA work products that help them to meet their business objectives. So, of the many professional interests that come together to create a digital experience, what work products make the practice of information architecture unique? 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