It’s hard to underestimate the impact of UX on digital design, it increases our sphere of inquiry by an order of magnitude. The moment we seek to understand such abstract concepts as “experience” we must look at a daunting set of considerations — at least, we must if we are truly sensitive to what can be significant contributing factors to success or failure at a given task: context, urgency, expectations based on existing conventions, accessibility…the list builds at a rapid pace.
So, it is not surprising that the interpretation of what UX should be or how it is implemented varies pretty widely from workplace to workplace, even from practitioner to practitioner. Some place more emphasis on the design aspect, seeking iterations of working mock-ups with which to test (“fail faster”) and build upon. Others emphasize research, discovery, and data-gathering, looking to know as much about the user’s journey and task flows as possible before even sketching out ideas.
And then there’s testing. To me, usability testing has always been the backbone of UX. If you aren’t placing designs or mock-ups in front of independent users, you can’t call it UX (in my mind). Design without testing is simply…well, design, and places all its trust in the instincts or experience of the designer. That paradigm might be desirable or even necessary in other fields, of course, architecture is an example that springs to mind, where it is impractical to build multiple versions of an Art Museum, say, to decide what works best. (Though it occurs to me that architects use maquettes to visualize their ideas, and these days, must surely use 3D computer modeling to suss out engineering and ergonomic problems before actual building begins.)
But the web is so fluid! That is its strength, web interfaces can be changed, tweaked, refined relatively quickly, often on-the-fly as concepts are being explored. And as confident as a designer may be, user testing almost always reveals some surprising insights into what works and what doesn’t. Testing validates the designer’s assumptions (or proves them wrong) so that the finished product can be as effective as possible.
Having lived and worked through the transitions from the pre-digital world to the digital one, from the early days of web design to UX design and Product design, I’ve found another messy, problematic aspect to the current practice: how to wrap it all up into a tidy portfolio.
Granted, I’m a generalist, having progressed along a fairly winding path of professional development. Early animation, art, and computer geek takes long way ‘round to find himself designing stuff for the web.
But many of the skills that I find serve me the best in UX are difficult to quantify via images. They are often those “soft” skills that everyone neglects to mention when describing success in a given field: diplomacy, communication, empathy, synthesis of data and stakeholder input.
That is why I’ve chosen to split what used to be my portfolio up across these series of Medium essays. I get the chance to speak to broader concepts (and those who are just looking for pictures of my work can find those, too).
Wireframing, or low-fidelity mock-ups, are meant to be lightweight, quickly produced deliverables that allow ideas to come to life, and more importantly, provide a basis for concrete feedback.
Translating data structures into a visual format can help stakeholders better understand taxonomy and structure, and can help pinpoint where problems lie.
Visuals can speak to the identification of personas and task flows, as well.
Wireframes can also show relationships between actual data and data structures. (This is why using “live” data is always preferable to using dummy copy or made-up numbers.)
Lately, I’ve noticed an interesting return to the power of sketching — even faster than wireframing, no need for a computer, and somehow more engaging and accessible to a wider audience. They can be done on paper or whiteboards within meetings and they are a quick way to share a story. (Story is another aspect that seems to be on everyone’s radar these days!)
During a discussion with a very wise and talented co-worker not too long ago, he said “Scott, what we need is to define the UX of UX!” The more I thought about this, the more I realized how important this observation is. Because UX can seem so broad and diffuse and can have a variety of “flavors” (dependent on job sector, team style, business needs, etc.), UXers can be met by their IT co-workers with a certain measure of skepticism or frustration. How can we relate our value to a non-UX-savvy audience? More importantly, how can we garner the budget allocations we need to help make our products better? This is an important ongoing discussion, and I’m excited to be a part of it.
In addition to seeking an ever-improved digital experience for our clients, I look forward to the ongoing codification, structure, and story of what we do. Here are a couple of good places to start: