In his classic movie Rashomon, Akira Kurosawa unfolds the details of an event, by telling the story from the perspectives of multiple characters, including a dead person. Each character, who was also a direct witness to the event, recounts the story by telling the narrative from their point of view. That some form of the event actually happened, is undisputed, but as it happens, the stories, while similar in structure, end up contradicting each other.
User experience practitioners often find themselves in a Rashomon situation because of UX's unique position at the intersection of business, technology, people, and systems. The success of the UX project rests on our ability to fuse the various entities in a coherent and elegant way.
Understanding the perspectives of the stakeholders we work with is important, not only to arriving at a good solution, but also for a strong collaborative environment capable of handling the stress of constant change and fleeting schedules. The coming pages provide the insights of real people: business process architects, product managers, project managers, visual designers, development managers, and developers. I had the pleasure and benefit of working closely with many of these people over the years, and their insights are provided below, as they correlate to various chapters in this book.
You are likely to interact regularly with several types of business people: top executives, business process architects, product managers, and others. In many projects, the entire effort is driven by the business, and the success or failure of UX initiatives indeed rests on the informed support of top executives, who firmly understand the benefits of investing in user experience. UX practitioners often do not get much visibility into the tactical or strategic goals that the top management has for the project, which may lead to frustration and misaligned expectations on both sides.
I have asked Oren Beit-Arie, Chief Strategy Officer at Ex Libris, a leading global provider of library automation solutions, to share his thoughts about management and UX. This is what he has to say:
Organizationally, a company may not be built around UX core competencies, and outsource it. Consequently, UX may be the first to be cut because it is not clear to management that UX contributes enough value, and there is suspicion that the consultants are just exaggerating up the value of their work. The recognition of the importance of UX for our company and products has evolved over the past decade, as we gradually learned to integrate UX with the development process.
When you are designing a customer facing application, it is easy for stakeholders to form their own personal opinion on how compelling a proposed UX is. That's because we can see ourselves in the role of the user, compare the experience with the competition, and with other applications we are familiar with.
But when you develop expert systems, and administration tools, Management and other stakeholders face a true challenge with the UX because it is difficult to figure out the best user experience. Managers have less intuition about how expert users do their work, how to improve and innovate something you are not fully know in great detail?
As a result of the evolutionarily path we took, we have a lot more confidence in dealing with this situation, and the impact of UX on our products. Today, we can also invasion how to use patterns we experienced on our iPhone and other mobile devices, might work on a particular product, because such patterns are so ubiquitous.
Generally, we find that, as Management, we think about UX as an investment effort that has two aspects to it:
The first deals with relatively straight-forward questions that are easy for management to drive towards and benchmark against: How to facilitate tasks and workflow via the UX? How to improve the productivity and efficiency of an application? How to satisfy the need to demonstrate lower cost of ownership? How to get a smart UX especially for complex tasks, How to make a product accessible, and so on. This is a very important aspect, but perhaps more tactical, as it is a solution-based approach.
The second aspect is less clear but more strategic and far-reaching; where Management, often struggles to determine the appropriate answer and make the proper investment: It involve aesthetics, design language, high production values, and our product, even corporate identity: How to balance between sleek, supper commercial design, and a more appropriate, practical design?
Increasingly, the standards and expectations our customers have, are not related to the specific class of applications we are dealing with. Rather, they form their experiences based on their experiences with applications from totally different domains. The issues become - are user expectation set too high due to these other apps? Think about Pixar producing eBooks...How to balance between making you product unique - and yet not so different - How to preserve your identity?
New realities force management to think about the competitive landscape, and new customer demands such as dealing with multi-device delivery: Mobile, tablets, desktops - which translate to the cost and complexities of multiple technologies, and on top of these - creating the UX for these. Another example for a challenging dilemma was, should we wait to HTML5 or do something now with existing technologies? Other questions related to this aspect involve localization, personalization and customization - How much to spend on these features and capabilities?
It is a process, and working closely, and iteratively with UX helps resolve many of those questions and concerns.
Tim Robb is a senior manager at NetApp, with whom I had the pleasure of collaborating some time ago. I have to admit that I am still under the spell of his leadership style and the way he worked to get the team through challenges that, at the time, seemed insurmountable. Here are Tim's thoughts on collaboration with UX, in this case, a team of UX designers.
Q: What are your expectations from the UX team?
I'm looking for the UX team to understand the context in which our users will interact with an application and what the users value above all else... That is, I expect the UX team to go beyond time-on-task analyses and develop a full understanding of why the users would want to use an application AND then how the application will impact user productivity, how it will hold their interest, how it will pique their curiosity, how it will help them understand and hopefully encourage them to return and view the application as an enabler rather than a "burden"...
The UX team should apply its expertise to help the business/functional/technical teams from "getting in their own way". We can all fall in love with automation, technology, the latest-and-greatest, "process simplification", our pet features, etc. However, the UX team should be speaking as the surrogate voice of the user. They should keep the business teams honest in representing and protecting the users' best interests. They should help the project team approach "stretch goals" in fostering end user satisfaction. Don't lull us into adopting "best practices" at the expense of delivering something remarkable, something that could deliver a competitive advantage.
In some respects I expect the UX team to serve as a kind of safety net that drives the business to deliver a harmonized blend of critical functionality and usability. The UX team should play a key role in leaving users with the impression that application delivery is not something we did TO THEM, rather something we did FOR THEM.
Q: What are some challenges in reviewing UX?
Protecting the time to do it... the business is trying to balance requirements-gathering, BRD (Business Requirements Document) development, conversion to functional/technical documentation, etc. and bringing UX team up to speed on all the nuances within and across workstreams.
Given challenge above, we had to 'divide and conquer' to review and advise... I think preferences for UI elements tend to be very personal which can result in different opinions when different parties review at different points in development lifecycle (and I would assume, frustration on the side of the UX team when the feedback changes depending on who is weighing in and when)
Trying to understand how to wade thru a wide variety of options... Looking at Wireframes, mockups or some other graphic representation is very helpful – critical for me (and also I think for sales and marketing users, who I think tend to be more "visual")... but then it can be a challenge to keep up with the changes and proposed changes and user-reaction/feedback to those over time.
Q: Do interactive prototypes help clarify the UX, or do they make things more complicated, slowing down the project?
I think the answer is "Both". Prototypes definitely help clarify the UX and in many respects "bring it to life"... but they do take time to develop, review, refine, review, assess, refine, etc.
I think an equally impactful issue for consideration is how close can/will the final product be to the prototype?... Project capacity/timeline, technical limits or performance considerations (for instance if application is integrated to or embedded in another application framework) can all impact the ability to match a prototype to the final deliverable. Users who see a prototype seem to magically develop a "photographic memory" of that cool new UI or UX treatment of something they've labored with in the legacy system for years... If the end product can't or doesn't deliver those one or two favored aspects, you can run the risk of not meeting up to the expectations the prototype set in their mind. I don't think this is a reason to shy away from prototypes, just a cautionary note to be careful how you position prototypes/wireframes.
That being said, we don't subscribe to the "under-promise, over-deliver" strategy. Despite good intentions, that can easily turn into a "under-promise, under-deliver" situation and worse, can actually prevent the team from reaching stretch goals or creating differentiating outcomes.
Q: What can UX teams do to improve the communication with business people?
Simply be honest with the users and the project team... don't tell either of them what you think they want to hear, tell/show them what is realistically possible within the constraints of the technology and the project scope. At the same time, convey the UX team's excitement and energy to those possibilities.
Communicate visually, communicate visually, communicate visually – whether with mockups, wireframes, prototypes or by showing other websites for comparisons or just to trigger thoughts/ideas.
Don't dwell on the legacy system, but understand it well enough to understand what users think are the top detractors/barriers to productive use AND what they think are top 5 positive aspects. Keep in mind that when you do deliver the new system, regardless of current "shortcomings" the legacy system will instantly become "the best thing we ever had". So help protect the project team by understanding not to "miss what's not broken".
Don't underestimate or under-invest in the value of the end-user feedback as part of the review process. And if you are developing an application that is utilized both internally and externally be certain to capture both perspectives... walk thru "a day in the life" of both parties and then frame that in the perspective of the end user values (not what the project team values, not what project management values).
M is a director-level business process architect at a global consulting firm, who has years of experience leading the development of business requirements effort for highly complex software development projects:
During the requirement gathering and high-level design phases of a complex implementation project partnership between the Business Architecture and the UX team can greatly enhance the final product.
By using a prototype-driven approach, the business is able to grasp possible options and make better informed decisions. At the same time, the risk is that what is presented is assumed to be "set in stone" by the executive team therefore creating an expectation that cannot be maintained due to budget constraints or availability of functionalities.
The Business Architecture team can and should leverage ideas generated by the UX team and evaluate the business requirements accordingly. In multiple occasions, we found our requirements to be lacking the users' perspective. By communicating with the team and by evaluating its reaction, we were able to adjust the requirements to achieve an enhanced user experience.
Of particular help was the use of wireframes. One of the most effective interactions I have experienced with the UX team was the creation of wireframes making the requirements come to life.
The back-and-forth between the teams and the ability to see a draft of the final product while finalizing the requirements was instrumental in the achievement of a successful product. For example, one of the requirements called for the ability to indicate that one account can be indicated as "Same As" any other account on the object being developed. After reviewing the wireframe and going through the steps a user would have had to take to comply with the requirement, the Business Architecture team realized how cumbersome the interaction was and modified the requirement accordingly.
Although the use of wireframes and prototypes greatly enhances the ability to deliver a good final product from a user experience standpoint, some considerations need to be taken into account.
The UX team has generally limited knowledge of the processes being enabled; this requires the Process Architecture team to spend a considerable amount of time, at least in the beginning, transferring knowledge. This is especially daunting when the UI being designed is completely knew. In projects with limited time and budget this can cause friction between the teams and poor cooperation.
The Process Architecture team's expectations need to be managed when interacting with the UX team. In the early stages of a project, there should be a clear understanding of the rules of engagement between the two teams and the expected deliverables the UX team will produce. In my experience, teams that did not work on projects with heavy involvement from the UX team had difficulty understanding the benefits and the deliverables the UX team can provide. One of the major points of contention has been, in my experience, the demarcation between BRDs and UX specs. It has been challenging to identify which document should contain what requirements and to what extent to the point that, at times, there were conflicting directions for the functional teams to follow.
The UX team should use tools capable of producing an output that speaks not only to functional teams but to Business Architects as well. While reviewing UX specs I frequently found the documents to be very technical and not immediately understandable. This slowed down the process of creating a cohesive output and, in time-sensitive situations, has created friction between teams.
We live in a world where most of us spend a considerable amount of time each day on the Internet or using products from well known software providers such as Microsoft Office and Adobe Creative Suite. This provides all of us with access to well thought out user interfaces that have been refined over the course of several years and have been widely accepted as standard. When interacting with the UX team, Process Architects tend to apply their experience with such software packages and websites sometime overstepping their area of expertise. Interaction with the UX team, in such circumstances, has resulted less than fruitful. The Business Architecture team should clearly understand and recognize the UX team's expertise and rely on its inputs to craft a good user interface.
In my opinion, the inclusion of the UX team on complex system implementations is fundamental for being able to provide the best product. Although the interaction with the other teams involved in the development is not always easy, the benefits far outweigh the challenges.
Project managers are tasked with tracking the progress of projects and facilitating solutions that help resolve roadblocks along the way. In many projects, UX professionals do not have the benefit of a dedicated project manager, which can be a problem for medium and large projects. If a project manager is not budgeted to the project, it is a good idea to raise that as a flag and take extra effort in developing a comprehensive, mid-level plan, by yourself. If there is a project manager, make sure to review the entire project plan and flag dependencies where the UX effort has not been considered.
For example, many plans do not account for the time it takes to refactor the Axure file from vision prototype to detailed design prototype. Others don't take into account the time it takes to iterate and revise the prototype. Sometimes, the time it takes to arrange the logistics of usability tests such as recruiting, is not considered. The more time spent early on with the project manager, as the plan is being developed and revised, the better off the project will track later on.
Tom Hackett is a project manager with a background in web development. He has worked with UX designers as a front-end web developer and a project manager:
Q: What are your expectations from the UX team?
As a project manager my expectation from a UX team is that they are able to identify user issues, and suggest design solutions that solve customer problems. I would expect that a UX Engineer can identify issues through both interviews and observation. A UX Engineer who can create clickable mockups and walk users through a prototype helps clarify if suggested changes will have the desired effect. It's also important that the final designs incorporate functionality and workflow notes for the development teams, clarifying expected behavior that isn't implemented in the interactive prototypes. It's a huge benefit if the wireframes are written in such a way that the development team can leverage the HTML/CSS in implementation.
Q: Do interactive prototypes help clarify the UX or make things more complicated, slowing down the project?
My experience has been that UX prototyping seems on paper to increase project timelines, but in practice can reduce development cycles since users can give feedback on an interactive UX design much sooner than waiting for the first generation system. This reduces the amount of feedback necessary in the development cycle itself and allows developers to focus on functionality rather than incorporating design or layout feedback during the build phase. An interactive UX often clarifies whether implied or assumed functionality that isn't documented formally exists, both for end users and development teams.
Q: What can UX teams do, to improve the communication with business people?
UX Engineers can improve overall team communication by ensuring development teams are behind suggested solutions and feel confident in implementation. An interactive prototype that pleases the business but cannot be implemented due to performance constraints or ties to legacy system workflows, etc... can cause problems with scope management.
The Medium is the Message—Marshal McLuhan
Visual design introduces some of the most daunting challenges for rapid prototyping projects and a hidden iceberg for Axure prototypes. Why? Because of a gap, sometimes a serious one, that grows between the wireframes in the prototype and the visual design. This poses both UX and development risks because of the need to reconcile between two representations of the same screen. Eventually, a refactoring of the Axure prototype will be needed, especially if the intent is to keep using the file throughout the entire life cycle of the product.
The two sets of wireframes are developed asynchronously. Normally, we start with Axure wireframing as rough conceptual sketches that evolve through rapid iterations. These wireframes address information architecture and actionable tasks, and the layouts are often tentative. With Axure, we can enhance those estimates and evolve the concept as an interactive prototype that demonstrates the vision for navigation and interaction patterns.
All this work, however compelling, tends to be in grayscale, without visual design. As user experience architects and designers, we want to isolate the feedback we obtain from stakeholders and potential users. The conventional wisdom is that adding visual design cues at such an early point is adding unnecessary 'noise' to the feedback. That is because people's response to colors and layouts is both extremely subjective and strong, and the concern is that such feedback tends to push to the background more substantive issues.
However, referencing McLuhan's point that the medium is the message, is the argument that it is not possible to separate visual design from user experience. This argument sounds especially compelling when it comes to the design of mobile apps. This is a case where beauty is inherent to the design of the user experience.
What often happens is that, at some point in the UX process, visual design gets involved, and the ugly duckling emerges as a beautiful swan. Now, everyone needs to start looking at the two sets of wireframes. Often, the two sets will continue to evolve on separate tracks because, while the work with the visual designer takes place, work on finalizing Axure wireframes for specifications continues. It is easier to manage the situation if it is taken into consideration early on. Resolution is still going to be an effort, but at least it will be accounted for in the project plan.
I have found that UX designers, myself included, sometimes do not completely appreciate the complexities and challenges that the visual designers on the project face. Busy and stressed by our own issues, it is tempting to dump on the visual designer a great deal of information, often not fully baked, and expect that somehow the designer will 'get it'.
Therefore, I have asked Yael Alpert and Colin Ochel, two exceptionally talented principal visual designers, to share their perspective. Here are Yael's thoughts:
Q: What are your expectations from your UX partner (team or individual) on the project?
Get informed about the client's business and UI requirements as much as possible and get the full understanding of any background research for the project done by the UX team.
Be involved the UX's process of creating personas and users' and stakeholders' interviews, when such process exists, and understand the audience for the project.
Get involved in the UX process as to why they made certain decisions in design and interaction; this can help the visual designer better make their decisions in visualizing the wires and see what limitations, if any, the specific project has.
Meet the UX designer to go through the wires; this is very important, so the visual designer can fully understand every intention of the UX in the project.
Have meetings critiquing the visual designs; it is important to have these meetings so the visuals are viewed from a UI perspective before being presented to the client.
Q: What are some challenges of integrating the visual design with a conceptual wireframe?
Keeping true to the UI while creating an engaging braded experience. Many times it is tempting to design interactions that are 'more fun or unique' but are less 'user friendly'; the challenge is to find the balance between the two.
Come up with appropriate solutions - many time the wireframes will not be obvious in what's the best solution for a certain interaction or page; the visual designer will than need to communicate the UI intention in a way that makes sense to the user. It's the visual design that the user sees in the end and these do not come with an explanation, so the visual design needs to be very clear to the user.
Be creative: a good visual designer will try and see the wire frame page in a few different ways and explore a few ways of visualizing the same thing. This is a challenging practice but a very good one especially if user testing of the UI are conduced.
Q: What should UX designers keep in mind when communicating with visual designers?
Everything happens for a reason: Have every element in the wire thought about (even if they are made just for the purpose of visual design), even elements such as color; if you color a certain item in the wires, the visual designer will see it as a meaningful thing, if there's no reason for the color / differentiation – do not use color.
Be consistent: Describe or visually represent specific elements in a similar way and keep to it throughout the wireframes. Elements such as icons representation, navigation items, buttons etc.
Be clear: The visual designer in a way is like the client to some extent; s/he needs to understand the wires as much as anyone else to achieve the best outcome; to save a lot of back and forth clarity is important.
Be open: Many times, inspired by the wires and the project in general, the visual designer might come up with a different layout and or interactions than the UI that still serve the project well. Be open to discuss updates if they make sense; visuals designers in the interactive area understand interactions and have an opinion; they are not just 'coloring' the wireframes; a good visual designer brings his or hers experience to the table that can work well together with UX.
Here are Colin's insights:
Q: What are your expectations from the UX team?
To be the voice of the client. I expect that the wire frame are the translation of the client's needs and if I have any questions or suggestions, the UEA can answer me as if they are the client.
I also expect the UEA team to be open to change. Because the UEA gathers the requirements from the client, they are led down the client's vision of the product/site/widget and it very difficult to view it from another direction. I get to see the requirements from a bird's eye view through the raw wire frames so I can view the content/flow from a non-influential eye. This allows me to make suggestions the UEA might not have considered.
Q: What are some challenges of integrating the visual design with a conceptual wireframe?
Space. Often wireframes pack in a lot of information in a small space. It looks fine when it's small text in a bounding box but not when it is in a designed layout.
Less is usually more when it comes to design. Just because something is content rich does not mean that it needs to be cluttered. Do not be afraid to brake down a page into parts that are shown only when needed. Finding a clever yet clear, intuitive way to display the content is always a challenge though. The more you hide, the more risk you run into bad usability.
Q: What should UX designers keep in mind when communicating with visual designers?
Most designers do not think like architects so it is a good test to see if your wireframes are clear. If the designer gets hung up on any part of your wireframe then you need to revise that interaction to make it more clear because if they do not get it, the end user will not get it.
One would not be blamed for thinking that developing the user experience and software development are complementary processes. However, as we often find, there is a gap between UX and development. There are many reasons for friction, but a fundamental means to resolve these is communication.
It is surprising to hear stories about large projects where the interaction designer and developers only got together well after a spanking, high-fidelity vision prototype, commissioned by the business side of the organization, had been used to drive top management to move forward with the project.
The problem, from the perspective of the development team, is that the expectation now is that the amazing application will be developed and will work just like the prototype, and will be in production in no time...as if life was so simple! Development leaders often express concerns that UX does not always take into account the constraints of available technology, impact of the new UX on performance, scarceness of development resources available to the organization, or the complexities involved in implementation of the new UX.
These concerns are often valid and true. With Axure, however, UX has a tool that helps improve communications through visualization of interactivity and integrated annotations. Conversations, analysis, estimation, and adjustments can start early on in the development life cycle and reduce the stress on the development team.
The following are the thoughts of Mark Roeser, a senior technology executive with extensive experience and focus on large-scale data systems:
Q: What are your expectations from the UX team?
At the core of course the UX team builds out the interface design, looking for the most effective way to bridge the user's wants with the application. What I like to see most are openness and curiosity. UX needs to navigate around shifting product goals, technical constraints, a variety of user personas, and other unique challenges that have the potential to lead to an unsatisfying compromise. Having the freedom and curiosity to explore a number of possibilities is the best path toward inspired solutions.
Q: What are some challenges in reviewing UX?
Removing ourselves and our assumptions when reviewing UX, and imagining new contexts and situations in which to review a design. Also, focusing on the right elements at the right stage of the project: don't review or discuss art when things should still be handled at the wireframe stage.
Q: Do interactive prototypes help clarify the UX or make things more complicated, slowing down the project?
Prototypes should be carefully considered with specific goals in mind and not always be included. Prototypes that are easy to produce but too simplistic can lead to false validations. For example, a hardcoded workflow reviewed with an end user can seem easy and clear to understand, whereas a final working product might reveal excessive clicks, repetitive tasks, etc. when they use it for real w/out the idealized storyline.
Q: What can UX teams do, to improve the communication with business people?
As much as possible, share share the methods and teach the language of UX. Give them a language to effectively communicate their ideas and concerns, and draw them into the process. Be a guide and partner with them to discover solutions together, rather than asserting authority or attempting to dazzle with cleverness.
I'm also very much interested in finding ways to improve how UX works in an iterative development process, particularly in the context of the "minimal shippable functionality" aspect of agile/scrum. Here the goal is to learn early from a simple product in the field, rather than concentrating all UX work at the start. For this to be effective, the UX team needs to work closely with the development team to plan meaningful iterations and build in the feedback/measurements necessary to drive the process forward. Easier said than done!