At a certain point he alerts for the fact that developers tend to make this mistake because developers are worried about edge cases - "what if the connection to the database is broken", "what if the user isn't logged in". I agree with this, and I believe this is one of the reasons developers tend to make interfaces that are overly complicated for the common use case.
The solution seems easy, right? Developers need to take a step back from their work, look at the user-stories they captured from their users, make the most used features really obvious, and hide the rest of the clutter.
Well, nothing fundamentally wrong with this approach. I believe developers must deliver the best possible interface they can, and that requires effort and training. But I don't believe this is enough.
The problem is, when you dive as deep as a developer does on the project, it's very hard to step back and take a look at the big picture. What developers really need to do is get someone from the outside to spot the obvious errors that are just too evident to be seen by someone buried in the nitty gritty details of a project.
Again, this sounds like a simple enough solution. After all, getting someone to comment on your work isn't really hard, is it? Specially if it's about design! But the problem is that most developers don't know how to listen or how to act on the feedback they receive. It's the "what if" problem again... it's really easy to dismiss feedback based on edge conditions that happen 1% of the time. (This makes a great topic for another blog post, and I urge you to write it!)
In the meantime, no time like the present to become better at UX design. Here's an interesting webinar with "6 steps to engineering awesome user interfaces". Have fun!
(disclaimer: this is a webinar recorded by me for OutSystems, the company I work for)
7 comments:
I couldn't agree more.
One thing I remember with Joel Spolsky was "Hallway testing." Grab someone walking past you and ask for a usability viewpoint. See if they can use the application/website without asking for help.
I also posted something recently (uncanny timing with your post) in a G+ Post (https://plus.google.com/107327900154414671377/posts/UtDmbjYG4fT) asking if a developer can dress up a pig. :-)
BTW, I love the UI image you posted as an example.
I don't think it's hard to get developers to listen. I think it's hard to get users who can articulate what they truly want. I have one customer like this and they get a massive discount because of it.
@Tim: I loved your comment, because it perfectly illustrates one of the problems on how developers (don't) listen. :)
See, we as engineers have a very formal way of thinking and we are able to structure our thoughts in a logical, almost algorithmic, way. Normal people aren't like that!
Not only that, when trying to explain what their problem is, a lot of users phrase it in the form of a solution - more often than not, a solution engineers consider dumb.
The challenge for developers is to listen without judging (and without making fun of the user!), distill the feedback into the real problem users are trying to communicate, and come up with a brilliant solution that will "wow" your users!
(I really must write this blog post... :)
Aw, I don't think developers have trouble listening or acting on feedback. I think it's more that they process and express information differently to non-devs.
I'm a UX designer working in a team of devs and we rarely have trouble with conversation; the holdups are more to do with seeing things the same way. Although, I could be the 1% edge case, as all the devs I work with are personally interested in UX and UI design. :)
Good post. My principle is keep it clean and neat, easy to use. I followed that on Swing and JSP and it works.
Javin
how to solve producer consumer problem in java
@Tim
You should actually charge them more if they can't articulate what they want! :)
I've attended a bunch of presentations/training sessions targeted at developers, on how to think about UI. In everyone of them I've seen how difficult it is for developers to think past the feature and get into the user's shoes. I think it's in their nature and the only way you can change that it by constantly refocusing them on the end goal.
It's like teaching children how to eat with a fork and a knife: you need to constantly correct them until they get it right and stop eating with their hands.
Post a Comment