You know those gossipy websites that show photos of celebrities without their makeup and fancy hairstyles? At Sparkplug we have a similar dirty secret — underneath the sexy exterior and suave feel of our websites lies a series of ugly, puffy, just-rolled-out-of-bed iterations that would make the paparazzi shriek for joy.
Getting the feel of a web application right – that careful balance of design, functionality and gleeful first impression – takes a lot of sweat, and often a number of false starts. If your final release looks anything like the first draft you doodled on a cocktail napkin, chances are you’re not putting in the time to get it right.
In this article we’ll look at the process we went through to design just one screen of our TeamSnap web app – and the long journey between “it functions” and “it feels right.”
Wireframe Schmireframe
In the past we tried wireframing websites to show our clients what we had in mind, dutifully drawing in little boxes to indicate what “pieces” would appear on each page. This turned out to be borderline useless:
- Our clients couldn’t look at a wireframe and imagine anything resembling an actual website.
- Actually, neither could we.
- What we thought should be on a Web page and what actually fit from a visual perspective often turned out to be completely different.
- It’s hard to get excited by a wireframe. (Don’t discount this; passion counts when you’re building something great.)
Pretty quickly we learned that the best way to start designing the look and functionality of a website was to actually start building the website. Sure, we end up doing a lot of redesigning, but experience has shown that we’re going to have to redesign anyway, so why waste time in the beginning trying to plan what we’ll inevitably end up throwing away?
Version 1: Ugly and Unusable
TeamSnap is a Web service that helps you to manage your recreational or youth sports teams. It came about because several people at Sparkplug play recreational sports and wanted a way to manage their own teams. The application lets you keep a roster and schedule, post and send messages, store and view game photos, assign who’s bringing refreshments and track player availability for each game. We’ll look at the Availability feature in this article, because it seemed exceedingly simple at first, but turned out to be quite complex once we dove into it.
Here’s what the Availability screen looked like in our very first design mock-up:
The concept is pretty simple: List the games, list the players, provide checkboxes to indicate who’s available to play. (Note that we’re showing Manager mode here, where the team manager can edit everyone’s availability. An individual player would only be able to edit their own availability.)
Right away you can see some serious problems:
- Edit mode yields a sea of checkboxes inside table grid boxes. The whole page is visually unpleasant, boxy and difficult to read.
- On submitting this form, the database is going to have to make a server-munching 160 or more updates to save all of this data.
- There’s key information missing, such as the times of the games or a way to display availability for practices.
- We hadn’t even figured out yet what to call this feature. (“Participation” was our first stab at a title, but it sounds like a ribbon you’d get for displaying a slightly-irregular sheep at the state fair.)
Version 2: Better, But Problems Remain
After a few more iterations, and a wholesale redesign of the top banner, we came up with this version:
There are several notable improvements:
- We only allow for editing one player’s availability at a time. This prevents the sea of checkboxes and cuts down on the database hit every time the manager makes an update.
- We break down availability by gender (for co-ed teams only).
- We added in availability tracking for practices and added subtle background highlighting to differentiate practices and games. We also added highlighting to show which player is currently being edited and included game and practice times.
Smugly, we started showing this version around to our early testers. Unsmugly, we returned to the drawing board after we discovered that problems remained:
- Visually, this is quite monochromatic and doesn’t subjectively “feel” very pleasant. To put it plainly, it’s kind of blah.
- We’re worried that users are going to forget to save their changes after clicking on the checkboxes. As a precautionary step we’ve disabled all the other navigation on the page so the user can’t click away, though we suspect this may be confusing.
- This screen is going to get very wide if a team has more than eight games and practices.
Version 3: A Prettier Face
Another few iterations later, after some heavy-duty design work and some re-jiggering of features, we came up with this version. We were pretty sure we had it perfect:
There’s a lot to like here:
- Better gradients and shading to break up the monochromatic feel, plus a distinctly shaded “Manager” column to distinguish the manager functions.
- Paging in the upper right to handle an unlimited number of games and practices, plus a filter in the upper left to allow the user to show all events, just games or just practices.
- Removal of some grid lines to open up the feel of the page and prevent it from being composed of nothing but tiny boxes.
We felt pretty good about this version. So good, in fact, that it became our operable template as we began building the Availability back-end in Rails. Soon, however, programming ground to a halt as we launched into what became known as The Great Debate.
The Great Debate
Our Creative Director felt very strongly that there should be only two states for Availability. Either you were available (green dot) or unavailable (no dot). He didn’t care if you were a “no,” a “maybe,” a “don’t know” or a “have to check with my spouse.” As a manager, he simply wanted to know: Can you commit to being at the game?
Our Development Director felt equally strongly that it was important to know if someone couldn’t be there. Without being able to distinguish between “no response” and “no,” you had no way of knowing who might show up and who wouldn’t.
After debating this internally for several days we did what we should have done in the first place: We called up a few team managers and asked them what they wanted. The results were unanimous. They wanted to know if someone wouldn’t be there. They wanted a red dot.
Victorious, we began to add this to the system, only to realize something very troubling: We now had three states (yes, no and unknown). Unfortunately, an HTML checkbox only has two states (on and off), so there was no way to represent the three possibilities. If a checked box meant “Yes, I’ll be there,” what did an unchecked box mean? It couldn’t both mean “I won’t be there” and “No response.”
For three-state choices, you need drop-down menus.
Bring on the Drop-downs
Frankly, we hated this next version. From a usability standpoint, drop-down menus require a lot of finicky pointing, clicking and dragging, which makes them slow to operate. They also require reading instead of iconic recognition, which makes them slow to parse. Functionally this worked. Feel-wise this was less than ideal:
We also explored the possibility of three radio buttons for each event, but rejected that as being absurdly cluttered, or in designer’s parlance “butt ugly”.
The Obvious Solution – Finally
What we needed was an HTML widget that didn’t exist – the multi-state checkbox. Luckily, with some graphics, some Javascript and a bit of pluck, we realized we could build our own. Our homegrown checkbox had three states – empty, yes and no. Just click to cycle through the three options:
Even better, by hooking the checkbox code directly to the database with some fancy AJAX wizardry, we completely eliminated the modal editing state. Instead, you are always in edit mode with no need for an Edit or Save button. Every time you click a checkbox your availability for that game or practice is immediately recorded to the database. It’s much simpler and goof-proof for users, yet these always-clickable checkboxes are so visually pleasing that they never feel overwhelming, even with many on the page.
We also use AJAX to immediately update the total available players count in the footer, adding a subtle blinking effect to visually confirm that the change has been recorded. Alas, a static screenshot can’t give you the emotional satisfaction of actually poking the AJAX widgetry yourself; if you want to try it out you can sign up your own sample TeamSnap team (for free) and give it a whirl.
This final version also has a few more visual tweaks:
- Player thumbnail photos, which make it much easier to visually parse who you’re looking at for each row.
- Some more visual and typographic changes to the list of games and practices in the header row, including colored flags to differentiate between games and practices/events.
- The inclusion of a help tip that appears when the user first visits the page (hidden in the screenshot above, but triggered by the blue “i” next to the paging icons).
Perfect? Hardly.
Happy as we are with this version, we know that in the coming months we’ll continue to tinker to improve this screen further. There’s no such thing as being “done” in a Web application. Our users have already suggested ways in which Availability could be improved, including:
- An additional state for the checkbox, to differentiate between “Not Sure” and “No Response.”
- The ability to use the information from this screen to set game lineups, allowing the manager to “lock” availability close to game time and assign positions, as well as export a printable lineup card.
- Allowing players to set their availability by clicking on a link in an email, bypassing this screen altogether
These are all good ideas, and in the coming weeks we’ll be evaluating them to decide which can be implemented without making the basic functionality of the Availability screen too complex. Before adding any feature we look for the right balance of simplicity, power, utility and feel. Because no matter how handy a feature is, if it doesn’t feel right people won’t use it.
Getting from functional to “feels great” can be a long process, and sometimes it’s frustrating to tinker with existing features when you want to be adding new ones. But the payoff – a page that just looks and feels right to the user – is worth the time spent on each revision.
Great look into the iterative design process. The end result, TeamSnap as we see it today, is gorgeous on so many levels.
Really cool post.
About adding a “Not Sure” state to the checkboxes, I suggest you read this article from Zeldman: “Maybe” is one option too many
I’m pretty certain the team managers would not appreciate “Not Sure.”
Ahah… the evolution of the Thighty Whities………..
Vijay
This is a great example of an iterative design/development process (with a great result I have to say). We have also dabbled in prototyping wireframes for clients, and i completely agree that it can be fairly useless - infact our first attempt was a disaster. The client would come back with feedback such as “I dont like the link style on the main navigation” or “there isnt enough colour”. Explaining to them that there are no link styles or colours, only to be met with blank faces, is nothing less than awkward! Perhaps it is time to do away with wireframing…
Always nice to see good use of rails and ajax by the way :)
Thanks, Chuck!
Our bigger issue with wireframing is that it creates the false impression that you’ve made some final decisions with the client. Once the wireframing is complete, supposedly you’ve locked down the items that are going to be on the page, but of course as soon as you actually build the page the client realizes that they are missing some stuff that they just couldn’t think of or picture during the wireframing process, and thus you’ve just wasted days or weeks trying to lock something down that is not really locked.
We don’t blame our clients for not being able to work with wireframes, by the way. It’s just not realistic to scope out something that’s a visual tool using boxes or words; it would be drawing a stick figure, labeling it with words, and then asking someone if this looks like someone they’d like to date.
[…] June 25th, 2007 in Links A design walkthrough of Teamsnap, showing improvements over a few iterations. […]
Thanks for the insightful article, Andrew. It’s always great to hear about the processes others follow.
The great danger in implementing custom form elements is that it’s easy to forget all the intricacies of how a form element behaves. They’re often deceptive in their complexity, and rebuilding a widget from the ground up can be a daunting task.
I signed up to see your implementation in action, and it’s good to see that the tri-state checkbox is navigable with both the keyboard and the mouse. Unfortunately, you’ve built a dependancy on JavaScript, and without JavaScript there’s no basic version of the page. This is 2007 - progressive enhancement is well understood and well documented. It’s not cool to leave users out in the cold in this day and age.
Designing for a non-JavaScript experience is let another complexity to throw into an already complex mix. As professional web developers, however, that’s a challenge that can’t be ignored or postponed for a later release.
The app looks great and genuinely useful. Thanks again for the article.
Thanks, Drew!
We decided early on not to support non-JavaScript users. The amount of extra development necessary to support that small percentage of users couldn’t be justified in terms of the potential return. From our standpoint it was an easy business decision. For what it’s worth, we haven’t received any negative feedback from users on this (and our users have been extremely vocal about what they like and don’t like).
We totally appreciate the philosophy of not leaving anyone out in the cold, but from a programming resources standpoint it was the right decision for us.
Thanks again!
Hi Andrew,
First time read, saw it via Digg. I enjoyed looking at your process.
I have to disagree with statements relating wireframing to being “borderline” or “fairly useless.” Yes, for the client to perceive a stick figure, it’s unhelpful, and quite frankly, I understand the reasoning to keeping such documents for internal usage.
But let’s say we have an Information Architect and Web Designer.
The IA comprehends the requirements of the page, and strictly works on framing the page in a way which will work efficiently and allow maximum comprehension of the page without any bells or whistles.
The designer can make changes and improvements, but at least they have a framework in which to base their explorations on.
I think it’s much easier to design work from a basic statepoint (a sketch, a wireframe) and evolve it from there, not unlike storyboarding a movie. Jumping into the fold limits the methods of quick exploration. From a developers standpoint, I suppose you knew you’d have the opportunity to redesign it sooner than expected, whereas in other contexts, one is only given the chance to redesign it once every few years.
Regardless, great work. I’ll be referring the application to a friend of mine.
Interesting article, i’m glad you framed it with the point that this is YOUR way of developing this web-app for YOURSELVES. You discount wire-framing as a practice stating that you can’t seem to get your clients to understand what they are. How large is your staff and what are the communication requirements between that staff. James Teow’s comment is right on in that wire-frames can be invaluable for internal communication. In today’s world of hybrid designer/developer types maybe one guy does all the work per project in your shop but my humble opinion is that it’s good practice to adopt a real process that includes Information Architecture/Requirements Gathering and User testing regardless of if it doesn’t “feel right” to you while your engaging in it in the moment.
I’m also a bit alarmed that on your journey from “it functions” to “it feels right” you don’t mention actually putting users behind the site other than yourselves during the development process.
That’s what’s wrong with all this “Web 2.0″ web-app development, we’re all learning some really bad habbits that don’t help us when confronted with a real-world client engagement. On one hand it’s exciting to be back in the cowboy days of web development but on the other hand this stuff doesn’t hold up under the straigns of a large scale client project where documentation and user experience engineering needs to be executed at a high level the first time.
“Luckily, with some graphics, some Javascript and a bit of pluck, we realized we could build our own.”
Oh noes, why not stopping at the drop-down-box iteration, instead of inventing new widgets? Webdesigners should *not* invent new (in most cases badly designed) widgets or new interface elements. Do not try to invent:
* Pseudo HTML drop-downs (you can structure drop-down content with and CSS), because drop-downs work in a very distinguishable way, which you won’t be able to reproduce, like reaching out of windows, scroll wheel, fast scrolling, keyboard navigation, etc.
* Tri/Multi-state checkboxes (users are used to the on-off-scheme, no one expects additional states)
* Checkboxes which work like radio-buttons (why not use radio-buttons if they should behave like them?)
* Sliders (no way to numerically see the current value or enter it this way, difficult to use)
* Links as submit buttons (there is a reason why is always a button or an image)
….
Cheers
Good article. I’m learning javascript and ajax at the moment so found it enlightening. One question though; how long did each version take to make and what was the time frame from planning to the ‘final’ version?
What did it changed in terms of time/task/user?
[…] Web app without makeup: The design iterations of TeamSnap “A web app can look rough first thing. Andrew Berkowitz … takes us through five iterations of a single screen of web app Teamsnap, as it blossoms from “ugly and unusable” to “just feels right”.” (tags: web software design) […]
Did you consider any increase in bandwidth/DB usage by the tristate checkbox? For example, you may have many people clicking twice on each cell (and therefore two calls and two db hits) to make their choice. If you add extra states this would escalate the issue. This might be a fair trade-off for the ease-of-use and look, but just curious if you approached that, and if there was some sort of solution like a timer check so if they clicked twice in succession you only did one hit (or whatever)?
Hi All,
I wanted to respond to a few of the great comments and questions that folks have posed:
On wireframing…
We’re not militantly opposed to such things, and of course IA has its place in any web project. Any project needs some sort of feature list, outline or whatever. Our point is that typically a TON of time gets wasted trying to “perfect” a wireframe before design even begins, and usually that time is better spent just getting something imperfect onto the screen and then refining.
Whether on an internal or client project, we always start with a scope of work, outline, and, in some cases, a screen-by-screen breakdown of basic functionality, but we try not to waste any more time than necessary thinking of everything ahead of time and doodling page after page of wireframes, because we know it just doesn’t pay off for us.
But if it works for you, more power to you! There’s certainly no right way to do all of this and the scale of the project may dictate how much wireframing you want to do ahead of time.
On testing…
We do a ton of testing, internally and externally. This article glossed over that a bit, but be assured we put real people in front of our screens early and often. The results are often quite humiliating. We also do a lot of pre-design research that we think is unique to the industry and we’ll have more to say about in the future.
On inventing new widgets…
I have to admit that I hate sites that duplicate existing HTML controls with no added functionality. But our three-state checkbox does not exist as an HTML control and from a usability standpoint is far superior to a pop-up menu or radio buttons. Importantly, the checkbox we created does not attempt to look like an existing widget, so users don’t expect one behavior and get another.
I’ve seen a lot of sites that create new interfaces to be “cool.” We created this interface widget because it was the best way (in our opinion and in our testing) to solve a problem. We believe you should use the best tools available to solve a problem, and by “best” we mean it should be easier for user to use, and not confusing.
On time frame…
I don’t have a good answer for that, because in some cases we had to delay development temporarily to work on client projects, or to wait to line up a new set of testers for a particular screen (this article also omits a number of interim designs that weren’t quite different enough to merit including).
It helps that our lead designer is wicked fast and insanely talented.
On bandwidth/DB usage…
We have seen no ill effects of making a database call on each click of the checkbox and haven’t needed to run a timer or check for two clicks. Availability is actually not something that users fiddle with that often, so compared to everything else on the site that is hitting the database it’s pretty negligible.
Thanks again for all the comments and questions!
Andrew
Certainly think that in the increased interactive paradigm world of Web2.0 simple wireframes aren’t cutting the mustard … but but but, still not convinced the above will give a good indication to either client or development team.
To be honest I’m leaning more towards dynmaic HTML wireframes - or even simple Flash prortyping that cna show user journeys … however your above solution and what I’ve just outlined is fine if a) your IA / Interaction designer can build more interactive prototypes andf b) and this is the biggy, you have a decent whack of time and budget to do this …
In the end the good old paper wireframes done in Visio or Freehand (sadly gone so now have to stitch together 100s of PDFs in Illustrator!) may be the most cost effective answer and you just have to make them as thorough as possible and expect the developers to be constanlty coming up and saying:
“So OK, what happens when the user clicks that link then buddy?”
As a tesxt case we’ve just developped a livemusic community in PHP that had many of theses issues … and still has a few. A more thorough user flow journey plannig would have helped if i’d had time and budget to burn … but I didn’t. In the end I think we did everything from concept to delivery in about 10 weeks… that’s too short to do anything properly really!
hey, I’d date a stick figure, if those words were sayin’ the right things
This is an excellent article. It shows the power of the type of iterative development which puts a premium on making things visual as soon as possible so the team can get the widest, best possible feedback when it counts the most.
In my own work I tend to draw the line at making non-standard widgets. However, in this case, the hybrid checkboxes are clear in meaning, use screen real estate very efficiently — and add a clearly saleable “cool” factor to a commercial product.
We’re currently working on a new webapp and going through much of the same process you’ve talked about here.
One question remains in the final design:
” This screen is going to get very wide if a team has more than eight games and practices ”
You’ve posed the question on the second design revision, but in the final design I believe there could still be a problem regarding the available space.
Thanks for sharing your insight.
” This screen is going to get very wide if a team has more than eight games and practices ”
We added paging (see upper-right corner) on the third iteration.
Thanks!
Andrew - congratulations again to you and Matt on Teamsnap. And congratulations on your first Vitamin Article!
I wanted to let the readers here know that I have done a lot of work with Sparkplug in the past and they are simply a marvelous company. I don’t think that I have ever worked with a company which was more organized, more user-centric, more friendly and fun to work with, or with more processes in place for success. I have often held them up as a model and used lessons learned from them to encouraged others to do things “right.”
It’s really easy, when reading one article, to find things to be critical of. And that can be a great thing - it can spur thought-provoking discussion and can be enlightening. However, I must say that in the case of Sparkplug, while I’m sure they aren’t “perfect,” I can’t imagine doing things much better than they do.
Andrew - you have always been very friendly and approachable. It’s great to see the way you’ve handled criticism in this post. I have a lot of respect for you - keep up the great work!
[…] Vitamin Features » Web app without makeup: iterations of TeamSnap (tags: design) […]
Thanks for the article and insight to your process.
I’d like to know if you have any usability issues with the 3-state checkbox? Though I think its simple and intuitive enough, were there times when users were lost or not know what to do?
I love how awful the first idea was. I know I’m one to try to perfect it the first time. The problem is that I end up losing the time I could spend improving it.
My best designs are always the ones where I open up PhotoShop and just go for it. The ones where I set up my grid, calculate where I can use the golden ration, sketch it a millions times, etc, don’t always end up so rewarding.
I work for a small firm and we don’t ever really show wireframes to clients; nothing more than a site diagram at least. However, sketching out wireframes in a notepad for my own personal use when designing and developing is natural, and necessary.
Quick question, but how do you justify the AJAX changing the status as every time the button is clicked a new request will be fired off, if you’re clicking twice to get to the third option you’re sending a needless request.
…probably a bit pedantic but it’s something I’ve always thought about. Really enjoyed the article.
Mani — Thanks for the wonderful compliments. We’ve loved working with you as well!
I’d like to know if you have any usability issues with the 3-state checkbox? Though I think its simple and intuitive enough, were there times when users were lost or not know what to do?
We’ve not run into any problems. It’s pretty forgiving because even if you don’t expect that third state, by the time you hit it you kind of figure out what’s going on. It’s a pretty simple widget. (And we have a help tooltip.)
Quick question, but how do you justify the AJAX changing the status as every time the button is clicked a new request will be fired off, if you’re clicking twice to get to the third option you’re sending a needless request.
We decided a needless request was going to be more reliable than putting the update on some sort of timer. This way we guarantee that we catch the right state. Overall, availability just doesn’t hit the DB that hard, anyway. If we were trying to squeeze out every last savings in DB hits there are a lot of other places we could optimize. Again, your mileage may vary, but this works for us.
Thanks!
Oh, one more update. Since we wrote this article we’ve added two tweaks to the Availability page.
1) Duplicated the available players count at the top so you don’t have to scroll all the way down to see how many players are available.
2) Added a rollover tooltip to each checkbox so if you have a very long roster and the game/event details have scrolled off the top of the screen you can still roll over each button to see which game/event is applies to. That was definitely an issue and we like this unobtrusive solution.
[…] schoenes beispiel für einen iterativen design prozess und anregende diskussion zum thema wireframing […]
[…] Web app without makeup: iterations of TeamSnap […]
[…] July 3rd, 2007 Web app without makeup: iterations of TeamSnap - personally I prefer paper prototyping, that way when everything is laid out on the table and the client says how do I get from point G to point H and there isn’t a viable way, you know you’ve made a mistake somewhere. The client also gets a feel for the flow. Each to their own though. […]
[…] Web app without makeup: The design iterations of TeamSnap […]
[…] Link […]
Nice read.
In my experience, plans are great for products once they’re in the “OK, now just make it” stage (such as a bridge once the drawings have been approved). For everything else, including products where the client doesn’t run the show all the way through (as is the case in the vast majority of cases), and including anything that requires creativity, iterative development is the way of the future.
In fact, it used to be the way of the past - in the 80s, most computer software products came about this way. Plans are great, if they plan “work”. As in “order 800 fundaments from the foundry”. If they involve development, let the creative people develop. Apart from checking that the creative team actually develops, there will soon be no need for project managers in creative projects.
[…] Vitamin Features » Web app without makeup: iterations of TeamSnap (tags: ui webdesign wireframes inspiration design) […]
[…] Vitamin Features » Web app without makeup: iterations of TeamSnap - Killing wireframes with iterations […]
[…] A warts & all review of the design iterations of Teamsnap. […]
[…] Steven Montes wrote an interesting post today onHere’s a quick excerptYou know those gossipy websites that show photos of celebrities without their makeup and fancy hairstyles? At Sparkplug we have a similar dirty secret — underneath the sexy exterior and suave feel of our websites lies a series of ugly, … […]
[…] Passiamo al workflow e al processo di design. In Web app without makeup: iterations of TeamSnap su Vitamin viene presentato il processo di miglioramento di un’interfaccia complessa in cinque passi. Stessa tipologia di articolo, Improving the User Interface mostra come si possa rendere visamente accattivante e moderna l’interfaccia di una web mail. […]
[…] read more | digg story […]
Look this site
http://www.ooyes.net
Nice read.