Friday January 29, 2016

Writing as Problem Solving

Several years ago I personally discovered (I am certainly not the first person to do this) that writing out problems I encounter while designing often leads me to a clear solution. This exercise began as an attempt to solicit feedback from my coworkers via email, and to this day I often write inside an email program, even if I have no intention of sending.

The exercise is simple enough: I write out my thoughts on the problem as a solicitation for help, frame it up to ask for the recipient’s thoughts at the end, review it, and edit repeatedly for clarity.

By working through the problem with the mindset of explaining it to another person, a fuller story emerges. The process of articulating a thought to someone who cannot be expected to have the same understanding of the minutia — as the writer does — forces the mind to see the problem in different ways. It also requires discovering or recalling details that may have seemed inconsequential. And, naturally, it requires broader thinking to properly situate the problem in the recipient’s mind. All of this can lead to some very satisfying “a-ha!” moments.

I’m not exactly sure why this technique seems to work so well for me, but I have a few good guesses:

Writing itself
Like note taking, the simple act of writing a thing down makes it easier to recall and work with. The words are right there, right in front of my eyes. I have to make sense of it.

Forced focus
For me, at least, writing is a focusing activity. In order to really work at explaining my issue to another person, I have to concentrate more intently than if I was simply sketching possible solutions. I am forced to physically adapt my environment to the task (no noise or visual distractions).

A sense of manageability
There’s something soothing about reducing your huge problem down to a few blocks of text. I find that the amount of text I write always makes the problem seem less daunting. Like, “This problem is only 3 paragraphs long? Whew!”

Acknowledging all the information
Since the person I am writing to is not aware of all the details of my problem, I am forced to include information that I may be taking for granted. Seeing this information written down forces me to actively deal with it in my problem-solving.

This exercise naturally forces me to repeatedly run through and remold my narrative.

It can take some time, and I can’t say that it works 100% of the time, but it does work. If you’ve never tried this approach before, give it a shot. It’s not the only way to achieve clarity, but it’s definitely satisfying.

Wednesday January 27, 2016


We in the UX business have all heard of dark patterns. These are interfaces designed to trick the user into doing something they probably do not want to do.

I’ve noticed a rise in another pattern recently, more subversive than malicious: something I like to call “jerk patterns”. Jerk patterns don’t hide their consequences, but seek to manipulate people on a more emotional level. I think this pattern has been around for a while. In fact, just today I encountered what I would consider one of these patterns as I signed out of my account, as I often do. Because I want to, that’s why.

The language Amazon used for my sign out link is “Not Jared? Sign Out”. Perhaps I am being too sensitive, but this language has always grated on me. The insinuation is that the only reason I should be logging out is if I have somehow found myself logged in to someone else’s account. If I want to log out, I have to basically acquiesce that I am not Jared, and acknowledge that I am performing an action counter to what the UI is telling me. The goal is obvious: Amazon wants me to never log out, and they have engineered an emotional way to discourage it. A jerk pattern is born.

But the jerk pattern has truly blossomed with the advent of doorslams and mainstream ad blocking. BuzzFeed recently published some good examples of jerk patterns. The email collection doorslam is a perfect example of this pattern; instead of a simple “No Thanks” as the link for declining to sign up for their newsletter, users get “No thanks, I’m not interested in protecting my skin”. Yeah, you must want to destroy your skin, you scumbag. This language is a type of shaming. A guilt trip. Backhanded. It doesn’t work on everyone, but it undoubtedly affects some.

Designers, don’t do this.

What I fail to grasp is how this pattern can possibly benefit a brand. The negativity and judgement is thick. I think we can all tell what’s happening when we see this, and it’s not a good feeling. I suppose the intricacies of brand engagement are above my head. I just don’t get it.

There is hope, however. For whatever reason, has changed its link to “No thanks, my current skin care regimen works well”.

Maybe they were shamed by BuzzFeed.

Sunday November 22, 2015

Go to the Field

A harvested corn field in Villa Grove, Illinois
A harvested corn field in Villa Grove, Illinois

I just got back from spending 2 days in the field (literally), observing and talking to farmers about how they interact with software. We’re spending the first few weeks of this new project excavating the truth by observing with our own eyes.

Before we go out to observe users, we talk to people inside the client’s organization. They frame up the problem, often paint a pretty confident picture of the way things are, and explain what should happen next. It’s not unusual for this picture to appear fairly narrow in scope — something to the effect of, “We feel like we’ve got a lot of this figured out, and now we just need help with the user experience (i.e. user interface).” The picture also asserts a certain view of the user, and supposes to portray them fairly well.

And it’s great that the client has recognized that there’s a need for UX help. It’s why they called in a User Experience design company. No matter what off-kilter perception there may be of what is needed in the way of UX, it’s usually possible to effectively refocus those expectations.

But what you can’t do is design successful software based on faulty personas. It still amazes me what a different story we can encounter when we go observe people doing their work or talking through their challenges. When clients tell me that they know their customers, and are in contact with them regularly, I don’t doubt their sincerity. But relationships are complicated, and it’s only natural that the client/customer relationship may not be entirely open. Both sides can unwittingly tuck away important feelings and facts.

Research in the software design space is nothing new, though it is enjoying a steep rise in popularity — and for good reason. There is so much that users don’t articulate through plain conversation. Going to the place where they work and observing their environment allows designers to discover not only how the user works in the context of their workplace, but also the environment itself and all those ancillary and atmospheric details that the user would never think to mention.

Go to the field. There is so much more you can discover.

Tuesday November 10, 2015

30 Days with Sketch

So. I tried Sketch.

Though Sketch has been around for a while, it didn’t really catch on in my social circle until recently. That’s likely because my circle has used Photoshop for many moons and the motivation to move to some other tool could end up being more of a bother than a benefit. Still, where there’s smoke there’s fire, and I wanted to see what all the fuss was about. So I decided to use it on my last project. Here’s what I found.

The Good

There’s a lot to like about Sketch. It is fast, vector-based, and clearly built for UI work. Like Illustrator, one of its most powerful attributes is artboards. The ability to lay out multiple screens on a single canvas is not a feature that I would have previously describes as “must have”, but after experiencing this as Sketch’s default way of working I’m not sure I could go back to having a file (or layer group) for each screen. Photoshop has recently added artboard support, so Adobe also clearly sees this as a necessary (or at least desirable) component of the modern design process.

Artboards, as nice as they are, is not the feature that seems to really set Sketch apart from other design tools. That distinction belongs to Symbols and Styles. Between these two workhorses, it is really easy to define a UI element in such a way that editing it in one place instantly propagates across all of its instances. I found that this removed the hesitation to get an idea on screen quickly because the effort of going back and adjusting the idea later is greatly reduced. This also allows style or fidelity to build over time. On my project, the client was not sure what kind of style direction to provide. No problem; I worked in grayscale and later adjusted shapes and colors within Symbols and Styles to push final visual design across dozens of elements and artboards. Easy peasy.

Exporting is also pretty great. For any element, Sketch lets you define the resolutions and filetypes of the export. Granted, Sketch makes you set up the parameters for every single element you want to export — which can be pretty tedious — but the setup is still arguably quicker than manually exporting all resolutions and formats, and you get multiple files formats exported all at once.

The Bad

As Khoi Vinh recently pointed out, the text situation is pretty tragic. Don’t even attempt to create a bulleted list inside a text block unless you intend for all the text to be included in the list. And inline indenting? Forget about it. If you are used to the bevy of typographic controls provided in Adobe tools, Sketch will leave you very disappointed. You can’t indent text within in a text block. You can’t insert a list in the middle of a block of text. There are no superscript or subscript type controls. And on and on it goes.

And then there are the crashes. Personally, I never experienced any random crashes. Mine started happening after I had about a 25MB file size. Then the “out of memory” warnings began, caused by Sketch’s failure to play nice with OS X’s autosave feature. It halts all work. The only thing worse than this is losing your work entirely. And sometimes, despite all attempts to release memory, the app crashed anyway. On the bright side, I hear this issue is fixable with a newer release of Sketch.

And The Ugly

Bugs, missing features, and frustrating results are one thing, but dishonest UI is quite another. One of the first things I became excited about upon first exploring Sketch’s feature set were the arrows. They looked so great! And then I tried making an arrow, with appalling results. There is a time and place for UI to display abstract representations of its functions, but this is not one of those places. Those arrow UI icons are liars.

I also had a poor first-run experience due to all of the shapes being tucked up under an “Insert” dropdown menu. Hiding these toolbar icons by default certainly maintains a clean UI, but it makes learning more challenging.

So will I keep using Sketch?

Probably. It’s the speed, styles, and symbols that draw me back in. That’s a potent combination. I have issues with Sketch, but I also have issues with Photoshop. Tools are never perfect, and oh boy is Sketch no exception. But I do feel like it has more going for it than against it, and that’s something.

There is one thing that nags me as I consider moving away from Photoshop that does not really qualify as Good, Bad, or Ugly. It’s the same issue that I have with designing in the browser: that the design tool will constrain the design style. Sketch caters to the design trends du jour — flat & minimalist — and that is fine under many circumstances. But that style is not appropriate for every UI. As bloated and complex as Photoshop may have become, it does facilitate many more stylistic possibilities. That’s important.

Keep on truckin’, little indie app.

Addendum; List of Grievances

  1. Sketch tries to keep the list of artboards in sync with their arrangement on the canvas. Moving an artboard typically results in the order of the artboards changing in the list. I realize this is more of a personal quibble, as others may not care, but for me it’s infuriating to have a carefully organized list of artboards blown up just because I decide to move one of them on the canvas.
  2. Having to set export parameters for every single element. My kingdom for bulk Export settings! (To be fair, it is possible to select multiple elements when setting Export parameters and the settings will apply to all selected. But this can be difficult when elements are scattered across dozens of artboards.)
  3. There are no toolbar buttons for “Back/Front” arrangement actions, but there are for “Backwards/Forwards”. This seems like a wholly arbitrary decision.
  4. Setting user-defined guides was not very discoverable. Does Adobe have a patent on the “drag guide out from ruler” method?
  5. When using the color picker you cannot move the document to get to the element that you want to color pick. If it’s not on screen, you’re just out of luck.
  6. Artboards can only be collapsed one at a time. This results is a lot of clicking when all you want to do is clean up your list.
  7. Styles don’t have much control. For example, I found myself having to create 3 different styles for text that was identical in every way except for its orientation. Since Styles saves orientation by default, I had to have separate Styles for left, center, and right aligned text. Would be nice to untick the “orientation” box on the style attributes for that test style.
  8. Lots of UI I commonly use is hidden away under popup panes. I dislike that you cannot customize the panes to show those options all the time by default instead of having to click to access. I have plenty of space on my monitor. Lemme use it!
  9. I just personally find the color picker controls to be clumsy and lacking good control. I’ve gotten used to this, though 20 years of using Photoshop will always make this a bit too basic for me.
  10. Vertex points do not snap to each other. WHAT.

Monday October 12, 2015

Minimum Viable Perspective

Browsing Netflix a few weekends ago, I happened upon Star Trek: The Next Generation. I’ve been re-watching a number of TV shows from my kid/teenager years, so I watched the first two episodes.

Man, they do not hold up. The special effects were embarrassing, the characters cartoonish, and the stories painfully silly.

But, as may also be the case with you, I remember these episodes being pretty amazing at the time. And over the course of seven seasons the show improved its special effects, developed interesting and nuanced characters, and produced (mostly non-silly) great stories. The whole show’s universe matured and deepened. Not to mention the entire audience.

For me, this is the best corollary I have found to the software concept of Minimum Viable Product (or initial release). These initial episodes weren’t really missing anything—they had actors, a story, lighting, a director, etc.—they were just less formed than each episode that followed. Although now—decades later—I can pick out low production values and other shortcomings, most of these issues were arguably not evident in 1987. They were the norm, if not above the norm. Most of the faults that I find with these episodes today only come from comparing them to later, more polished episodes and a perspective gained from decades’ worth of overall growth in how TV shows can now be produced.

An MVP has to be a whole thing. To the user, it cannot appear to be incomplete in any way. It has to be awesome. And that can be a hard thing to judge since we software-makers have a different perspective than our users. We have access to roadmaps, knowledge of unimplemented features, and a sense of what we’ll need to adjust to as the future unfolds before us. We often have the curse of being able to see 1987 through today’s eyes, and today through eyes that are never satisfied, always looking to the future.

I’ll try to remember those first few episodes of ST:TNG when I’m thinking about whether software is ready to launch or not. It may be incomplete and flawed from my perspective, but it must be whole and amazing from the user’s perspective. Keep those production values high.

« Older writing is available in the Archives.