When Allan first approached me about the possibility of doing some work for LessEverything, I immediately accepted his offer. I’ve followed Less for a while now, and I was thrilled to get to work with one of the top Ruby on Rails shops in the country. My first task was a total redesign of the LessTimeSpent website. The old website was an extremely simple one page design made for the unpaid beta version of the app. It provides the user with a glimpse at the app, but there is not a sufficient display of what the application does or how it is valuable to the user. A more robust website was needed for the release of the paid app.
Like every other project, I started out sketching on my trusted Moleskine. While sketching I tried to keep in mind two main things: show the user the value they gain by using the application, and display the main features of the app. Clear signup/tour buttons were also a necessity. I also came up with the idea of having a tiny widget of sorts, with sliders to show how much money could be lost every year as a result of under billing. My sketches were traditional layouts for a web app, and my first draft was good, though both Allan and I thought there was a better way to showcase the value and features of the app.
I decided to go back to sketching to try and come up with a more unique layout that only showed, in the best manner possible, the elements that were needed to accomplish the goals. With my first iterations, I had stuck with tradition, and while this isn’t always bad, I learned that different layouts can offer a better way to accomplish your goals. Once my second sketch was finish, I knew I had nailed it. Thinking a bit outside the box allowed me to come up with a really solid solution.
This layout is simple, and formed in such a way to clearly showcase the main features of the app: projects, reports, and users; the blurb beneath the logo quickly relates the value the app provides. There aren’t any elements that are out of place or unneeded. We decided to keep the money lost widget, and incorporate that and some other secondary elements into a footer.
Overall, the process went really well. Allan was clear in what he wanted, and kept the goals and requirements simple, so that I had the freedom to explore various options. If I had the option to do this again, the process could have been improved by starting with more simple and goal oriented designs, rather than trying to fit the goals into the mold of traditional web app layouts. Start to finish the project took 4 days. Both Allan and I were extremely satisfied with the final design, and I was thankful to get to work with Allan and LessEverything, and look forward to working with them in the future.
You can see the new site live at http://lesstimespent.com/
Categories: Design Process , Web Design | Comments: 3 Comments
Or, why design is more important than development. Bold, I know, but allow me to elaborate.
There is an abundance of information available on the web about design methods, but I have not read terribly much about design theory. While methods are wonderful, theory is just as important. Tutorial websites and blogs have enabled the average person to learn a specific way to accomplish a design, but design theory is what makes these methods work. Without the theory, there is no design. Now I am by no means an expert on design theory, but I do feel I can contribute somewhat to the conversation.
37Signals has written about designing before developing, but the gist of their anecdote seems to be geared towards the fact that designing (whether paper prototypes, or HTML mock ups) is faster, easier, and more agile than developing. While I would agree wholeheartedly with their points, I feel there is more to add. There is a reason why designing must come before development, and why design is, to some degree, more important than development, and here it is:
Users do not care how good the development is, what methods/languages were used, or even how it works at all. All they care about is that their assumptions about what the UI (whether a website, application, etc.) does prove to be true, and that they can easily use the UI to accomplish their goals.
This may seem obvious, or even perhaps dull, but take a moment to think about it. Every idea the user has about using a UI relates to just that: using. They want to be able to interact with a UI in such a way to accomplish the goals they have. This is all they bring to the table. When a user goes to save a project or time sheet in an online app, they don’t care that the updated info is sent to a database, overwriting the old info, and then called back again and displayed whenever the users clicks to access it. They don’t care if you are asynchronously calling in the weather, all they care about is that it’s displayed in a quick and usable fashion.
Assuming my own statement about the assumptions users bring to any UI is true, then logically it follows that they only care about the interface and how easy (or difficult) it is for them to accomplish their goals. Knowing this, then, it should be obvious that the only thing the user cares about should be designed, tested, reworked, and finalized before a single line of code is written. If possible, every use case should be defined and looked at, so that it’s clear and obvious what interactions the user will make with the UI. Once you have the hard part out of the way (creating a UI that is usable and allows goals to easily be accomplished) it should then be relatively simple to tie all of that into the back end. I’m not at all saying that development isn’t important, or that time shouldn’t be spent refining code and efficiently making functions, but the back end is not what’s important to the user.
I hope I have communicated this in a fashion that is easy to understand, and again I never claim that this may be absolute truth, however I do think the principle, and the reason why design should come first, are important concepts to always keep in mind when created a new website, application, or anything else requires interaction with a UI. Let me know your thoughts on what I’ve written, no matter if you agree or couldn’t disagree more. I’d also love some links to any blogs or sites that have articles specifically on design theory, rather than methods.
Categories: Design Principles , User Experience | Comments: 2 Comments
Listen up! I love your website. I really do. It’s a super useful location for browsing thousands of design elements. But is in in NEED. Of what you may ask, some new feature that will just crowd the UI? Nope. Some new category that we don’t currently have? Nope. Then how are we in need??
View.
All.
Button.
That’s it. Three simple words, one easy button, and a world full of win. Viewing 90 is nice, but viewing all is better. Now I’ll admit, it doesn’t take me long to edit the URL of a collection to force the page to display all of the thumbnails anyway:
http://patterntap.com/tap/collection/21/1/90
becomes
http://patterntap.com/tap/collection/21/1/259
But I have to do this every.single.time. Can you pretty please spend the 5 minutes it might take to add a View All button? I would love you even more, and I’m sure other people would as well. Come on, do it for the children.
Categories: General | Comments: 4 Comments
I’m currently reading Designing The Obvious: A Common Sense Approach To Web Application Design, by Robert Hoekman, Jr. It has been extremely useful for me so far, and contains loads of high quality information about designing web applications, everything from theory and philosophy of, to techniques and methods. One idea that Hoekman writes about is use cases.
I had never heard of a use case before reading this book, but it’s a method that seems to be great for detailing how exactly an interaction on your web app should happen. The advantage of creating use cases before you get into mock ups and prototypes is that first, nothing is cheaper or faster than writing something down, and second, this process allows you to see potential problems in an interaction, or areas that an interaction could be improved or streamlined.
An example use case (and the refining process) for a user recommending a product to a friend might look something like this:
Step 1. While viewing a product, the user clicks a button named “Recommend to a friend,” and a modal window pops up with the product title, image, small description, and a short form for the user to input their name and email, their friend’s name and email, and then a submit button.
Step 2. The user fills out the form with the necessary information and then clicks the submit button. The email is sent to their friend, and the modal window closes.
This is a good start in that the use case details exactly what is needed for the goal of sending a product recommendation to a user’s friend to be met. However their are a few areas that can still be improved. Since a user is already viewing the product, it is redundant to show them the product name, image, and description. This is wasted space and unnecessary information for them, so why show it? We can remove that to make it quicker and easier for a user to fill out the form to recommend the product (when the email is actually sent, however, we will obviously want to include the product name, picture, and description).
Thinking more about this interaction, a problem arises. We have not accounted for the possibility that the user may choose not to fill out the form. Currently, they are stuck, so we need to add a cancel button in Step 1 and an exception to Step 2, allowing the user to click cancel and return to the page without sending the email. It also might be nice for them to add a personal note, so let’s add a text field for that.
In addition, the user has no way of knowing if their recommendation has been sent: currently when they click submit, the modal window simply closes. We can add a simple confirmation notice before the modal window closes that lets them know their recommendation has been sent.
After taking out unnecessary elements and fixing several issues, the final use case for this interaction is as follows:
Step 1. While viewing a product, the user clicks a button named “Recommend to a friend,” and a modal window pops up with a short form for the user to input their name and email, their friend’s name and email, and write a short personal note in a text field if they wish, and then submit and cancel buttons.
Step 2. The user fills out the form with the necessary information and then clicks the submit button. The email is sent to their friend, a quick confirmation notice is shown, and the modal window closes.
Step 2a. The user decides not to fill out the form, clicks the cancel button, and the modal window then closes.
Perhaps this method seems pointless or obvious, but it makes perfect sense to plan and think about what exactly you want to happen before you start getting into design and code. The power of use cases is that you can write out every possible scenario for an interaction given the interface and note problems that you may not have thought of originally or areas that you can cut out unnecessary elements or features.
Categories: UI Design , User Experience | Comments: 3 Comments
For a long time, I couldn’t tell you why I designed, or what the purpose was in my designs. This was a huge problem. It’s still something that I need to consider, and indeed every designer needs to think about. Design, whether it’s for the web, an application, print, or a product, must have a telos; an end or reason for being. On the surface, this may seem obvious, but putting it into practice, correctly, is at times difficult. This is where goal oriented design comes in.
Simply put, goal oriented design has as its purpose a specific goal that the design, no matter what the medium, must accomplish. This is a very loose definition, and I’m sure others may explain it differently, but I believe it to be adequate.
Let’s now take a look at the goals that should be considered in designing a website for a web application. The primary goal would be that a user signs up for the web app. There are countless ways to design the home page for a web app, but the goal should always be in consideration. From a very broad overview, to accomplish this and have a user sign up, a story must be told.
Ira Glass is a professional story teller; also known as a radio host. He has some truly great advice about storytelling in an interview you can find on YouTube (via Lokesh Dhakar). While Glass is in radio, what he talks about is still applicable to other mediums. He states that one of the building blocks of a story is the anecdote, something which brings the listener (or in our case viewer) to a destination. It is simply a sequence of statements that conveys something: a story.
Any design then, in a sense, will tell a story. Back to our example of a web application, I believe the story must contain several key elements to truly accomplish the stated goal.
The Problem
Just like in direct response ads on TV, a problem must be brought to light that the user has, or encounters on a routine basis. No one will look for a solution if they don’t first know that there is a problem.
The beautiful LessAccounting website clearly relates a problem to the viewer. It’s obvious from the headline that accounting is stressful, and Quickbooks is time consuming and frustrating to learn. Notice also how negatives are used. This is a great example of word choice in highlighting the problem. It would be much less effective, and indeed somewhat ridiculous, if the headline read, “Finally, relaxing accounting! Stop trying to learn Quickbooks, save time and enjoy a quick and pleasing experience.” Problems should be described with negatives, allowing the user to relate to something they want fixed.
The Solution
The user must be given something that will solve the problem. LessAccounting quickly lists solutions that it provides. These little bits are part of the story, showing how the web app can solve the problem for the user. The user must be presented with an incentive to respond to: the solution to their problem is just that.
The Presentation
Thinking back to those direct response TV ads, there is always a quick, powerful demonstration of the product. This is an important part of the story, as it allows the user to see the product, how it works, and also perhaps other people demonstrating or discussing the product (in this case the web app). 37Signals, an industry leader in both web apps and design, presents their flagship application, Basecamp in near perfect fashion.
The Basecamp website clearly shows the product with a great screenshot, and also shows the companion iPhone app. The user can easily see at a glance that the app is beautifully designed, usable, and accessible on the go via the iPhone. Immediately below, well known and respected companies and organizations that use Basecamp are featured. This lends credibility and respect to the app immediately.
The Action
The story is now complete. A problem has been raised, a solution addressed, and the application presented. This step is critical, as without it, the goal is not accomplished. There must be a call to action for the users. There is a large, clear button on the Basecamp website for the user to click to see the plans and sign up for one, and it also informs the user that there is a 30 day free trial, and that the signup will be quick and easy. This button is the only button on the content part of the page; there is no confusion for the user about what the next step is.
While these rules are not necessarily set in stone, I do think these are concepts that should be included in designs for web application sites that want to successfully accomplish the goal of having a user sign up. The principles of storytelling are valuable in general, and the idea of goal oriented design is something that I think can be applied almost universally to design.
Categories: Design Principles | Comments: 12 Comments
