Jeff and .NET

The .NET musings of Jeff Putz

Sponsors

News

My Sites

Archives

Why UI design first is important

Like most developers, I work with other developers. Most are computer sciency and kick ass when it comes to class design and architecture. The problem with this is that this creates a UI design culture that is not always optimal.

There will always be bigger picture architectural design decisions that need to be made. So much of what we write code for doesn't even involve UI, especially since big systems are distributed and service-oriented. But when someone comes to you with something from a competitor site, and says, "I want to do this," starting somewhere deep in the application is the wrong place to go.

It's pretty easy to see the differences in the real world. Take OS X vs. Windows. I don't presume to know anything about how the development of these products really goes (except to say that Microsoft clearly sucks at it if it takes years of missed ship dates), but the end product makes it pretty obvious. Windows is driven by mountains of legacy and compatibility. OS X, on the other hand, starts with, "I want to do this, so what does the UI look like?" For example, say that you want to run a program. Windows makes you navigate a start menu that assumes too much about what you may or may not know. Try to find Excel on a friend's computer, when they try to keep their start menu "organized." Good luck with that. On OS X, I click the Spotlight icon, begin typing Excel, and there's the icon to click. The evolution of categorized portals like Yahoo to the single simple search box on Google demonstrates similar focus.

Don't get me wrong, you can get out of control. People who start building things in Photoshop or Visio are getting way too ahead of themselves. Scribble something on paper, because it's a lot faster and you won't get attached to it as easily. Start to flesh out what it is you're trying to accomplish for the user, and the fastest way to that point. Figuring out the object abstraction and data access then becomes a natural extension of delivering on that well thought out UI.

I'm going through this exercise right now at my day job (which by the way, I can't believe I've been at for a year, but that's another post). It was also the key, freeing moment for me when I started to rebuild my forum app instead of worrying about how to get my old data into it. It's amazing how much better your software can be when you focus on the task first, and the implementation later.

Comments

Ryan Anderson said:

I couldn't agree more. It always seems to amaze me how quickly scope creep rears its ugly head when stake holders get a GUI in front of them.

Once a client sees what they can have the wheels really start to spin on what it is they want, can have or more importantly need. I really like wire framing, or building mock ups with XML for example. It really saves a ton especially when designing a database back end. Now that is a little further down the road than what you are pointing out to do, but it is still a very important step after the sketching and scribbles.

I have made many, and I mean many mistakes building web applications as my skills have evolved. The one thing that has seemed to save me the past couple of years is really harping on the initial steps on "defining" requirements.

People tend to be very visual and in building the UI or at least sketching/ wire framing it out initially will save you hours and dollars in the long run.

# January 19, 2007 12:20 AM

vikram said:

yes very very true in real life situation. The UI design is as important as the architecture design and if the articture design cant give u a satisfactory UI design its of no use

# January 19, 2007 12:57 AM

Ben said:

> It's amazing how much better your software can be when you

> focus on the task first, and the implementation later.

You came very close to saying test-driven development, but not quite :)

Approaching problem you talk about in a TDD manner has deep meaning, and it's something I've been thinking about recently. At my company we use TDD for everything, but then we hit the presentation layer and find ourselves without adequate tools to continue TDD. That's one lesson currently without an answer.

A second lesson is that TDD does not automatically build the business layer interface that the presentation layer will need. Or put another way, the presentaiton layer imposes implementaiton requirements that are not obvious when you are happily constructing your business layer in TDD. Through careful imagination, you may correctly guess some of your needs, but invariably the presentation layer causes you to go back and add new methods and interfaces to the business layer - or sometimes, to add a business "wrapper" around your complicated TDD-made business layer API to simplify things for the presentaiton layer.

So TDD enforces a mental model, but the presentation layer mental model and 'language' of pointing, clicking, dragging, etc is not at all the same as the model and language resulting from using TDD to construct the business layer.

It has been said that TDD does not cross application teirs well. I disagee; I think TDD crosses DOWN through layers just fine, such as reaching into the database. TDD does not cross UP nearly as well, so you want to start from the highest application teir you can.  

My last scattered thought on the matter is that TDD helps you specify what needs to be done (business), but not necessarily how it needs to be done (implementation). I think this is a correct approach because your test harness should be as implementation-indepdent as possible. However, it does lead to the gap I stated in my first point: one is left wanting for a presentation layer harness.

# January 19, 2007 12:03 PM

Jeff said:

TDD is essential, without a doubt. But you're right, there's still that issue that in so many application scenarios, someone has to interact with it and accomplish something. That gets lost too frequently.

# January 19, 2007 12:38 PM

Dan said:

I really agree with this. My bosses are visual, they need things to look at. Mockups on paper and/or Photoshop give them a feel of what they're going to get. Better still flat HTML only when they can click things and stuff happens do they get a feel for things. It's the difference between them passing 3 date input boxes and them realising they want a date picker. The tabbing order of input fields. You have to make them sit and experience the whole shopping process rather than let them signoff on artists impressions of what it'll look like. Bosses tend not to think about the details it's a way of making them slow down and pick fault in the whole experience.

Once it's done... write the behind the scenes code.

I'm gonna plug a book by 37 signals that talks about this http://gettingreal.37signals.com/ (not free) amongst other "getting real" practices.  It's all common sense stuff but an interesting read all the same.

# January 19, 2007 2:33 PM

Jeff said:

I was resisting making a reference to that book, because it's like a cult. :) But I do agree with a lot of their principles.

# January 19, 2007 4:50 PM

Stéphane Hakni said:

True. Have you discover again Unified Process method ?

That's underly all the family developpement methods until XP programming. "Use case driven". It"s certainly the best way to reach the requirement.

# January 22, 2007 5:47 PM

Eski said:

Any suggestions on mockups for AJAX-based UI? How to ensure that UI Mockups (HTML or ASP.NET) are not throwaway once coding starts.

# January 23, 2007 8:34 AM

Jeff said:

If they can storyboard movies, I think a little UI should be easy enough.

# January 23, 2007 8:58 AM
Leave a Comment

(required) 

(required) 

(optional)

(required)