Getting stuck in the details
My entire life, I have been prone to getting stuck in the details of a thing. It’s one thing to know this, and another to continuously find ways in which it affects me and for which I have developed workarounds.
I’ve learned to recognize that sudden exhaustion means that I’m stuck in the details and need to take a break.
Whether it’s my surroundings, a particular task, or a website, details are likely to distract and overwhelm me. This may or may not tie in with my ability to notice details that others overlook.
I suspect it’s much of why I have trouble with clutter in my surroundings, whether at home or in stores and restaurants. I suspect it may also relate to my difficulty with noisy surroundings.
I was reminded of this tendancy of mine during the recent outreachy project. Of course, I was also reminded of the many workarounds I’ve developed to handle it.
CSS and Coding
When working on CSS, I started to wonder if the difficulty that I have with writing code is purely about the number of details involved. I understand coding fairly well, and have no problem talking about it with those who do it for a living. At the same time, trying to write code usually results in me being exhausted and frustrated, and not actually successful at creating the code. Modifying code is always much easier, I suspect because there’s simply less to deal with and I am less likely to get stuck.
Using CodePen helped, I suspect in large part because I could see the immediate effects of what I was doing. My strong tendency to break problems into smaller pieces also came into play, as when I was stuck on a particular aspect of the CSS, I’d just clone my Pen and take out the bits that weren’t currently relevant.
Transcription, summarizing, and brainstorming
Transcription and other detail-oriented tasks
Transcribing from audio or video means I’m faced with a wealth of information that needs to be expressed in a written way. For the first in a set of items that need transcription, I always find myself getting stuck and writing down _way_ too much stuff.
I tend to need frequent breaks when transcribing, simply due to the sheer amount of information and the fact that I will start to forget what’s actually important. After I’ve done the first in a set, it is usually much easier for me to identify what’s important and what’s not, so the rest will go more quickly.
Similarly, when working on a task that is part of a larger project — as most tasks are — I can easily get stuck in the nitty-gritty of the task and forget why I’m doing it. This makes it harder to actually perform the task due to being stuck and to not remembering the purpose.
One of my most effective workarounds, in addition to frequent breaks, is to summarize what I’m doing and what I’m learning. Whether it’s in a blog post, as with the Regional Hubs project, or in talking to others involved in the project, summarizing and explaining what I’m doing never fails to get me back out of the details. Of course, it’s also typically useful for the people with whom I am conversing and for my own later use.
It is typically easier for me to write than talk my way out of being stuck, as long as I write as if I have an audience. And Medium’s interface is _fabulous_ for this. It doesn’t get in the way of what I’m trying to say, and is minimal enough to not itself act as a source of distracting details.
It’s also helpful to have written logs of conversation, which can be harder to get with people I’m speaking to in person. I retain what I read much more easily than what I hear. For this reason, having a remote job can be useful, because most conversations are written and often easily logged. This is also why I tend to try to take notes during conversation, or ask people to send me written reminders. Similarly, I’m trying to add the habit of sending a written summary of what I understood from spoken conversations when I am concerned that I missed something.
I strongly suspect this need to summarize and explain to get out of the details is why I am good at explaining things. Lots and lots of practice, plus that being how I understand things better.
I also strongly suspect this is why I so badly want other people to work with or near: other people and the need to explain what I’m doing help me stay grounded in the overall purpose of what we are doing.
Like discussing what I’m doing with other people, brainstorming with others is fabulously useful, especially if they know something different about the topic than I do. While I might get stuck in the details when investigating something on my own, having someone else there means that they might not get stuck, or at least we can work together to pull ourselves out of rat holes.
Of course, brainstorming also brings in the wonderful thing called ‘other people’s perspectives’. No one can think of everything, no matter how hard they try. Involving other people means that together you have a good chance of coming up with things that work better than what either of you would come up with alone. People are very good at building on each other’s ideas, and often find it enjoyable, as well.
Analyzing data typically involves a great deal of detail work. There is usually a great deal of data, and it’s all too easy to lose track of the big picture of why the data was collected in the first place and what the goal actually is.
I _love_ that analyzing data in the UX world is often a group experience, whether through affinity mapping, brainstorming, various methods of prioritizing, and other things that aren’t currently coming to mind. It means that I don’t get stuck as often.
In grad school, analyzing data was often an exercise in figuring out ways to not get stuck in the data and remembering what I was there for. Analyzing data alone is not good for my mental health, as I’ve not yet found useful ways to keep myself on track for long periods of time. Statistics are hard for me, not because of the math, but because I have trouble remembering what to do when or why.
I also love that in UX there are often diagrams to remind you what research methods are most useful when. I’m sure that’ll come more easily to me with practice, mind you.
Speaking of research methods…
Learning UX is full of details
I think the biggest problem that I had when trying to learn UX on my own was the sheer amount of information. Having an internship and people to work with means that I had a way to focus.
Pre-internship, having had projects that I was working on didn’t help enough in terms of focus, because there were so many options.
I tried to write blog posts about what I was learning, as you can see early in this blog. Much of the time, writing the blog posts meant that I kept finding out how much I didn’t know yet, and how much trouble I was having figuring out what to learn first.
There is a _lot_ to UX. I have the skills to do it, I know for certain. It can be daunting navigating the sea of possibilities to identify what I should focus on.
Visual Design is full of details
I suspect the trouble I have with figuring out visual design is that it’s full of details. At least when I was trying to do things in Inkscape, the sheer quantity of things that you can do meant that I often had no idea where to start. Even once I understood that there were sample style patterns in the hubs design github, there were still a lot of possibilities.
I have no idea what’s important to pay attention to in visual design. I don’t know how to tell what’s a thing that needs to be the same always (nor do I know how to make sure that’s true), and what the range of ‘reasonable’ is. And the number of tools in professional drawing programs is absurd. If I don’t know what I need, how would I possibly know what tools to use, when?
I’m sure this is a tractable problem to solve. At the moment, though, it’s an especially daunting one. It is probably not aided by my lack of visual imagination or memory.
I think this is why I’m so happy that Balsamiq exists. The number of tools available is much more limited, and rather than trying to guess what something should look like, there are a number of items that already have a template for you to use. Indeed, working in Balsamiq is kind of like having a lot of small templates that one can use as building blocks, rather than making it up as you go.
I worry that Sketch will be too flexible. I won a license for it, and I should have access to macs in my household that I can play with it on. Indeed, after this internship, I am somewhat more comfortable with the idea of playing with it. I have some visual design knowledge just by frequently referring to the protoypes that Máirín Duffy made.
Portfolios are full of details
At the moment, I am trying to distill what I did in this internship into a portfolio format. I keep finding myself stuck in details, so I’m thinking that perhaps it makes more sense to create a presentation, first. I’ll need one regardless, and those force you to stay big picture.
The world is full of details!