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
In my previous two columns in this mini-series about extended reality (XR) design, I discussed some building blocks of XR, as well as some fundamentals to consider when designing an XR experience. Now that I’ve covered some of the broader aspects of this design space, I’d like to shift gears a bit and discuss some specific concepts you should be aware of once you’ve gained some traction in the XR space and want to improve the experiences you’re creating.
In this installment of my mini-series, I’ll cover five additional design concepts:
Field of view (FOV) and retention versus exposure in virtual reality (VR)
Many articles have been written on what is probably the single most ubiquitous interface element within Web applications today: the form. Forms justifiably get a lot of attention because their design is critical to successfully gathering input from users. Registration forms are the gatekeepers to community membership. Checkout forms are how eCommerce vendors close deals. But what goes in must eventually come out, and the information users provide to Web applications often makes its way back to users in the form of tabular data.
After forms, data tables are likely the next most ubiquitous interface element designers create when constructing Web applications. Users often need to add, edit, delete, search for, and browse through lists of people, places, or things within Web applications. As a result, the design of tables plays a crucial role in such an application’s overall usefulness and usability. But just like the design of forms, there’s more than one way to design tabular data.
In a previous Communication Design column, “So the Necessary May Speak,” I discussed how to reduce the number of both visual design and content elements within a table to the absolute minimum necessary for effective communication. So, I won’t repeat myself here. Instead, I’ll focus on interface design solutions that enable users to find their way through large data sets. Read More