Great, another UX article.
There are tons of articles out there talking about UX, deliverables, how-to-whatever, you name it. But one thing that has been on my mind for a while was the division of roles in the field and confusing distinctions between responsibilities during the process.
We do things a bit differently at Vincit. We believe that the term “User Experience” (UX) refers to the entire experience of a product, ranging from the offering itself, to the user’s pathway through the product, to the visual polish and quality of implementation.
This article aims to provide insight into the industry, as well as explain our design philosophy at Vincit.
So what really is UX?
UX design is seen as synonymous with Wireframes and User Research. At first glance this may seem strange, as those deliverables are part of the research and planning stage of a project, which is pretty far removed from the final “experience” the user will have when using the product.
****To understand why this is, we need to step back in time to the 1990’s.
The term “User Experience” was coined by Donald Norman, who was the first person to ever hold the title “User Experience Architect”. During his time at Apple, he created the term to describe the entire experience of owning and using Apple computers: whether or not they fit into your car, your first impression upon opening the box, the user interface, even how your conversations go when explaining the product to others.
****So how did the term become confused with research and planning?
Well, UX was a new way of thinking, and the main areas where it differed from the legacy approach were in (you guessed it!) research and planning. Rather than designing for pure functionality and assuming users will figure it out, Apple took time to really understand their potential users, taking great care in smoothing out sticking points and frustrations. The result was a product that changed the paradigm in personal computing. When people analyzed what Apple did differently and attempted to create processes to achieve the same results, they arrived at User Research, User Journeys, Wireframes, etc. After all, graphic designers who create the interface and visual design were already a thing, so there has to be a different name for these new processes right?
Photo Credit: https://society6.com/product/honest-blob-says-no_print
There is definitely room for research specialists in a large team, but calling it UX Design and separating these new processes into its own role goes against the original purpose of UX. It also can confuse the roles in a design team; with UX being a term that encompasses everything the user experiences when using a product, it is misleading to have “UX Designers” working side by side with Researchers and UI Designers.
So how does Vincit do things?
At Vincit California, we started off with the title “UI / UX Designer”, in a half-assed attempt to be accurate about our responsibilities, but retain the industry terms to not confuse clients. It served us for a couple years, but we realized we needed a better description.
****Our description is:
Vincit crafts user experiences. In order to tackle such a broad task, we rely on Strategists, Interaction Designers (ex UI / UX Designers), and Software Engineers, all working together to create that holistic user experience.
****You might have noticed that we combine UI and UX into a single role, “Interaction Design”
This is a different approach than a typical design agency will take, where roles are separated into UX Researchers, UX Designers, and UI or Visual Designers. We believe that separating research, planning, and implementation is a recipe for wasted hours and incoherent results. When each person hands off their work to the next, the nuances of their learnings and decisions are lost and the documentation required for handoff is time consuming. After this game of telephone, the final product is pretty far removed from the user research.
At Vincit, the same person will talk with clients about business goals, conduct user research, plan based off their findings, and implement the final designs.
For larger projects, when a team is involved, instead of each member owning a stage of the project and then handing off, each member owns a share of the work throughout the entire project. This allows for greater collaboration, and allows the nuances from the original findings to come through in the final product. We call that person an Interaction Designer, because they have control over the User’s experience purely as it relates to the time the user spends interacting with the product. The before and after will be crafted by our Strategists, working closely with the client. We make sure the whole team is in each meeting and collaborates closely with one another to keep everyone in the loop.
Feeling a bit skeptical?
So were we at first, but after testing the approach with multiple projects, the results have been great. I’ll try to address a few of the main concerns:
You might be thinking that this approach requires a lot of unicorns, since the Interaction Design role spans from user research through final animations. But even before UX was called UX, designers have always been considering the user experience, even if they didn’t realize it. Great hierarchy, logical structure, and usability are a huge part of what makes a design beautiful. There’s a happy Medium (ayyy) between a generalist and specialist that we look for in new hires, allowing for the team to give quality input on all aspects of the project, while still focusing on their strongest areas. This approach also allows for huge personal growth for each team member, exposing them to areas where they can improve on a daily basis.
You’re probably also thinking something along the lines of “aw hell no” about sharing the same type of work throughout a project because of design file versions, inconsistencies, etc. (AppUIV47Final_FinalForRealsies.sketch sound familiar?) We worried about that too, but we recently switched over to Figma where we can collaborate in real time on the same file, with version control and shared libraries. This is allowing us to find newer and better ways of working together, which is pretty exciting. But Figma is a topic for another day.
In the next article I’ll discuss the importance of the User Experience. See you soon!