Thinking about the user, or “How to consider the experience”

Over at my day, evening, and night job, I just posted something on simplicity. The audience for that blog is such that I don’t really like to go into as much detail as I normally do. Lucky for me, I have all of you…

We just went through a fairly detailed critique of our application’s UI right down making sure the number of pixels used in the borders for all our dialogs were the same. Nitpicky, you say? Perfectionist? Downright anal, even? I’d be lying if I claimed I didn’t think the same thing at first. (Side note: After trying to parse that last sentence about five times, it probably has no business in a post about simplicity. But you all know what I mean so I’m going anyway.)

After looking at the final product and doing a bunch of reflection and stuff, I’ve decided it was probably one of the best learning experiences of my recent career.

Here are three dialogs that I had just done a bunch of clean-up work on (click for larger versions):

Edit StaffBook AppointmentEdit Service

All looking pretty spiffy if I do say so myself.

Now here they are in the format that was given back to me after submitting my work:

Here are some variations on what went through my head when reading this:

  • Who’s gonna notice?
  • There’s more important stuff to work on
  • WTF?

But being the passive-aggressive hillbilly that I am, I went about correcting the problems and grumbling about looming deadlines like any good hero programmer should.

Now let’s assume that I’m being honest with myself and summarize my grumblings a little differently:

  • Yes, this is important but it’s also boring and I want to move on to some real development.

(Let it not be said that self-awareness is all it’s cracked up to be.)

This is a symptom of a larger “disease” I had contracted (other than misusing “double quotes”). As a consultant in the software industry, I like solving problems. Once solved, I want to move on to the next one. But a lot of times, the problem is solved only in my head. In this example, I have three fully functional screens. All work to the specifications laid out before me. Individually, there’s nothing wrong here and because of that, in my mind, I had already moved ahead to the next problem.

But user experience is a problem. Judging from our competitors, it’s a rampant one. (Hoo-ah! Bet you didn’t think the hillbilly was capable of that kind of potshottery.) Reflecting on this recent experience, my mindset is partly (possibly mostly) to blame. I didn’t put enough emphasis on the user experience and so my thinking was: In order to succeed, we need to pump out features at any cost. This is what my thirteen-odd years in the business has taught me. As long as you don’t totally screw up the user interface, the user will adapt. And when in doubt, do what Microsoft does.

Now, me taking on the persona I have on this here blog thingy, I can tell you first-hand that simple isn’t easy. (Given how much I’ve edited this post, writing about it ain’t exactly a swing o’ the possum either.) But there’s a reward to getting the user experience right, though. Yes, there’s an emotional response that the user gets and they become champions for your software and blah, blah, blah. That’s all well and good. But thinking more selfishly, I have to work with and use this software for the rest of my career (<random deity> willing). If it has a bunch of little quirks in it that I will never get around to fix it, it’s going to start eating away at me.

QA person: “There’s a bug in the Edit Staff dialog”
Me (to myself): “Woman, that screen has always bugged me with the buttons being slightly too high and everything being a little off-centered.”
Me (to QA person): “Assign it to Mayumi

Ha ha! I jest, of course. We have no QA person. Why do you think I spent so much time automating our UI tests?

Time to wrap this up. Closing point: Creating a good user experience is a lot of work but worth the effort. For us, it’s meant taking out features that were already built until we could get the UI right. The nice thing is: once you start enforcing UI standards from the beginning, it’s much easier to maintain them going forward.

Kyle the Experienced

This entry was posted in BookedIN, User Interface. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • ChristianM

    A good UX designer would also ask the bigger questions – whether functionality can be simplified or re-organized to make more sense.

    for example: can the “client search” field be folded into the client fields in the “book appointment area”? How are search results shown? Can we reduce the number of dialogs?

    This is usually explored with UI sketches and wireframes rather than running prototypes.

  • Pingback: The Morning Brew - Chris Alcock » The Morning Brew #799

  • Steve Py

    It’s why software developers make for poor UI designers. Their vision is focused on functional, not aesthetic. UI design should always be done, or at least reviewed by an artist, even if developers have to sit down with them and actually make the changes. One of my first jobs I learned this first hand. We had a product for CD-based learning (back way before e-anything), solid, fast, best features on the market, and a slowly growing client-base… I’m not sure if it was feedback from the clients or what, but they decided to hire a graphics-arts grad to spruce up the UI. In a week it was like we had a completely different product, our lesson set looked like a legit suite of related products, each with an industry-specific theme, and suddenly sales came rolling in. All by replacing bitmaps and changing the layout.

    This is one reason I enjoy WPF. It is easy to tweak layouts, though MS has probably pushed the “designer” as a development role a bit too hard. (Expression Blend) Aside from that one early job I have never worked in a team with a dedicated graphics artist or designer working on UI.

  • Krishna Prasad Accot

    For the moment right now, I completely agree with you. But from my experience I can tell “it depends on the situation ” where you, user and the client. If you are in the beginning of the project or in beta, definitely UI matters in order to convince /impress/attract your client and users. But in the middle (now it became a part of your users life), nobody is taking care of the look. Everybody wants to finish their work as soon as possible.

    But yes, like you said “start enforcing UI standards from the beginning”. We should be really vigilant. Because whenever people come to the relax mood they start look around, everywhere and also their comparison begins…. :)

    Nice, really great reading…

  • Kyle Baley

    Don’t have that problem here. It’s a start-up company and the person in charge of the user experience and the functionality is, ultimately, my business partner. And we’ve decided that user experience is non-negotiable.

  • AhJian

    Yes, I got this kind of experience before, and its very hard when you get into this kind of user.
    They may just want to comment from pixel to pixel, rather than the functional of the system.
    Erm, somehow the person-in-charge from the user side, or the project leader from the developer side, should agreed whether “functional more important” or “UI more important”.

    If they agreed on UI more important, then it is better for the developer to sit with user and adjust accordingly. Else, it will be many rounds of ding-donging… for the UI, alignment, color. And trust me, they will forgot of what they say earlier and will make changes to the previously changes by themselves.

  • Pingback: Context Strategy | Ideas in the Making

  • Pingback: Tweets that mention Thinking about the user, or “How to consider the experience” | Kyle Baley --

  • Taco

    Pixel perfection…

    The links to the larger versions of your dialogs seem to be broken.