From a best practice standpoint, looking at the stuff that they have. Generally that’s a lot of things. A typical company for me won’t be that large in employee size, but it might have 25 different properties. From the logged in versus logged out standpoint of what their employees use, what their partners use, and what their users or consumers use.
Looking at all of those things heuristically and really understanding what they have. Generally I am the first person to make a picture of all of those things together. That’s a big part of what I do.
I spend a lot of time working with internal employees to understand what they have and how it got to the point that it’s at. Also how big it is. And I like to talk about how much it hurts. [Laughs] Because at a certain moment, I have to help prioritize, "Alright, well, everything is red. How red is it?" In terms of figuring out whose stuff gets fixed first, or what we restructure first, or who comes on a platform first, or who serves as a beta team. Things like that.
That upfront stakeholder and internal research to get to that picture of where they’re at can take days, it could take weeks. I’ve had it take months, depending on the size of the project and company. From there, it’s really about architecting a series of experiences for those people that are going to be working with the decision-making of what we’re going to be making to experience the user as much as possible.
Whether that involves going out and getting research done, or doing research myself, or referencing research that’s been done. In larger organizations, there’s generally an ongoing research department that you can tap in to and ask to do custom things for you, or reference things they’ve done for other initiatives.
Taking that research and formulating it into objects that can be used in a workshop to make those stakeholders and designers and business people and technologists understand who this person is, in a way that’s respectful of their time and decision-making abilities. Generally trying to get that into a couple days over a couple weeks, or a couple weeks over a couple months, depending on the size of the project.
In those workshops, we’re really getting at the crux of where the language of our users and where the language of the business may not be in agreement. A lot of that comes down to having conversations about, like, "What is our actual goal here? Are we looking at this as, we’re trying to be seen as an authority?" Because, in that case, you do want to take a different language, potentially, than your users. It still has to be one that they understand, but it might still be able to be authoritative and be your language, as opposed to using theirs. If it’s something that you want to make them feel like they’re part of a community, you’re probably going to want to have it written more in their language and designed more in their aesthetic.
Getting into those kinds of conversations and preparing people for the idea that they’re going to have to make concessions with the decisions that are going to be made. That it’s not going to be, whoever is higher up in the hierarchy of the org chart is going to get to make the decision. That’s generally a structure that does make for unhappy designers and technologists and business people and, ultimately, I think, executives as well.
Once the workshop part of my job is coming to its completion, at that point, teams are generally set out to do actions of their own. There are a lot of next steps and parking lot items that come out of meetings like that. A lot of next workshop steps, in terms of smaller workshops that they want to have with their own teams to make critical decisions. But while they’re doing that, I’m generally making some level of record of the consensus that we came to. That generally comes in the form of a map or large set of maps, depending on the context of the assignment.
That’s pretty much start to finish what we’re dealing with.