<p>Published on <a href="http://ift.tt/2tfYf4E">| Prototyping: From UX to Front End &mdash; Medium</a> Valinda Chan <img alt="" src="http://ift.tt/2siBX55"></p>
<h4>Influencing others to trust the UX process and consider other solutions</h4>
<p>At a 204-year-old multinational <a href="http://ift.tt/2tgaaPX">Big Four</a> financial institution like <a href="http://ift.tt/MotcYb">Citi</a>, redesigning legacy products isn’t always easy or quick. Redesigning each and every component under tight deadlines is hard enough. But do you know what’s even harder? Convincing everyone — including senior managers you didn’t even know were involved in the project — to get on board with big changes. How do you redesign a legacy product used by thousands of users across the world? Scrutinized by the most senior of management who have other priorities?</p>
<p>I’ve been fortunate enough to work with great internal clients. <strong>When I talk to people about design, they get excited about the potential of their products and are excited for change. </strong>One internal client was so excited for a redesign that after the initial conversations with my team, they went to do their own research and came up with their own wireframes they had gotten approvals from senior management to move forward with. While I was impressed by how excited they were about the UX process and how committed they were to the redesign, I felt that there was a misunderstanding about the UX Design role they had agreed I would play on this project. Awkward!</p>
<p>As I sifted through the wireframes the client provided, I came across four separate search bars displayed, one on top of another on a single page. The client explained that they had asked users and senior management about how they would like to search, and as a result of the feedback, the client came up with four different ways of searching, so they all need to be included. In addition, different users wanted to view different columns so the client wanted to include the 15–20 columns (each cell had with anywhere from 0 to 35 characters) on a table with a horizontal scroll bar.</p>
<p><img alt="" src="http://ift.tt/2tfP5Fp"></p>
<p>Still trying to navigate this type of dynamic and situation, I came up with some alternatives to their wireframes, and showed the client the simplified search process and customizable views. As with previous clients I’ve worked with, I explained to them the benefits of each, how these new designs can help solve particular problems and achieve goals, and how we can conduct user testing to validate these decisions or pivot.</p>
<p>However, they explained that they had talked to users, incorporated their feedback into the wireframes, and received approval from management on the wireframes. On top of that, they had deadlines to meet so we had to move forward — and fast — with the approved wireframes they had provided. In addition, they stated that they would like to save time and skip testing wireframes on users because those users had already given feedback and told the client what they wanted in the redesign. “I already know this is what the users want since I’ve had over two decades’ worth of experience working with these people,” the client stated. They wanted me to focus on the visual design.</p>
<h3>Empathy with clients is just as important as empathy with users.</h3>
<p>The questions that ran through my head were: Why are we so rushed that we can’t spend more time understanding the context, background, and goals? Why did the client want to jump right into the visual design? Why were there different assumptions about my role? How do people view UX Designers? Why does the client like their own solution so much? Who did they really have to answer to (boss’ boss’ boss’ boss’s boss…, boss’ boss’ boss’ boss’s peers, etc.)? What are those people like? What are the consequences if they don’t complete this project or don’t complete it on time?</p>
<h4>As I started digging, I realize that the clients were under a lot more pressure than they had communicated.</h4>
<p>There were many other people they had to answer to at the end of the day and those people’s names never came up in discussions but were just as important to the process. The client and the users have been working on this legacy product for a while and wanted certain things to stay as they were. They had invested in trainings and resources to get users to learn how to complete certain tasks, and were afraid that a redesign too different would cause trouble for some longtime users. The client also didn’t want us to test wireframes that looked different from what some of those people had already signed off on because they were afraid that those people would think we were misunderstanding the requirements or wasting their time.</p>
<h4>I bit my tongue and pulled an all-nighter on a Friday to fully consider their ideas.</h4>
<p>I know. But I get very passionate about my work and wouldn’t have been able to enjoy my weekend.</p>
<p><img alt="" src="http://ift.tt/2siv4AG"></p>
<p>I committed to spending that night going through all the wireframes the client had originally provided. As requested by the client, I made them look visually appealing and compliant with company standards. And I included these hi-fis in the deliverables along with my alternative solutions.</p>
<p>On Monday, the client showered me with praise and thanked me for understanding their deadlines and for prioritizing the project. They felt so relieved.</p>
<p>Because we were a bit ahead of schedule (thanks to the extra hours I had put in on Friday), I asked the client if they would like to hear from some more users again, and I shared with them a list of users who had asked to participate in further research sessions. I also explained to the client that we could do all this in a day and that many of these users — even those who were quite senior in the company — had reached out to me about their excitement in checking out new designs and even sent emails with suggestions after we spoke.</p>
<h4>I even suggested that the client bring the wireframes to their next management meeting and get feedback as well. The client agreed.</h4>
<p>“We’re getting really good feedback for that second option you provided,&lt;name&gt;, of the input forms,” the client called one morning a week later. “I know we originally said we wanted &lt;original design&gt; but can we move forward with this instead? And I can email you some bullets of the feedback we got since we may need to make some minor changes.”</p>
<p><em>What!? You are okay with a different solution now? And you even want to help revise it?? </em>I thought to myself. The next thing you know, we were going through an iterative process of designing, testing, revising design, testing, and so forth all the way including prototyping and developing.</p>
<p>“The users loved this new landing page we’re doing!” the client exclaimed.</p>
<p><img alt="" src="http://ift.tt/2tfZtNy"></p>
<h4>When I look back, I attribute the 180 change in our dynamic to what I spent that Friday night doing.</h4>
<p>What exactly happened that Friday night when I decided to use the approved and original wireframes the client gave me? By moving forward with their wireframes as an option, I:</p>
<ol>
<li><strong>Took a big weight off their shoulders.</strong> They were getting pressure from management about making sure there was progress. They felt nervous that they weren’t seeing hi-fis.</li>
<li><strong>Considered their perspective.</strong> I showed them that I considered their point of view, and understood that there were other people they had to answer to. Even if there were other solutions out there, I took the time to move forward with their suggestions. If someone’s suggestions are a better fit, we will find out soon enough.</li>
<li><strong>Gained their trust.</strong> I guided them and eased them into the UX process. It was new to them, and they were hesitant to go through it. I understood that different teams operate differently, and I couldn’t expect them to just jump right into our process of revising again and again when everyday, they needed to check off progress. The iterative process made it difficult for them to gauge where we were in terms of progress. However, I showed them the benefits and how what we were doing fit into the iterative process and timeline without compromising deadlines.</li>
<li><strong>Helped them build better relationships with their stakeholders.</strong> I helped them understand that even though their stakeholders signed off on certain things, they were still open to new ideas. Helping them build better relationships with the people they answered to, in turn, helped us build a better product.</li>
<li><strong>Removed emotional attachment to design.</strong> By going through with the hi-fis from their original wireframes, giving each a name, and presenting them as one option of three, I made the comparison process more objective. It was no longer “their” design vs. “my” design. They were all grouped together and we were trying to identify the best solution that worked. There were no hard feelings if users preferred one over the other because we were all partners, designing, revising and collaborating. At the end of the day, I could care less who came up with the best solution; it matters more that we have one.</li>
</ol>
<p>If I could do this project all over again, I would have my team agree on the process with the client and see if their timeline aligned well with the process. It would also have been helpful to establish clear roles and really understand the client’s needs. In addition, I would have my team find out more on the background of the project such as the client’s motivation for doing the redesign, the key stakeholders, and what success means to them.</p>
<p>There were countless times when I thought about caving in to the client’s requests. However, I couldn’t help but feel responsible for doing everything in my power — and brainstorm creative ways — to have the client consider other options so that we could have the best product possible. Just like my own in-house team, the client was part of the team too. Empathy toward not just users but toward everyone involved in the project goes a long way in making sure a project is successful.</p>
<p><iframe src="http://ift.tt/2rmUPQ0" width="800" height="480" frameborder="0"><a href="http://ift.tt/2pIip9S">http://ift.tt/2pIip9S</a></iframe><img src="http://ift.tt/2sir1o6" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou"></p>
<hr>
<p><a href="http://ift.tt/2tgjPWU">When clients want you to design but tell you what it should look like</a> was originally published in <a href="http://ift.tt/2cAqCpx">Prototyping: From UX to Front End</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.</p>


When clients want you to design but tell you what it should look like

Influencing others to trust the UX process and consider other solutions

Top Stories