Enterprise Storytelling 2018
Enterprise Storytelling Sessions
Session Leader: Dan Willis, UX Consultant, Cranky Productions
Every year, dozens of your peers apply to tell their tales of woe, present their big ideas, and just plain rant—each in a five-minute story format. For 2018, we’ve selected these seven brave souls to tell their stories …
- Chris Chandler, Director of Product Strategy, Philosophie
- Kim Gausepohl, UX Designer, Rackspace
- Brianna Koch, User Experience Designer, AppFolio
- Patrick Leahy, Senior Designer, DesignMap
- Jesse Livingston, User Experience Researcher, LinkedIn
- Jana Sedivy, Founder and Principal, Authentic Insight
- Kit Unger, Director of User Experience, Smartsheet
Kit interviewed for the Director of User Research with Brent, the CEO of Smartsheet. He is a big guy (6’7”), he can be intimidating. She rambled on and on describing process, but he eventually stopped her and asked for guiding principles. He stopped taking notes, and admitted that he didn’t follow all of that. She didn’t think much about it, but when she was building the team they weren’t adopting the principles she was trying to instill. She loves Jakob Neilsen’s heuristics – they make her feel smart. But even she couldn’t remember all the nuances. We are making things more complicated than they really are – how we talk about our work, our title. But our work is about simplifying! What we do is about cognitive science, and using that understanding to make our designs better. She took information from gurus, and asked her team to label and describe them in cards-sorting exercise. Together, they arrived at eight UX principles, and they started using them daily. UX team members were able to explain the principles to their teams, and engineers could use them too. She has learned now that her North Star for design is to create things that are valuable to people, and the principles help her do that.
Patrick had been working with his small team for the past few months, helping their client redesign their core product. They had done research, collected personas, cerated a style guide. They were really proud of our work, and preparing to roll off the project. But then they hit a snag. In a weekly client update, they learned that the client was upgrade their existing product instead, and in only six weeks.
He realized they had dug the hole for themselves. They never asked about the client’s process, and thus with this major change he felt they were doomed. He was trying to figure out how to fix their processes, and he started helping with the Product Manager’s work. Now they were only 80% doomed. Then he looked around to see who else’s toes could he step. He made a spreadsheet for the Lead Designer, and now they are only 60% doomed. He feels like things are looking up. They could use his advice … it was a crazy idea but he drove one way three hours to the client office. It was news / criticism, delivered to the client, their external engineering team, and one of the founders. Strangely, it seems to have worked – it seems that the client will adopt the criticisms and change.
He learned that when we focused on empowering the team, we get better results. We don’t just need beautiful artifacts – as much as he loves that part of the work. We need to be producing usable software. We were feeling like we were alone in t3e bottom of the dark hole, but the reality is that the client was right there with us, terrified. We started building the ladder but the client got to finish and take all the credit.
“Are you trying to get us all fired?” they asked. She was in her first UX Lead role at a new company. She thought she was prepared for anything, but she was not prepared for this.
It was an existential crisis for her. She explored the question seriously, without bias. Her group was under pressure to sell more product and meet their numbers – and thus earn their bonuses. The Click to Cancel feature she had proposed was focused on bottom line revenue – automating account cancellation process. She thought she was a UX hero and not a UX villain. Is is possible that she was going to accidentally get everyone fired (herself included)?
Her entrance into UX was not a direct path. She worked an IT Helpdesk, and answered very repetitive questions. She went back to school to learn to design software, and eventually got a PhD in Human Factors, and now she has her first industry job. That experience does make her a competent professional. So, why did the meeting go south?
She realized that she hadn’t explain the rationale to the engineers – she went right to the design, and glossed over the rationale. Cancellation policy for an audiobooks company had been a subject of discussion at lunch, so she had mistakenly assumed they were on board – she read that as buy-in for our own cancellation project.
She had to explain that while we may not be the best fit for a customer, we still want to delight them – we need to consider that as a natural part of customer experience, and it needs to be designed with thought and consideration. Why should’t that process be fabulous? Their reaction was logical – why would we design for customers who didn’t ant to be out customers any more? People remember beginning and ends of experiences the most, so we want those to be awesome – that will be what they talk to their family and friends about. What about our entirely manually cancellation process? Through her efforts to communication, there were no further questions about the design … instead “when do we start planning?”
Jesse has been frustrated by how we talk about enterprise users, by focusing on their tasks. During his time working in the consumer space, his days were focused more on human emotion, how people feel about products and brands. Aren’t there deep human emotions behind enterprise tasks? Though his efforts, the team shifting from focusing only tasks to considering emotions, thereby transforming the direction of their product.
He was assigned to work on Data Analytics for the LinkedIn Talent Solutions product. He was brought on to create insights that would inform talent strategy. The team was moving really fast – they were deep into thinking about what content to put on the home page, what filters to put into custom dashboards. But after a few feature-focused studies, they realized something big was missing – they just didn’t understand the emotions that were driving their target users.
They just went back and listened, and that is when all the human emotion behind the pie charts started to emerge. Hiring manager would grill them about where that data came from, or how it was calculated. So they had deep anxiety about expressing that data to their hiring managers – because they are under tremendous pressure. You as a recruiter have to find two software engineers but you can’t find what you need in the local market. You can’t convince them with your data, and are just told not to miss the deadlines. Imagine how defeated and embarrassed you would be in that situation. That was the experience of many our customers.
When we really listened we didn’t hear about dashboards or home page content. The end-users asked the questions their hiring managers were asking them. That was the clue the team needed to move forward. From those learnings they established a framework. (1) The data needs to be accurate and trustworthy. (2) But that’s not enough – they need to understand it so they can defend it. Explanatory tool tips showed underlying calculations. (3) Third pillar is relevance. They built in a more guided approach, so users could get to the data they needed through search. (4) The last pillar is control – some granular controls so they can manipulate the data.
In spite of differences between consumer and enterprise, people are just people. If we want to build products that engender trust, we have to listen to their emotions.
She is three years into her UX career, but she still has imposter syndrome (though it’s better than before). On paper, she works on a super supportive team. Despite you best intentions, you might be comforting new designers in a way that is not comforting at all.
She was asked to mentor someone new, she wasn’t sure she had something to offer. She was overcoming those same challenges not that long ago. They told him he was great, they hired him for a reason, nothing to worry about. She remembers how she felt when she started. You are excited but insecure, and not knowing something can be embarrassing and overwhelming. When you try to tell them how worried you are they just tell you that you are doing great. If I feel so shitty why is everyone telling me I’m doing a good job?
When she had a chance to mentor, she gave him an opportunity to voice his concerns, and didn’t just dismiss them with vague positive feedback. There are four stages of competence – unconscious incompetence, conscious incompetence. There is a lot going on that you don’t know about. That is not a bad thing – that is the beginning of learning. People are prone to making mistakes, which are critical for learning. It is scary and uncomfortable – affirm their feelings and how we can help them. Eventually you move to conscious competence, and later unconscious competence.
Her message to us is to please step telling your junior designers that they are doing great, because it is not helping.
Raise your hand if you love estimating projects. It’s a chore, but with consequences.
This is a story about how he learned to love estimating. The craziest estimate he was ever a part of was with a large media and entertainment company on a huge and very cool project. The PMO wanted estimate that was 80% accurate. The best estimates are based it on something you’ve done in the past – but that doesn’t happen very often in our business. The second best approach is enumeration (which is a synonym for tedium).
A Mythical Cycle is bigger than an Epic. They enumerated every screen they thought they might need in those Cycles, along with the time to produce those screens, including rounds of revisions for a brilliant but challenging creative director.
When they presented the estimate, it came to $60M. They had two basic beliefs (1) somebody had a magical way to produce an accurate estimate, and (2) their slow and boring internal team didn’t know the incantations. So, they went to three partners produced their own estimates. Those partners produced estimates of $45M, $75M, and more than $100M.
He lied – the purpose of this talk is not about ways to make estimating less onerous. In reality, asking how accurate an estimate is is the wrong question. They are not prophecies, they are guesses. His recommendations are to (1) determine the riskiest, most complex part of the project, and focus on that, and (2) revisit your estimates. George Bernard Shaw said that “Plans are useless, but planing is essential.” And Mike Tyson said “everyone has a plan until they get punched in the face”. (3) Estimates are not commitments. It is a guess, and the farther out the guess, the less likely it is to be correct. So, no matter how much rigor you apply, you are not going to be right anyways. However, someone will always make a mistake of assuming estimate is a commitment – just don’t fall for that trap.
The project just completed, and the final cost was $120M.
Jana’s story is about little things that matter on a large, complex project.
When this project started, the client did not want her team there. Product Management thought the UI needed to be revamped, but it had been the purview of the engineering team for the past 15 years. The budget came from engineering, so they had to pay to fix something they didn’t think was broken.
If we have some empathy for the engineering team, we’d realize that when it comes to releasing a product, the buck stops with them. They have to get it done on time, and make sure it works – everything else is secondary. So, it is understandable for them to push back on their recommendations. She had been a developer, so she had respect for them. But that respect was not reciprocated.
When she studied HCI she thought she was going to make users’ lives better. But she has realized now that most of her job is to influence people who don’t understand what we do, think what we do is common sense, and don’t even want us at the table. In order to make headway in this kind of climate, she has five simple rules she likes to follow. (1) Show don’t tell. Demonstrate your expertise every day. (2) Admit when you’re wrong. It’s the most efficient way of building trust, because it shows your ego won’t get in the way of building a good product. (3) Details matter. We have to be super meticulous. (4) Talk often (don’t just use email and Slack). It’s tempting (but not productive) to do the opposite when the relationship is hard. (5) Pick your battles. She is not proud of this rule – we don’t serve the user well because we are tired of arguing. These simple, basic things done consistently over time yield big results.
We did eventually win them over, and most importantly, built a great product.