The power of asking why, why, why, why, why.
In the job of Tool UX Design you will get overwhelmed with feature requests, Jira tickets for changes, etc. Folks will come to you and ask for all kinds of things they need. Some are specific to their own needs at a specific time, and others are daily issues they will have to deal with often. A big part of Tool UX Design is filtering and understanding what a request is intending. Finding out what the actual underlying issue is. What are they requesting, and why? And to discuss that, we first have to discuss Star Trek.
“Please state the nature of the medical emergency.”
If you’ve watched Star Trek Voyager then you will know about Robert Picardo playing ‘The Doctor’, who is a physical hologram in the medical bay. Whenever he is activated, he will ask those in the room what the nature of the medical emergency is. Those in the room will state what is wrong with the patient, who is usually unresponsive. It is then on the doctor to find out what the actual issue is.
If the people in the room were to say someone is having a heart attack, and the doctor would immediately believe them, he may end up performing completely the wrong procedure on the patient. Maybe they’re having a heart attack, or maybe they’re having a stroke. Both issues are related to blood flow, but one is related to the heart, and the other to the brain. Not that I know much about that. I’m not a doctor, I’m a Tool UX Designer!
The people in the room may not know exactly what the issue is, and the doctor still has to manually find out what is going on with the patient. Nevertheless, he will always ask what the nature of the medical emergency is, because even though the answer he gets may be wrong, it does give a starting point on where to start looking. A suspected broken toe will create a different fact finding method than someone having trouble hearing.
This means the question has to be asked, has to be listened to, but then also confirmed, and then dug into further. The same goes for the job of a Tool UX Designer. And this is why it’s useful to keep asking why.
It may sound weird, but it works
When a tool user comes up to you and asks for a feature, workflow, or change, the best thing is to keep asking why, usually a few times. You may sound weird to them, as if you’re a small child asking an adult why the world works the way it does. It may sound weird, but it works.
Let’s grab a simple example at first. A user comes to me and says the translate gizmo needs to be yellow. Let’s start off: Why? Because they are having trouble using the gizmo. Why? Because the gizmo is hard to see. Why? Because there is too much stuff on top of the gizmo. Why? Because all the assets near the gizmo are covering it. Why? Because the gizmo is rendered depending on the depth relative to the camera, and as such before some of the assets on top of it are rendered on screen.
Alright, so if we would’ve just ticketed the issue as is, and made the gizmo yellow so it’s easier to find when looking around for it, we would’ve been in a lot of trouble. We would’ve probably made a big change that would have affected a lot of people, for example by making the blue/red/green XYZ axes harder to understand by making them yellow, but above all we would not have understood what the underlying issue is.
Depending on many other factors, such as existing features, difficulty, and engineering time, there could be a multitude of solutions. Maybe we render an outline around the gizmo when it is hidden behind objects. Maybe we decide to render it last on screen. Maybe we shouldn’t have to look for the gizmo at all, and users should be able to click and drag anywhere on screen to move the selected objects around. And many more ideas!
Now you can also start finding out where else this is an issue, and if there are other gizmos that have this issue. Such as lighting gizmos, animation helpers, etc. Are they all hidden behind other objects? Why was that created in that way in the first place? Was it overlooked when it was originally built this way, or was it for a specific purpose? Is that purpose no longer relevant, or is it still being used in some way? Now you are looking into directions that can uncover bigger issues.
A lot of this initial researching and fact finding can be done without talking to a single engineer. Let them work, don’t interrupt them. They’re busy enough as is! Find out why someone requested something first. Find out what the real, underlying issue is that made them request a fix.
Something tougher, something nicer
Of course the above was a very simple example. Making the gizmo yellow? Who would ask for that? Why would you believe that at face value and send the request on through to engineering? So let’s grab a more complicated situation.
Someone comes up to you, and says that in your internal tool when you click the headers in the property panel, it should make all the options below it expand and collapse into that header. They’re also telling you that Unity and Unreal already do this, and they even show you a video of what that looks like.
That sounds reasonable, and useful! But, we have to always ask: Why? Because they can’t find the properties they need quickly enough. Why? Because they are far down in the property panel. Why? Because the objects they often use have a lot of options on them. Why? Because gameplay engineering is still iterating and trying to figure out what objects need to have what properties for the systems to work well together.
So what could be a good solution here? Again there are couple of interesting solutions, such as reorganizing what properties are where, implementing a search filter in the property panel, maybe even just implementing it if this is very easy to do with the UI system we’re using, etc, but another great one is: Do nothing!
Gameplay engineering is still trying to figure out what properties go on which objects, and doing a bunch of testing, and things will still rapidly change in the near future. Maybe those objects will split up into multiple ones, so the properties will be easy to be found. Maybe most of those properties will be hidden later on, as they are simply data that is contained within the object, but is never necessary to be touched in-editor. For now they are shown so the gameplay engineers can quickly test things out. Maybe the objects will continue having too many options on them in the future, so we can resolve this later when other systems are more settled.
The feature sounds like a great idea, it can probably help everyone who is using the property panel which is usually everyone who is using the editor, but do you really, critically, have to do this right now, or even soon? Should this be prioritized in the ever expanding list of things to do, or is there a good chance it will resolve itself over time?
Write down the issue, write down why it was requested, write down your research on the subject, and let it sit. You’ve done the legwork, so now if a similar issue comes up you can connect it to this one much more quickly. It may be good to mention the issue to a producer, to see if they have seen others struggle with this, or had any deadlines pass incomplete because of this or similar issues. Ask some more users if they find this really annoying and grating, in which case it may be important to resolve so they can remain creative. And sometimes you can find out that doing nothing is best, for now.
You have probably heard before that if you ask users what they want, they will say faster horses, while what they really need is a car. Other times though, they don’t need to go any place at all, and they’re fine where they are. It’s up to you to find out why.
“I’m a user, not a tool designer!”
I have never had a user tell me the above quote, but it is good to remember for yourself. They’re a user, not a Tool UX Designer. If they come to you with a request, be it in person, via e-mail, or another Jira ticket, the important thing is to remember they are a user. Their feedback is valid. Their opinion needs to be remembered. Their idea of how to solve their problem has to be noted. But you don’t have to do exactly what they say. Just like the doctor in Star Trek Voyager, you have to ask, but you don’t have to believe that’s all to the story. Trust, and verify.
They are having an issue, otherwise they wouldn’t be coming to you. Also remember that they have deadlines! Level designers, technical artists, etc, all have very busy schedules. If someone wrote up a ticket for you, or comes to you with an issue, then obviously something is wrong. Maybe something is wrong with the tool. Or maybe with the schedule they’re on. Or maybe with the project documentation.
Always treat every request with respect, kindness, and an open ear. Every single request comes to you for a valid reason. If your company recruits appropriately, then everyone working with you is a smart person with good ideas that is there for a reason. They may know much more about topics you have less knowledge about, and you may know more about topics that they have less knowledge about.
As always, continually and never ending, users will come to you with requests. The question you have to find out is: Why? Why, why, why, why?
Thank you for reading! If you enjoyed this post, you can find my talks here, and my other posts here.