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.
Dude!
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 
http://softwareindustrialization.com/CategoryView,category,Storyboard+Designer.aspx
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.
-Arin
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.
@Felix:
"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.
@Felix:
â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âŚ