Code: Prototyping

Throughout my career as a user experience designer, I have continually asked myself three questions:

• What should my deliverables be?
• Will my deliverables provide clarity to me and their audience?
• Where do my deliverables and other efforts fit within the spectrum of UX design?

I have found that, if I do not answer these questions prior to creating a deliverable, my churn rate increases and deadlines slip.

When attempting to answer the third question, I use a framework I discovered early in my career: The Five Competencies of User Experience Design.PDF This framework comprises the competencies a UX professional or team requires. The following sections describe these five competencies, outline some questions each competency must answer, and show the groundwork and deliverables for which each competency is responsible. Read More

A prototype is a primitive representation or version of a product that a design team or front-end-development team typically creates during the design process. The goal of a prototype is to test the flow of a design solution and gather feedback on it—from both internal and external parties—before constructing the final product. The state of a prototype is fluid as the team revises the design iteratively based on user feedback.

Why Are Prototypes Important?

Tom and David Kelley of the design company IDEO have perfectly summed up the importance of prototyping by saying:

“If a picture is worth 1,000 words, a prototype is worth 1,000 meetings.” 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