We're currently in the midst of building the new web property I alluded to in a previous post. Before I write a single line of code, I want to have a pretty clear idea of what the user interface will look like first. I'm in complete agreement with Rick Schaut here:
“The first is that most programmers, particularly those who’ve been trained through University-level computer science courses, learned how to program by first writing code that was intended to be run via the command line. As a consequence, we learned how to implement efficient algorithms for common computer science problems, but we never learned how to design a good UI.”
I have an issue with this. Software Engineering != Computer Science.
I’m a computer scientist, not a software engineer. Recently I’ve started planning what I’d call my first software engineering project.
Sure, I’ve written tens (or hundreds) of thousands of lines of code in the last couple years. But I have very limited experience with writing a program someone else will actually use, so I’ve been hung up. I had no clue if it would be more practical to design the GUI first, or hammer out the details of the back end.
Question answered. Thanks Jeff.
I totally agree with this. If you don’t do this, you end up spending weeks if not months with feature creep and lots of “oh shit” we didn’t think of how this would affect UI moments. 37signals has a similar philosophy: http://gettingreal.37signals.com/ch09_Interface_First.php
I made the switch and bought my team licenses to “GUI Design Studio”, and wow… I HIGHLY recommend it. It certainly isn’t perfect, I see many usability issues that the developer could improve on it. But even with it’s blemishs, it is worlds above the way I used to prototype interfaces. I recommend anyone interested in prototyping check it out.
UI-First Software Development is essentially Test-Driven Development for the front-end – and I don’t mean “did Firefox catch any JavaScript errors?” UI Testing. I can see combining these two making a natural and powerful union.
I have a problem with this approach. Humans have a limited attention spans, and developers are no exception. Focus too much on the interface, and you’ll end up neglecting the architecture or, worse, the data format. Yeah, yeah, I know, the users will never see those. But they will see a bloated, buggy application that locks them in with its almost-unconvertible data formats. (Any resemblance to real-world applications is not coincidental. :-P)
IMO, the initial design step should be more abstract: “what problem do our users need to solve?” Note the singular “problem”, btw - a piece of software should solve one problem and do it well. A well designed architecture can support wildly different interfaces. A well designed data format can be implemented by different architectures. But an arbitrary interface - designed with no concern for what’s underneath - will lock the developers in now, and the users later.
Felix,
I think you are missing an important point… UI often should DRIVE architecture AND data structures.
For example… I create a UI with multiple windows that all look at the same conceptual objects. If I do that and I know they are not modal, then I immediately know I need to need some sort of observer structure to propegate data object changes. Where as if my needs on the UI are different, I may be able to skimp a little in the way I persist the data layer.
So what happens, working from UI down I am not caught in a suprise moment where a fundimental architecture decision has hamstrung my UI. While working down from the UI, you still have to make the same fundimental architeture decisions that you would make if you were working up purely from the architecture, but you can make them in light of “will they satisfy my current UI needs”.
In a perfect world we would make all our backends be able to accept anything and any kind of interface, but we all know that is an impossability. What you can do is ensure that you absolutely support your current UI needs while still eyeing maximum flexability of your lower layers.
I use paper prototyping and I love it. When I’m serious about a project it makes me take a step back from rushing into code to look at the bigger picture. Most importantly, it allows me to mentally walk through various flows of major features for an application. This ultimately informs my decision on how to structure an app and usually leads to new feature ideas which in turn fuels my excitement for the project.
Just because you think about the end users mental model first does not mean that you need to structure the underlying data the exact same way. Structure domain level data the way it needs/wants to be. Often times the two map together nicely and for the places where they don’t there is usually some code foo that can remedy the situation with little real performance hit.
Yep, if you’re building software for users, and you’re not starting with the interface, it’s very hard to take a user-centered design approach, which is really what you want to do if you’re expecting users to find your software enjoyable and choose to download/buy/use it.
I disagree to an extent that prototyping the UI on paper is universally better than using a UI designer software. Starting with paper gives you a lot of freedom to get the broad strokes right, but quickly switching to a tool like glade can help getting the interface into the hands of a sample user. It also lets the developer start “feeling” the app. Of course, you don’t want to get hung up by limitations of the tool or let the tool stifle your creativity with respect to solving your app’s unique problems.
Here’s a post I wrote about doing low-fi prototypes in Visio: http://blogs.msdn.com/jackiebo/archive/2007/02/28/how-to-create-ui-prototypes-with-visio.aspx
Yet another reason why having a skilled Interaction Designer on your team, whether full-time or contracted, is essential for success. It’s not about making the interface look pretty, it’s about having the interface make sense, right?
That’s the logical next step up from paper prototyping.
PowerPoint or other digitally-enabled prototyping is a step DOWN from paper prototyping, not up.
With a PowerPoint prototype, the polished look sends a blatant cue to the person evaluating the system: we have already designed this, we care, and if you tell us we screwed up, you will be hurting our feelings and making us do extra work.
With paper prototypes, you provide the opposite cues: this system is totally open to changes, it’s easy to change, nothing is set in stone, we aren’t married to the design, we welcome your input, you are part of the team, changing this is no big deal, it’s going to change anyway.
You can state all these things verbally, but the reality of a paper prototype states them at a much more visceral level and really removes the inhibitions, both conscious and unconscious.
Paper, post-it notes, sharpies, highlighters, pencils, erasers, index cards… these are way better tools than software tools.
Oh, and by the way, moving a post-it note from one side of a “screen” to another is WAY faster than doing it in PowerPoint. You can move two at once, float them around, try things out, undo instantly, set things aside, hand over control… The user/test subject can do it themselves without the social friction of having to say “um, would it be OK if I used your mouse to edit your document?” You could give them control of your computer, but still the difference in what they do is like night and day.
The link for GUI Patterns (http://www.welie.com/patterns/gui/index.html) in your “previous post: <a href=“http://www.codinghorror.com/blog/archives/000499.html””>http://www.codinghorror.com/blog/archives/000499.html" is broken.
I was happy to read that I wasn’t the only one who liked paper prototyping. But when you mentioned using PowerPoint as a prototyping tool I almost fell off my chair. Maybe I’m a bit skeptical because I’ve seen PowerPoint completely overused. I’ve also seen a prototype produced in PowerPoint that looked like it was done by someone in the marketing department with zero technical knowledge. Maybe in the right hands it’s a good tool…
I feel that in my case it was the other way around, when I started developing applications, I had really good “natural” skills in how to design interfaces that were easy to use, I liked trying different layouts and icons, etc. But then until I finally grasped the concepts behind object oriented methodologies, three tier design and all that, my code was a real mess. Since I had the interface almost ready, then in order to quickly have something working, I used to put code and logic in the most unusual events (click of the buttons, change of a textbox, index changed of a combo, etc…) they were really a nightmare to maintain afterwards, thanks to courses, internet and good books you start understanding the benefits of all the “best practices” … I felt bad about the code done in the past, but it feels good to evolve, if you are developing applications the same way you did 2 years ago, then you are just accumulating years of experience, but not really improving your career.
Great links to the powerpoint prototyping articles.
Here’s a very cute little tool designed to do just this.
Sometimes you do not need a swiss army knife, but just a knife. This is it.
Designing nice usable interfaces for applications is my favorite part of writing a program (not that i dislike the algorithm and code behind it part), i guess that makes me fairly unusual.
I think paper-prototyping is something most people should be able to cope with - after all, kids play with paper and crayons for hours (or they did when i was one)
The great thing about paper prototyping for me - and we used it extensively on our current product - is that you don’t invest the same amount of time in creating any part of the UI and so don’t develop an obstructive “ownership” in the design.
Use any tool, including PowerPoint, and you immediately start building up a reluctance to dismiss the idea because it looks clean and closer to the actual UI. Keep to paper and draw quickly, and if it’s not working, shred it and move on. It only took you a minute to draw, so there’s no feeling that hours of work have to be tossed.
That way the investment is in getting the design right and no one is reluctant to drop an idea because they spent ages creating it.