UI-First Software Development

For web applications we use an HTML creator such as Microsoft Expression. The key to fight the temptation to convert it into a working application is that all the pages are just static HTML. We use either links or a standard submit button to demonstrate workflow. I warn my clients before they view the Wireframes that they are ugly and only demonstrate workflow and elements, not presentation.

For Windows applications I rely on Visio, linking the pages to demonstrate workflow. To share with clients I’ll export the Visio pages to a PNG files, which I embed in HTML pages and host on a website.

I’m taking my High School’s comp sci course(basic command line java), and the teacher emphasises user friendliness even at this level. She takes our programs home, and if her 7 year old can’t run it then we get a 0.

I thought this was a joke at first because 2 days ago at TDWTF there’s a tongue-in-cheek post about FAD - Front Ahead Design. ha ha.
http://thedailywtf.com/Articles/FrontAhead-Design.aspx

I’m working off a 100+ page UI design in a pdf, done by a UI company, but that’s it. They supposedly did all this work talking to heaps of users and they can sure talk the talk. They created great looking screens, but there’s a total lack of flow, they didn’t bother giving us any use cases, and from a ‘web design’ company they expect a lot from html. Sure we’re all fancy web 2.0 jazzy widgets, proper CSS. - but you could park the death star in the gaping holes.

It’s easy to draw pictures. It’s easy to conceptualise what should happen. It’s much harder to turn it into a system.

But that’s what I do. I make shit work. As always, the devil’s in the details.

“Focus too much on the interface, and you’ll end up neglecting the architecture or, worse, the data format.”
“The trouble is, this way you often don’t get a consistent architecture but code copy-pasted into Button triggers on forms, because the client assumes that it’s 80% done and you have not time for planning…”
“There’s a total lack of flow”

So far, the anti-response seems to be “Well if you do this, you’ll end up being really careless and rushing with the rest.” I’m not convinced that this attitude is confined to that “if”. If you are committed to being careless and sloppy in all but one area, that area might as well be the GUI.
It’s like me saying “If you work on a good back-end, you’ll inevitably end up with a truly shocking GUI”. I’m not saying that. I’m saying that you’ll get a lot more information about the data required at the back-end when designing the GUI, than you will about the GUI when designing the back-end.

I’ve always found paper prototypes to be very helpful. Not least because users feel that suggested changes are ‘cost free’, as distinct from coded prototypes, where it is perceived as more difficult and costly to tweak a change. The task here is usually to offer a starting point to validate a design, with the intention of iterating to a more suitable (better) design. The methods should be appropriate for the sort of information required. Inter-panel relationships and parsing what goes on which panel can be explored with panel relationship wireframes, on paper, in Powerpoint or, my favourite, Inkscape SVG with a tiny bit of Javascript to allow a page switching presentation in Firefox. Likewise, similar technologies can be used to look at the detailed layout of what’s on a panel. However, where I want to explore the subtleties of say autocompletion in a field - which may make a big difference to a panel’s usability, paper is less appropriate. I have even prototyped in HTML/Javascript, for an HTML/Javascript Web based admin console but I knew that no developer would use my code to drive the real thing (since it’s an enterprise product, using JSPs to generate the interfaces on the fly).

I completely agree about Usability’s fundamental relationship to product architecture and on my projects, this is usually where the whole team (architects, developers, test, information developers, UCD, marketing and other stakeholders) enumerate and then detail the use cases. We’re very careful to ensure we stay implementation agnostic until we’ve got the use cases and it’s only at the prototype stage that the design implementation is realised at all.

My view is that prototyping can only be as good as the foundation on which it rests. That starts with Customer requirements, formalised into use cases, which are embodied in use case scenarios, which inform the design, which are a starting point for prototyping, which allow the customers whose requirements we’re trying to meet see if we understood what they wanted (or even if they understood what they wanted). And the hip bone’s connected to the…

One development method does not cover all types of projects. Very large projects with many forms cry out for full many design approaches to get the whole story. A small application with a single form and a small number of use cases might just as well start with the UI.

The question is how do you get a shared definition of what is needed? Words have different meanings to programmers/architects/db and users. Users need something concrete. People who actually execute work processes have to use this stuff. Most don’t understand use cases. They understand widgets on a screen.

Jeff,

Agree 100%. But decoupling the UI from the back end is as important.

UI-first always runs the risk that all the app’s functionality will get built into UI controls that the user completely changes his mind on three days later.

UI drives functionality design, but functionality implementation must be decoupled from UI.

Another advantage of paper prototyping (one I frequently employed in my previous employment) is that it forces the peer-reviewers to criticize the significant features of the UI. If I were to provide a more accurate UI mock-up, I would invariably receive criticism about the alignment, font-choice, and other trivial issues. During development, a lot of those trivialities can be changed up until delivery, whereas reworking a complex layout or adding and removing significant UI features often costs a lot more late in the game.

It is more than ‘paper prototypes’ – you actually need to know how the system should work, from the users’ point of view.

Ben Cchneiderman (http://www.cs.umd.edu/~ben/) took this a step further in 1987: design the documentation first:

Shneiderman, B. (1987), Designing the User Interface: Strategies for Effective Human-Computer Interaction. Reading, Mass.: Addison-Wesley.

I referenced the technique in my thesis, and proposed it for aircraft autoflight systems!

http://dspace.mit.edu/bitstream/1721.1/37310/1/ICAT-2000-3.pdf

Interesting, why for web design would you use power point over a photoshop comp? Designers use photoshop for design compositions all the time…Photoshop is another good alternative for laying out UI designs.

It depends, right? I agree that you have to design the UI well enough to design the program logic, and design the program logic well enough to design the data layer. But what that entails will vary from one project to another. If I’m writing something like Google 1.0 or Deep Blue, I’m sorry to disappoint you, but the UI design is so simple it might not even make it onto a napkin.

One guy I worked with insisted that you should always start with the database model. Always. Evidently he never ventured far outside his domain of data-centric applications. His approach may be fine, as long as the UI and logic are so simple that they are effectively implicit.

I’d also like to add that I’ve observed that when it comes to UI design, programmers are like the children of Lake Wobegon. They’re all above average. It’s pretty rare for a programmer to consider himself a poor UI designer. You can’t see your own blind spots. This false confidence is probably a big reason why so many programmer-designed UIs suck… even if they are done first.

I’ve never been on a team that suffered from having too many UI designers. Too few, very typical in my 15 years. A really good designer will be able to work on an Agile team – it takes knowing which decisions should be made up front, which ones can be deferred, and how to communicate them to the team.

On my last design project, I used a combination of two Visio tools with a lot of success:
Prototyping Template:
http://www.guuui.com/issues/02_03_02.php

This article and downloadable template/stencil allows me to mock-up simple web user interfaces that look “sketchy” (so users won’t think the app is almost done), but is legible (better than my handwriting).

Swipr:
http://www.swipr.com/

Allows you to create a interactive prototype from a screen flow diagram and wireframes. This took a bit of time to get working properly, but it was worth it. The result was the ability for my users to see at a higher level how all the pages interacted, but also allowed them to walk through the user interface like a simple prototype. There is some sample output at their site.

The best part of using these tools was that I didn’t end up with prototype code that I felt bad about not using.

@Bobby

Please don’t apply for a position in my development team. Coding “easy” first is the WORST way I can imagine creating a system. Quite often it’s “easy” because you haven’t come to grips the with requirements yet. I have had enough of wiping the up after coders with this “philosophy”.

Seriously though… all the people that say “you end up with tightly coupled spagetti hell” by doing UI first are missing a VERY big point. I never would recommend actually designing UI in your primary development environment. Use a graphics program or a special UI design tool. You do NO programming… you are only defining application flow, data needed, and functional requirements. You are NOT creating the actual UI code that is to be used. So when you are done with the UI “design” you can still code from the bottom. But like the house and a foundation metaphor, you now have the blueprint for the house and you can make the foundation fit it.

A big whiteboard works equally well (and is my preferred method of prototyping just about everything). Easier to “fix” things on a whiteboard than it is with paper, too.

I have to disagree with this approach. Although i have a lot of fun designing how the gui should look, i think you can spend a lot of time wasting doing this before actually doing the backend work. Believe me i have wasted many hours repositioning buttons, and aligning text, only to throw it away.

My approach for developing Applications using the Model-View-Presenter architecture and an Agile Use Case approach:

  1. Write Unit Test for the Presenter/Use Case
  2. Write the Presenter
  3. Write Unit Test for the Model/Use Case
  4. Write the model
  5. Write the GUI - this is where you have the fun :slight_smile:

You’ve done the hard work. You have implemented the required functionality based on a Use Case/User Story, now make it look pretty.

Another useful link, a list of GUI Prototyping tools:
a href="http://c2.com/cgi/wiki?GuiPrototypingTools"http://c2.com/cgi/wiki?GuiPrototypingTools/a

I wish I had time to read all the comments, so if someone already mentioned this, then I second it.

Obviously, the business goals and the user goals (not always the same thing) should drive everything and be documented in requirements, use cases, stories or whatever. Its often helpful to have wire-frame sketches of the UI so users and BA’s can visualize how they’d work with the program.

During the Design phase, the UI can be refined more with a tool like Visio or PowerPoint.

Then at the beginning of Development, the UI is finally realized, but with absoluate minimal functionality. The users can then get their hand (and mouse keyboard) on these dumb UIs and give the developers more feedback.

We always have to keep in mind that people typically think inside their little box. When we enlarge their box slightly, they are apt to enlarge their thinking. I think that was Software Development Principle #201 (201_Principles_of_Software_Development by Alan M. Davis http://www.amazon.com/Principles-Software-Development-Alan-Davis/dp/0070158401).

I also wanted to provide a link to a resource that I found very useful. “Visio - the interaction designer’s nail gun” (http://www.guuui.com/issues/02_07.php). This site provides Visio templates that can be used for low-fidelity prototypes for web and windows apps.

On the PowerPoint vs Photoshop comment…you can use Photoshop, but the users are going to focus on things like rounded buttons, shadings of controls, texture. The advantage of low-fi prototyping is that they know its a rough sketch, so they won’t focus on fluff. Photoshop can come later, like when Marketing gets it.

Like Keithius, I typically start with a whiteboard. Without that, I’d use a piece of paper and a pencil with a good eraser. Never thought of using post-it notes before.

That’s really just the first step though. At some point you need to move on to a GUI builder for your widget set. The reason for this is that at some point you are going to discover that a UI element you were planning on using isn’t really well supported for what you had hoped to do with it. When that happens, unless you can find a drop-in replacement, everything’s going to have to be rearranged anyway.

You wouldn’t use a file system for version control, you wouldn’t use a text editor instead of an IDE, you wouldn’t use a flat file instead of a database, SO WHY ARE YOU USING PAPER FOR UI DESIGN?