UX IRL Ep. 26: UX Help Desk Part 2
Hello! Here are our show notes for episode 26 of UX IRL: UX Help Desk Part 2. We hit the highlights in this article, but get the full context by listening to the episode:
The UX Help Desk is back! We are answering questions from our listeners and Redditors. If you have a question, contact us or talk to us IRL at UX Y'all! If you can't make it to UX Y'all, you can chat with us on the zeroheight Slack community (bit.ly/zheroes-signup), comment below, or reply on Twitter @uxinreallife or Instagram @ux.inreallife.
Question 1
Our take
OK! This is one way to think about it, but this is in no way ideal for us! In an optimal situation, Design would influence requirements early on in the project in a partnership with PM and Engineering.
This can depend on the maturity of the org, too. Some orgs might not be used to working with Design early on. When PMs provide requirements, you don't get much leeway in changing things to solve for the user. Essentially, you're doing production design, which most designers don't want. Depending on the organization and someone’s previous experience, there are activities that either PMs or UX practitioners can do. This overlap can feel like an intrusion, so when possible, try to level set and align on expectations.
It should be a collaboration, but we're not saying it should be creating requirements by committee. Instead, it’s about having requirements informed by different teams — research that the UX team is doing, technical or time constraints, and so on.
You might want to consider trying a tool like the RACI matrix to figure out who's going to do the work, who's accountable, and who needs to be informed. It's a great way to create understanding around accountability and responsibility. RACI’s specific labels can sometimes be confusing or difficult to apply depending on what you're using it for though. If it's challenging, there are other similar styles like DACI and more that may better suit your needs. Maybe we'll do an episode about this!
Question 2
It's been difficult to show leadership how much work our UX team has completed in a given timeframe, like in a quarter or year. Our ops team isn't sure what is the best way to measure the effort and time it takes to work and complete a project, and then translate that into a number or percent that a non-UX leader would understand
The tech teams have a way to show the amount of work they've completed in a given timeframe, but that is done through totaling story points, etc. In UX design, there's some activities that designers and researchers do that can't be translated into a Jira ticket or story point.
In essence, Our ops team wants to show the value and importance of our UX team when it comes to the development cycle and we're having difficulty with this task.
Henry V, New York
Our take
This is a common problem we hear about. In general, try defining how you measure the success of the project and thinking of how UX plays a role in that. How was UX brought in to help you reach that goal, or conversely, if UX wasn't there to help, how would that have affected outcomes?
We also think UX teams tend to be modest — we're doing our jobs to do the right thing. But when talking to stakeholders, it's helpful to call out the team's accomplishments. Highlighting these successes isn't about bragging but making your work visible to demonstrate value.
We don't get credit when UX works so well because things just work. The minute something goes wrong, people get cranky and start to ask why wasn't UX involved or why is the UX so terrible.
When our work is done really well, people don’t notice our work.
In thinking of success, consider the UX outcome, but also understand that it might take some time for that UX outcome to come about. After a designer creates designs, it might take a while before a team can code them, and it gets implemented into the product. While waiting, try to fit in some usability testing to see if you can pull some preliminary findings that point to success and impact. Work with a user researcher regarding what makes sense as data to capture to present to stakeholders.
We want to argue that you can story point design work. We get where people are coming from though. For some, UX work can feel more intangible than coding. Michelle has created a framework and taught design teams how to story point their work. When it comes down to it, teammates can break all design or research activities into tasks. We can get a good sense of how long a task will take, which we can then story point. Story pointing is a good framework that can be a great communication tool. After defining what different size story points mean, the team has a common language.
People might find story pointing a little amorphous because you can do some research activities and then find something that impacts your scope or approach. That can cause you to pivot unexpectedly, which can throw things off. But that's also why it's important to stay agile to build in that space to be flexible. Maybe we'll do an episode on how to story point designs.
Question 3
Our take
It depends! It'll depend on the app you're creating, who you're working with, product complexity, or how you work with others.
Michelle worked on a side project with her husband, and she created a mock-up but then sketched on paper all the subsequent screens. She didn't want to put in more effort with it being a side project. Her husband also understood how to interpret the sketches. This is where a design system is nice to have — you can create more screens quickly.
Some developers might be comfortable working with loose sketches, while others might need a lot more detail — especially if they're in a different time zone where you can't sync in real-time. It'll depend on whether the product is brand new or already exists. If it's an existing product, you might be able to get away with taking screenshots and just designing out the changes.
A good balance is ensuring you provide enough detail to unpack the complexity. And if it turns out to be too complex and you don't have enough time, it might be worth considering rescoping the project.
Question 4
I'm doing a little research for UX testing applications and curious if you had any recommendations? Thank you!
Devi, Albuquerque, NM
Our take
It depends! It depends on the problem you're trying to solve. Are you having trouble recruiting users? Is it something for qualitative or quantitative analysis? Do you want to do unmoderated or moderated testing? Is it a mobile or desktop app? What kind of information are you trying to glean?
There are a lot of good tools out there. We like Optimal Workshop for their information architecture-related tools. Pendo also has some tools that people can use for usability testing.
We've worked with people who've used UserTesting.com and heard good things about Maze. If anyone has any suggestions, feel free to comment below!
Question 5
Our take
As a former design manager, Michelle understands how murky this question can be — and again, it depends on the company, too.
At some companies, only senior-level designers are allowed to present to stakeholders. So you'd know you were a junior-level designer if you weren't presenting. When we worked at Citrix, everyone was allowed to present to stakeholders and lead projects regardless of level. This could blur the lines, but we saw it as an excellent opportunity for those who were more junior to get more experience.
For mid-level to senior-level designers, managers are typically looking for the ability to generate solutions independently, be comfortable doing so, and be self-sufficient in their work. It's essential senior-level designers can work independently. That includes managing their time well, meeting deadlines, and staying on task. Even if they can do great work, no manager wants to (or should) supervise a senior-level designer that closely.
Managers are also looking to see designers' strategic thinking and being able to connect the dots between multiple features, products, endpoints, etc., beyond the task or workflow at hand.
For Mary Fran, being senior means being more comfortable with the unknown. This includes recognizing where there are gaps and how to solve the gaps based on things she can control or influence. At this level, there are expectations of taking the initiative to get the info you need, communicate if something's not working well, and have an idea for how you can help. Being able to pivot comfortably and not get attached to things sets senior designers apart. Also, being comfortable working cross-functionally and building those bridges if they aren't in place yet.
Question 6
Our take
It depends! One way isn't always correct. Some usability testing might help provide insight or tracking like Google Analytics can help you understand if there's an issue.
Also, it might depend on what patterns you're using. For example, how are you indicating something is clickable? What kind of navigation patterns have you established?
Consider the labels you're using. Your primary category and items under it might not have labels that resonate in a way that people know to click on the main category. You can also make sure people can get to the information another way. If there's something vital on that top-level page that people are missing, consider moving it so people can get to it with certainty. A breadcrumb might offer a visual cue that there is another level.
Do you have burning UX questions?
Let us know, we'd love to hear what you have to ask, and we're happy to commiserate with you! Feel free to submit your question on our Google form; maybe we'll read your question in a future episode!
