UI-First Software Development

We designed a touch-screen interface using 9x12" magnet white boards. We used tape to mark the dimensions of the screen. We printed pages of adhesive labels with our various widgets printed on them in the size we wanted to use, cut them out and stuck them to a flexible magnet material (like you find on refrigerator magnets). It was fast, you could see the proportions of the screen. If you wanted to note things or one-off screen elements, you could use dry erase markers. It was the smartest thing we ever did and made a huge improvement in GUI discussions. You could mock up a dozen screens in just a few minutes and then pass them around the room for people to see and comment on.

I love doing back-of-the-envelope drawings of interface elements, application flow, architecture etc. But once I start implementing stuff I inevitably discover things I hadn’t though about, and realize that other things won’t quite work as planned. So I guess it’s best to take small steps. Doing UI-driven development doesn’t mean you need to design the entire UI upfront!

Couldn’t agree with you more, paper prototyping was a hard lesson learned. I worked on an capital ‘A’ Agile project (capital ‘A’ as in Steve Yegge’s post Good Agile, Bad Agile). Anyhow, the managers/leads pushed YAGNI, and evolutionary software/UI design. At the time we all thought it seemed like a good idea - none of us had been on a capital ‘A’ Agile project. Needless to say the UI was a disaster - like a horse in blinders we all focused on what was in front of us - we ended up with Frankenstein, we had overlooked the big picture. One of the biggest lessons learned was big UI design upfront first, but no architectural / software design until later. I’m still not sure what I think about Evolutionary Software Design, it’s a neat concept, but I’d rather focus on a plan of attack.


You are giving away all our secrets as gatekeepers to the esoteric world of application dev.

This is what I get paid the bigbux for.

What’s next? A post about codesmith? Or how about Expression Blend omega-typing? You’re gonna make it seem like this isn’t hard work at all!

I couldn’t disagree with this post more. Don’t let your UI lead your requirements specification. Create functional requirements and object rules so that you know what they’re going to do before you decide how it will show up in the UI.

don’t get me wrong, I agree with Jeff’s stipulation that to the user the UI is the application, but don’t let that be reason enough to build a house without a foundation.


i’m pretty sure it’s assumed that the requirements are gathered already, before UI starts. nowhere in jeff’s post did he suggest to let the UI lead drive the requirement specification.

One advantage of working on the GUI a bit, even if you’ve already got a design in mind for the rest of the system, is you’ll discover things that users need to be able to do, and can build those tasks into the rest of the system rather than implementing them poorly (ie. bugs or confusing behavior) or just not implementing them at all.

You should iterate. Think of a general design for the UI. Think of the design of the rest. Implement some of the rest, use dummy objects with dummy data, maybe just read it from some temporary data store. Then do the GUI, and really play with it. Try to do the kinds of things users will be doing. If you did something like “user stories” then do those. Then you might need to redesign the GUI, and you might need to redesign the rest. Etc.

Oh thank god, I’m not alone.

I have spent the last 4 months trying to build a website for my business that is used totally internally and I have been fighting with GUI the whole time – trying to fit a square peg in a round whole … or more accurately, trying to fit a dozen square pegs into a few different sized holes that are less round and more oblong.

I’m with John Pirie (sp?) here. UI and backend should be decoupled. A lot of people here this and think “well, in an academic world that would be possible”. Well, it is possible in the real world, and all it requires is that things be done right.

Paper prototyping is good if you aren’t wedded to a specific UI. For instance, you start using a Windows GUI designer, and then you are screwed when you try to port that to a Series 60 interface. Or a web interface. Etc.

If the UI is set in stone, a good designer has advantages to offer – like not letting you draw impossible interfaces. Still, a paper prototype pass has much to offer.

BUT, all UI prototyping let you do is come up with the UI requirements ALONE. If your application is nothing more than a GUI front end for a specialized database, then maybe that’s all there is to your requirements.

The moment you have a single business rule that is not an UI-element, then you have to find out what the backend requirements are. The UI requirments help there, as they identify use cases. And sometimes the backend requirements feed back into the UI requirements, by showing there are user interactions required to make the process work that were not taken into account.

I agree that UI specialists are great, the same way that DB specialists are great. As long as no specialist is allowed to impose his vision on fields outside his expertise. Which, of course, requires communication between all experts and consensus-driven design. Which as we all know, is hard as hell. See also the Mythical Man-month for further consequences.

In the end, a generalist may not be able to design a system with particulars as good as those designed by experts, but whole software will probably work better, and will certainly be done faster. Such is life.

My previous and current job have both been “software engineering” jobs where we serve a large portion of folks (intranet apps for university, then county government), but have a small staff to do it with. The apps I’ve written are typically being served to a decently large scope of folks.

The first thing I’ve always looked at with new projects is the data involved. First because the client often doesn’t exactly know what data they are processing (I just want my app to to X) and secondly it drives what my UI will ultimately be like.

Is the desired application just dealing with a mass of rows and a basic query? Then I’ll tailor the app to look more “spreadsheetish” and focus on easy navigation amongst the result set. Is the desired application more of a forms processing type app? Then I’ll make sure not to overload the end user with data input, potentially step them through a few pages to enter the data, and then give the final report.

I made the mistake in my first “real world” app of not looking at the data first, going straight to UI, and wound up having to revamp a lot of code in the late phases of coding since they still wanted everything to look the same.

When working in Agile development environments, I find that there is often pushback with regard to any “up front” design work. With Interaction Design, you ABSOLUTELY have to do some up front design. You wouldn’t pour the foundation of a house before the architect decided if the building should face south in order to capture as much natural light as possible. That might seem like a minor detail to the concrete contractor, but that drastically effect the success of a building.

I have done some paper prototyping but I find that, while it is useful for myself other designers, stakeholders and test subjects don’t “get it”. I usually fall back to lo-fi mockups done in Illustrator which give everyone a better visual. I can still do a “boxes and lines” mockup in illustrator faster than paper any way and it is easier to share with others than paper.

I think whatever method allows you to be efficient personally is fine as long as you don’t get too hung up in the details at this stage. If you are mocking something up in illustrator or photoshop you can tell if you are getting too detailed by how much work it is to change. If you find yourself saying “Great… now I have to change 40 layers… I can’t believe I need to change this” then that might mean that it is too detailed and you are too attached to it.

You must remember that many changes and modifications to the design are expected so plan for it.

I totally agree with you: The UI is the first thing, a user sees and is very important. A great software with a bad UI is a bad software. 37signals say something similar: http://gettingreal.37signals.com/ch09_Interface_First.php

For the pros and cons of paper-prototyping see http://www.uie.com/articles/paper_prototyping/.

And for a great introduction to User Interfaces take a look at this MIT course: http://ocw.mit.edu/OcwWeb/Electrical-Engineering-and-Computer-Science/6-831Fall-2004/CourseHome/

Totally agreed Jeff - The customer could care less about anything behind the UI. In my 17 years of experience working both as a developer on several ISV and SI projects, the customer only cares about the UI and really, isn’t that all that matters :slight_smile:


And a great storyboard tool can be found at: http://www.stpsoft.co.uk/story/

Say yes to UI first!

I’m 100% on board with UI first.

I usually start with a quick bullet list of features/components for each page. I’ll give the items in the list a weighting too so I can determine which widget/component/element of the page gets more real estate or prominence on the page.

My next step is to browse tons of sites for good UI ideas. Some of the best sites to check out may have nothing to do with the type of app your building so its a good idea to get creative here. When I find widgets or metaphors that apply to my app I’ll print 'em out.

After that I’ll hit the notepad w/ a pencil and draw out a UI making sure I adhere to the weights that I assigned in my listing step.

Finally, its off to Photoshop. If I have a graphics person on board (which is rare… aka never) then they can start a comp while I move on to non-ui code.

After the comp is done I mark up margins etc with their sizes in pixels… then off to CSS land.

As far as code goes i’ll stub out the functions for gathering first… even if they just return BS for now. That way if someone else on the team starts on the HTML/CSS they have data to work with even if its fake. If i’m running solo I’ll take it one component at a time; write data access stuff, make it look cute, then the next component etc etc

Personally I’ve found photoshop to be the most useful tool in the process. You can get pixel perfect and all that which is a big advantage when moving to writing the CSS. You can make it feel interactive if you use layer groups… its not the same cuz you’re not hitting the submit button but its better than nothing.



I follow a very modular and component based approach. If i have all the requirements and understanding necessary to implement a component (i.e. it’s easy) then i implement it immediately, otherwise i wait on it until i have a better understanding. I guess the advantages of component based development are lost on some of us.

I absolutely disagree with this approach. I’ve just spent the past 6 months of my life groping through a tangled mess of code that has been implemented this way. The problem is that it is too easy to just add code to the form controls’ event handlers, and many coders seem to do just that (ie put virtually all the code there). This leads to a maintenance nightmare. A clear decoupling of UI from back end code is essential, and decoupling of elements within the back end is highly desirable. Whilst UI design may have some impact on parts of the back end, these parts should be decoupled from the business logic.

That, BTW, is one of the good things VB encourages.

I mean, basically in VB you draw the form (UI) first, then write event handlers (code) that is behind it.

"IMO, the initial design step should be more abstract: “what problem do our users need to solve?”“
Exactly. And this divides into two questions:
“What will our users do?” = GUI
"What do our users want back?” = GUI

The architecture and data format have absolutely no bearing on this question. They’re part of the next questions: “How do I solve this problem?”, “What problems might I encounter in 5 years?”, “Will this interface with my competitors?”

How you get there is entirely immaterial to the user, except that it must be fast enough not to annoy them. Note the word “enough”. Also, it doesn’t matter if it’s come up with a result, unless it DISPLAYS it within this time = GUI.

It doesn’t matter if you have the cleanest data format in the world, if the user can’t enter their data easily, it’ll fail. By contrast, even if the data takes up twice as much space on the drive, or requires a convertor app to interface with a competitor, it’ll have a chance to succeed. At which point you can make improvements to the way the data’s stored, now you’ve got real world data.

“But an arbitrary interface - designed with no concern for what’s underneath - will lock the developers in now, and the users later.”

That’s the point. Before you design your data format, you should know what’ll be going in, and what’ll be coming back. = GUI.
Otherwise, where are you getting your data format from?

(Any resemblance to real-world applications is not coincidental. :-P)
Some of these apps are the most successful in the WORLD, though. I’d include both iTunes and Outlook in this. Ever tried to get your music back off an iPod? Tiresome.

“I absolutely disagree with this approach. I’ve just spent the past 6 months of my life groping through a tangled mess of code that has been implemented this way. The problem is that it is too easy to just add code to the form controls’ event handlers, and many coders seem to do just that (ie put virtually all the code there). This leads to a maintenance nightmare. A clear decoupling of UI from back end code is essential, and decoupling of elements within the back end is highly desirable. Whilst UI design may have some impact on parts of the back end, these parts should be decoupled from the business logic.”

i don’t think you quite understand the point of the post. what you described is a bad practice in coding, has nothing to do with UI design upfront.

Joel Spolsky’s entry on Biculturalism is relevant here.
He claims there is a cultural divide between UNIX people and Windows people, which explains why Windows software is GUI-oriented while Unix software is command-line oriented. He explains this much more beautifully than I. If only I could post the link…