Unlike the Graphical User Interface (GUI), which only connected marketing, technology, and the user through a façade, User Experience (UX) in the enterprise incorporates the way people perceive a design, use the product, and how they make decisions. In fact, UX is a very broad term that encompasses many smaller categories, all with the goal of creating a better product, whereas GUI is laser focused on the graphical presentation of a product.
From my early time at NCM, I had seen my own UX title represented many different ways, from architect, to designer, to developer. I had yet to see researcher, but this would also fit just fine. These title changes are due to a combination of factors. First, the general infancy of the term User Experience brings with it a lack of understanding around what it means. For some, it is simply the User Interface (UI) design, or what most closely relates to the deprecated GUI role. For others, the UX role is a developer that builds the UI graphically, as well as in code functioning as a prototype, or leaving it ready to accept the logic piece. This leads to the second reason, and that is that UX really does have multiple titles within the main UX category. Many companies will separate research from design, development, testing etc. The below image is an example of all the areas within a business, shown with UX at the center. This, however, does not break out UX into its different areas of focus, which are then seen on the outside as sub-containers.
Spectrum of User Experience
Based on design by Information Architects, Inc.
With the UX role built into the process at NCM as a floating specialist, my concern is that the role is being utilized on an “as seen fit” basis. This could result in the aforementioned siloed view of the role, circumventing the deep knowledge of a project required to properly implement UX in its most cohesive form. Instead of “as seen fit”, UX should be looked at through the idea “how does it fit” throughout the software development life cycle (SDLC). Any fragmentation of knowledge leads to miscommunication and ineffective design.
I should also note that not only is the “as seen fit” implementation apt to be siloed, to this point the floating specialist (me) has been utilized more as a UI role called upon when needed, with that need being identified through the stakeholder request of a new UI integration or change. Much of the time, these new feature or change requests are only being initiated because of underlying bad UX and should be looked at from the root of the problem in a proactive manner, rather than the more common reactive response.
UX professionals listen intently to stakeholders and users. Being involved in the early design sessions through to the launch of a product and beyond allows for the frequent collection of team-wide feedback and will minimize waste. Placing a UX iteration step into each business cell will lend itself to building a true lean UX process into the SDLC.
The deliverables from the UX practice must be constantly integrated into the lean process to assure the least amount of waste — work ultimately forgotten or not used in development of the product. That being said, lean is light and fast, so emphasis on deliverables should be lessened in lieu of actual experience design. In short development cycles this isn’t even an option. Achieving this shift from deliverable -> experience design is heavily weighted on the UX factor being truly collaborative during every cycle of the SDLC. Deliverables are not worked on and completed, but rather iterated on throughout.
The question becomes, where, and more importantly, how does this all fit in to the rest of the process? The first step is to make sure that UX is heavily involved in the design phase of development. This focus on earlier insights ensures that UX is aligned with the business vision, provides direction to developers prior to their work beginning, and flushes out creative thinking through increased collaboration.
My job is as much to create the experience as it is to organize and analyze the feedback that manifests through this collaboration, which in turn feeds the experience. Integration throughout the entire design process will result in an experience design that is infinitely greater than work I would create if involvement were minimal or “as seen fit”. As the sole UX expert in the Enterprise Information Systems department, my job is to use an entire toolkit of sketching, presenting, critiquing, researching, testing, prototyping and wireframing as they are appropriate for each development cycle, and for each problem that needs solving.
In order to cover all these bases, I cannot be in a cell myself; however, my particular “jobs” can be incorporated into cells. If the above iteration diagram were my products, how would each of these fit into the product families for each of the cells being created? That is what I’m hoping to solve and embed into our new lean environment. I’m hoping this blog can serve as a launching point for my research into how this can be done. Based on our current process, I intend to move forward by looking at each deliverable above: concept, prototype, validate, test, analyze & research, and iterate, and make a game plan for assuring UX and the lean work cell are one highly functional factory of awesomeness!
