Geeks With Blogs
UXD with Wessty Thoughts about user experience in software development, with a pinch of awesome.

I deal in user experience.

At the core, I’m a developer. If you want to label me, I would say that I specialize in front-end development, or the presentation layer. Generally speaking, when I talk about user experience development I get the following assumptions being made:

  1. I’m a designer, and ultimately live and die by the words of my master Adobe Photoshop, but dabble a bit in software development
  2. I only see user interfaces and usability. Meaning, when it comes to anything outside making UIs look good, or gathering requirements from users.

The former is completely untrue. The only reason I have started to learn how to use Photoshop is because it helps to speak the language of graphic designers. As for the latter, if that were true then I don’t think I would be very good at building user experiences.

The fact is, if you don’t know what technologies are available to you, you can’t envision any user experiences realistically. Let me tell you my reasoning.

When I start a new project, I gather a bunch of users and get them talking about the project. As we get the creative juices flowing, I lead them onto the problem that we are trying to fix with the new system, and get them thinking big. Get them thinking as though there is no limit, or get them thinking “Blue Sky” as I tend to put it.

This is a really good way to get the team excited for the project and get them thinking outside the box. The catch is that you need to know when you pull on the reigns on the thought process and get the team to come together. The technology stack is a good way to do this.

I realize that at this point, the technology stack to be used in the project are far from being concrete. But if the UX developer knows what technologies are available, along with which ones could apply to the project, the UX that is built will end up resembling something everyone can imagine, rather than something from Star Trek.

Wessty, you’re wrong. UX shouldn’t worry about the technology, just the experience.

You’re right. Well, kind of.

I agree in the fact that UX development/design should not be constrained by the technology stack. Ideally, the developers should be able to pull together and mould the technology we have available into whatever user experience gets built.

Like I said, ideally.

In reality, projects have the project triangle to worry about. On top of that, your development team members have their strengths and it’s those strengths you will want to utilize when implementing the user experience for the project. When the users come up with an idea for an iPhone (because someone always does), and you don’t have anyone on your development team that even owns an iPhone, you need to put people back on track, and the technology stack is a great way to do that.

Before you mention it, I know that budget and scope are two other ways to bring people back on track too. I’ll tell you why I dislike using either to pull on the creative reigns.

The users you bring in to solve the problem likely don’t have knowledge about the budget, nor would they have any input on it. When you bring budget into discussion, the users become disconnected as it is something they don’t fully understand. When users become disconnected, the creativity stops. That is never good.

Scope is really just another word for budget. Sure users will understand what problem they are trying to solve, but why is their idea “out of scope”? Assuming the idea (or feature) is related to the problem, then likely the idea is too pricy to implement. In other words: budget.

Technology can be considered a budget thing too, but it is a budget constraint that users can understand. With the iPhone idea, if you explain that you are going to need buy the whole team iPhones, the users are going to understand that is an unreasonable budget request. Even if you bring up server technology, if you explain that the idea needs other computers or software that costs a lot of money, they understand it is unreasonable to request that.

Get to the Point

Fair enough. Here’s my point.

At the end of the day, it is important for the UX developer/design to know what technologies are available in the project when building a UX with users. This allows the UX person to know where they should draw the line with the ideas and keep everyone within the realm of the possible for the project.

On top of that, the technology constraint can act as a sort of common vocabulary when working with the users. Users understand that technology is expensive and can see how the excessive cost does not work for the project. Ultimately, this does not put up any barriers in way of you and the user as they feel as though they are always on the same page as you with the project.

Remember though, just because ideas are not possible for the first version, doesn’t mean they aren’t worth documenting on your side. Version one is what you are getting paid to complete, but knowing what version two and three could look like always something to keep in the back of your mind.

Catch you on the flip side.

Posted on Tuesday, November 2, 2010 4:30 AM | Back to top

Comments on this post: Knowing your Techs for UX

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © David Wesst | Powered by: