by Jitesh Rajani

The term “User Experience Design” as coined by Don Norman has had a very broad meaning since its inception. As he explains the term was invented as Human interface and usability were too narrow to look at the broad spectrum of problems. He wanted to cover all aspects of experience with system including design graphics, interface, physical and manual interactions, services. But the term has spread so widely that it has starting to lose its meaning. 
 Unfortunately, this historic and truthful definition is easily forgotten. Somehow has been restricted to drawing things and painting pixels within . This has made it easier to forget what stands for, as the role of a designer doesn’t challenge the status quo.
 Working in innovation spaces, I realized that within the product development teams the fire of design genius was harder to ignite than in startups. UX is losing its meaning in the battle of conflicting interests. Togetherness is often replaced by private opinions and problem solving is easily confused with budget constraints and team excuses.

Understanding Enterprise Problem Solving

Enterprise design teams are often surrounded with challenges in working environment where the urgent trumps the important. Speed and task completion are easily mistaken for value and success.

Product owners and product designers are under tremendous pressure to deliver visible improvements without spending time and money. As a developer, you are staring at impossible workload(or designing better experiences too). It gets worst when as a UX designer or interaction designer you are expected to work miracles without being given enough control to do what you do the best (which is not just designing screens). We live in a work where burnout factor is high, tendency to change is low and questions to how to improve the overall experience are rhetorical.

On the other hand, for startups, problem solving is survival. Every line of code, button or every feature that include ultimately affects the experience. The goal is a relentless focus on problem solving. For us in the world of enterprise, designing like a startup means looking at problems, solutions and opportunities.

The UX Value Loop

Within enterprise product development teams, the goal to provide seamless experience can only be met if every effort taken correlates to UX Value Loop.

Whether our clients or users, people need to perceive value before they act, even in situations where they don’t have a different choice. Once they do act, the value should be confirmed for them to try, buy or use it. If any of that happens, value comes back to organization as money earned or money saved.

The value back to the enterprise is the last bit. Depending on the nature of the product, the features we design must:

1. Convince the user/customer to purchase (after trials and validation).

2. Keep the users from abandoning it (to strengthen user loyalty)

3. Ensure that users/customers continue to use it

UX isn’t just about users, and it’s not the sole responsibility of people with the words “design” or “UX” in their title. Teams that have been able to change their thinking were able to make quantum leaps in product improvement. Let’s dive into what it means to adapt startup thinking over the course of enterprise projects.

Stop Jumping to Solutions

As one of the most common scenarios, this is what effects the thinking the most. We have always seen long and unbearable requirements (often from product managers, marketing or departmental leads) that come with suggested solutions.

“It should have this feature…”

“Users should click on this…”

The requirement rarely explains the problem. This is called solution jumping in the name of lean and agile. The two big problems with it is –

1. No consent, No direction — When humans work for end state, it’s a reflex that they tend to fill in reasons why it’s the right choice. As everyone comes up with different rationales, starting with different positions of intent we suffer widespread disconnect.

2. Tricking people to believe we are ahead in the game. As you talk about solutions we often tend to consider research requirement gathering as a step backward. You start running fast but in a wrong direction.

A very effective and quick way to uncover the and to understand the problem is Five Whys. Embracing it can help you get to root problems and work to implement a real solution and not just fixing a small issue.

UX is Everybody’s business

When there’s an issue with the product, the problem is not just one thing. It’s rarely a usability issue, just a technical glitch or a UI design error. It’s mostly a combination of all. Within enterprise teams it’s given that everyone with be on the table for kickoffs but when it comes to solutions people work is silos –

  • BA’s would look at statistical research
  • Product owners will push the user stories and create new ones to solve problems
  • UX Architects will move to user research to get the answers
  • Developers will start thinking about the tools that might help solve it

These are both solid and time-tested approaches but at the same time inherently flawed because each address a small slice of the problems. What teams lack is a shared understanding of User Experience; a common lens that would filter and target these activities. Startups think differently to create a common mindset (whether it’s an open office space or collaborative team meetings).

As a UX designers, as much as you want to change things within enterprise teams you can’t have a Big bang approach to things. To find a common ground everybody in meetings should ask themselves 3 questions –

1. Is this worth doing? Every minute spent researching, designing and developing a feature is an investment. Are we certain that every requirement on our list delivers a return on that investment?

2. Does everyone agree on and understand what we’re creating? Does every member of the team share the same understanding of what’s being built and why it matters?

3. What specific value does it deliver? Does this improvement, feature, or function facilitate a desired outcome for both customers and the organization? Do we know it will deliver that value, or are we guessing?

As we stop to think how everyone’s decisions effect strategic issues, people not only start taking responsibility for their actions but also start thinking collectively from user experience lens.

Get the Right people in the Room

Let me know if you come across this: You are all set for your detailed design reviews and things seems to fall in place when people in organization you have never heard of mandate and change the requirements (we know it by swoop and poop).

Well it happened because from initial planning to development of solution they were weren’t on the table. Perhaps they weren’t invited or were not willing to get involved in the ground work.

Your worst nightmare: these people are the decision makers, true risk takers.

Including all these major stakeholders from initial phases prevents you from endless iterations (don’t forget the endless ping-pong game also), while you are detailing out the solution. A perfect way to include these stakeholders is design sprints. They help you in bringing everyone on board and create a collective knowledge about solution. Here are some more tips –

1. Invite them to process early — Most of the project teams exclude stakeholders resulting in them feeling alienated and do a lot of self-referential design reviewing the work. Start by asking them their vision and concerns and their aspect of product.

2. Their vantage point is critical– Let them know that this can’t be done without them. Ask them what success means to them and allow them to their pressure and pain. Discuss critical success factors make sure this information is well distributed.

3. Design education — For designer’s top excel in what they do the best, let the stakeholders know how their involvement influences the solution. Explain them the importance of design process and fill the blanks to help them overcome the fear of unknown.

Actions bring Insights

“That’s not how I imagined this would work when I wrote the requirement.”

I am sure most of us have come across such statements and they are still being heard in product teams because of requirements are often drawn from personal opinions, political pressure and knee jerk reaction to competitor’s features.

To help in preventing this, I recommend a solid and tested way of conducting design sprints: build a simple prototype as soon as humanly possible and iterate with users and stakeholders to generate requirements. I prefer Google Ventures, 5-day sprint that helps you quickly build solution and test them with users. Here’s a breakdown of things-

Day 1 and Day 2 Contextual Use Scenarios

We start with stakeholders, naturally. They’re usually immediately accessible and are also willing to share their vision of the product or solution. The first order of business is to understand what they expect, what are their goals and conflicts with what’s as-is.

First 48 hours will be spent with users and stakeholders trying to understand the process and diagramming it. Understand the pain points and identifying the opportunities is a key part these 2 days. The only deliverable from these meetings is a photograph of the whiteboard, shared with all involved. For now, forget formal use cases, forget formal diagramming methodologies and rules. Just draw it out and label who the players are and what they’re doing. As you draw, you ask questions:

  • What should happen here, and what actually happens?
  • What happens (or should) next?
  • What can (or should) the next person in the process do with what they have?
From Jake Knapp’s — The Sprint

Day 3 — Prototyping, Information and Action

While screen layouts and interaction mechanics are legitimate concerns but a bigger fish here is to know the problems, we are trying to solve and direction the team would take to design a solution. This is the right time to draw a clear separation between information and actions.

On day 3 the team would strive to filter concepts that makes more sense keeping the discussion around desirability, feasibly and viability. Keep two things distinct:

1. Things the user needs to know, and

2. Things the user needs to be able to do.

You use the prototyping process to answer the questions that have arisen over the past two days of strategy discussions:

  • How the system will meet users expectations?
  • What are the primary and secondary user goals?
  • What are going to be the critical success factors for this system?
  • How would the information be organized, categorized and labeled?
  • How might we stand it up as an interface?
  • How is system flow aligning to the user’s mental model?

You and I both know that we will revisit these questions in detail while we do detailed design, but we use this exercise and the following artifact to guide everything that follows.

Day 4 and Day 5 — Test and Validate

On day 4 and 5 we concentrate on testing our chosen concepts to know if are on the right direction or not. This is where magic happens. I am sure most of you have gone through extensive usability test where you have effectiveness, efficiency and other usability aspects of the system but at this point we will only test which concepts makes sense more than the others.

This can be as simple as Walk the wall exercises where the team articulates their ideas to user and clients while taking their feedback. I recommend insisting participants to sketch out the flows and concepts as you discuss. This particularly helps in two ways –

a. Giving users a sense of systems and processes and making sure they know that it’s just initial phase activity where they get to help the team to create solutions to their own problems.

b. Sketch and co-creation help them align their thoughts and think better about the complete picture. It also helps team to understand user perspective of things.

To Conclude

Obviously, there are some dramatic differences between enterprise organizations and startups. But when it comes to digital product design and development, they share the very same pain points and pressures. UX improvement for big sites and systems begs equally big questions. But no matter your enterprise-driven constraints, I can assure you that the principles we’ve explored here will dramatically shorten the distance to the answers.

“Clap If you found this article useful and let me know your views on it in comment.”

Source link—-eb297ea1161a—4


Please enter your comment!
Please enter your name here