photo credit: victoriapeckham

We have reached the most critical point on a project I'm working on. After a few months we think we know enough about the domain and application to build a product road map that will take us to the first public release. The proof of concept is complete. The design team has created a remarkable, genera changing product. Additionally, the system is designed around real users we have been able to talk to and get feedback from. We have put together an unbelievably good development team and built a backlog of stories with estimates. We have been here before. Putting together a design and backlog of stories is something we have done countless times...

The easy part is over. Now the hard part begins.

Our research and user feedback tells us we have multiple potentialcustomer groups we can build the system for. On one hand this is great news. We have a number of potential markets to choose from. On the other, we don't have an infinite amount of time and money to build it for all of these groups. We have to commit and go all in with one group. Right now, these are just some of the questions we are asking ourselves now:

• What customer group do we value the most?
• What features do they value the most?
• How expensive is it to build the ultimate product for each group?
• What is the minimum viable product we can build for each group?
• Which group is most likely to give feedback and partner with us to help refine our product?
• How much feedback is this group likely to give you?
• Are we missing some market window by passing on one group v.s. another?

This is a critical point in the product's design. Whichever user group we choose will be our customers. Or another way of saying it: They will be our ONLY customers. Other customer groups aren't likely to be interested because we aren't building any features for them yet.

When designing a product do you consider what customer groups you are including and excluding? Are you going to be happy with that choice for the foreseeable future?

Related posts:

1. Your SDLC or Your Product – You Decide
2. User Driven Product Development
3. “Build half a product, not a half-assed product” – tips on clarity and focus from Jason Fried of 37Signals

Instead of a "loading" animation that we may bail out on, why not tell a story? I was impressed with this technique used by BMW.  They are running banner ads on NBC's site which hypes the upcoming Olympic events. You see a car in the banner ad, you expect to click and see more car. But you don't. Instead, a blank white screen with just a few short words pops up. But the words tell a quick paced story. phrase by phrase, of what joy is. Joy is Timeless. Joy is Freedom. Joy is Innovation. And below those words is the "loading" indicator. 10%, 20%, 32%, and so on. A nice example of storytelling used in design - if you are going to make someone wait (or have to, because you are loading a high-end car video), consider getting them engaged with a story.

http://www.bmw.com/com/en/insights/technology/joy/bmw_joy.html

Related posts:

1. Ajax and Design
2. Art vs. Design, the Art of Design, or the Design of Art
3. Design Doesn’t Just Mean Color

1. The daily commute. It's a simple matter of ergonomics here. I will use the iPad, sold with a cheap data plan when I'm sitting down on the El, rather than the iphone. Because it has a bigger screen, and it's already connected. I won't use my laptop, because it doesn't come with a data plan (or only an expensive one that I won't buy), and it's pretty uncomfortable to use in a cramped row of seats. I'll use it instead of a laptop because the form factor works much better, and because I will have bought the data plan bundled with the iPad.

2. The eBook reader. I'll use it instead of a Kindle because it will be good enough (or better), and I can do a lot more than read with it. My guess is there will be more people that read on the tablet than who buy a dedicated reader. (Just as there are more people who do photo sharing on facebook than on flickr.)

3. In the Kitchen. If I'm in a situation where a sealed, mess resistant device with a big screen is a big advantage (like a kitchen) then I will use the tablet. I will prefer it to the iPhone because it's bigger and I can look at it while I'm doing something else, and I will prefer it to a laptop because the keyboard will not get gunked up. There are already devices retailing around $300 to store and retrieve your recipes in the kitchen - an iPad with the right recipe app will run rings around that.

4. Video calls on the go. If it's always on, like an iphone, and it has video (like my skype video phone) with a front facing camera, then I will replace my skype video phone with it, and I'll make more video calls. This isn't in v1, but you can bet that it will be soon, and when it is, it'll be a killer app for the iPad.

5. In the store. Walking around, showing people more information, more details. The form factor is better than a laptop, and the screen is better than an iPhone. Which would you chose in that situation?

6. On a trade show floor. Very similar to the store situation.

7. Any other place where you would say "hey, let me show you this!" It's cumbersome with a laptop. You have to say - hey, come here, look at this...

8. In the restaurant. I could see it used in a restaurant, taking orders, or at the reservation desk.

9. For doctor making rounds. In multiple hospitals (as many do.) A doctor or nurse making their rounds is a similar situation - they'll use their iphone when nothing else is available, but they'll prefer the tablet when it's available, because of the larger viewing surface. They'll prefer it to a laptop most of the time because of the true portability.

10. Online games. There's a reason games have been a big hit on the iPhone - like the wii, it's a different gaming platform than a gameboy, and unlike a laptop, it's truly portable. Add a bigger screen and a faster processor, and you've got a killer gaming platform.

11. Social games. A special case of #10: Playing chess or another game on a table with a friend or friends (or against the computer.) One of the issues with sharing a laptop for gaming is that you can't really do face to face. You're both looking at the screen, not at each other. A tablet can be laid down between you and used as a gaming console.

12. Online courses and test preparation. You're doing a lot of reading, and watching a lot of video, and probably answering mostly simple multiple choice questions, rather than writing essays. You can do it on the go, or sitting down at a table. A tablet could be a much more enjoyable way of doing this than a desktop or laptop.

13. Watching movies. You don't watch movies sitting at a desk - you do it lounging, on a couch, in an armchair, or on the bed. If you're not watching it on a big screen, this is the way to do it. On the train, in the plane, in the back seat of the car, on the couch, on the family room floor.

14. On the job site. Contractors and architects do a lot of site inspections/checklists in the field where an ipad would be great – my guess there are a lot of other applications for them as well. Just as in a medical situation, concerns about durability can be addressed through functional cases.

15. Turn by turn navigation in the car. The bigger screen is a natural for this. A purpose built case with gps is probably not that far behind.

Got any other situations that the iPad is suited for? We'd love to hear about them.

Related posts:

1. iPad: Instant Reaction to Apple’s Tablet Event
2. iPad: How big is the space between laptops and iPhones?
3. Why would you use a tablet instead of a laptop? (In Pictures)

It's no accident that Steve Jobs is arguably the ultimate technology pitch-man. He's worked with some of the best designers, ad agencies and creative people on the planet even since the early days of Apple. But how would he pitch your idea? It's a fun question to ask and I found a book that just might have the answer. While browsing in a discount brick-and-mortar bookstore I came across "The Presentation Secrets of Steve Jobs" by Carmine Gallo of Businessweek.com.  There was one copy on the shelf and it immediately caught my attention. As I flipped through the pages, I was impressed with the many "how-to" pieces of wisdom. For example, you'll see how answering four simple questions can yield a powerful elevator speech. You'll see how to use high impact words, tight headlines and key numbers to get your point across in a way that seems effortless. While I think the book is a "must have on your desk" for product managers and marketers, I also think it's a great reference for designers to think about what makes a design more marketable and enticing to the customer.

Related posts:

1. Salaries Go Up for Ajax Jobs
2. Scenarios in Product and Project Management
3. Reconciling the Powers of Less and More in Product Design

photo credit: Hugo90

This morning I sat through two pitches by two startups looking for funding. I won't get into the details, but they both had clever ideas at their root. But while one company was attractive and poised for success, the other was mediocre and not getting much traction. Why was that? They both had clever ideas, no?

Over the years I've looked at a lot of business plans for Venture Funds. The first lesson that I learned was that cool ideas didn't equal successful companies. While I would get all hot and bothered by a particularly elegant software solution, the VC's I was consulting to preferred the plans that understood the market and the customers in it (and had a kick ass management team, natch).

The "good" company from this morning had a clever idea that was a clear solution to a customer problem. The mediocre company had a clever idea that didn't really solve a specific customer problem.  What accounted for this difference? Well, the "good" company spun out of a larger business, while the mediocre came out of a government funded not-for-profit.

The easy conclusion here is that business folks have the discipline of competition working for them, while NFP's don't. It's true that I've seen companies that have no valid competitors flounder when it comes to a business plan, but that's a disease that's not restricted the the NFP realm.

No, instead this seemed to be a different ivory tower problem: lack of a customer. As a result their product definition was crap. Who would want this thing? Always start with the customer.

If your startup idea includes a software component, you should make sure that your software development practice also keeps the customer front and center. It may be tempting to start with architecture, to see if your software solution can "scale." But if you get the customer wrong, you won't need to scale.

That why with most software products that we develop, we start with user modeling. We do move on, eventually, to data modeling, process modeling, etc., etc., etc., but only after we've set the tone, so to speak, with user modeling -- personas, user stories, task flows, etc. Everything that follows is then motivated by the customer.

So, before you spend a million dollars on that cool idea, validate it with some customers to see if they actually want it.

Related posts:

1. Upcoming Talk at RIApalooza: Fast. Smart. Agile. User Experience Driven Agile Development
2. Web 2.0 Expo: Behavior-Driven Development with Rails and RSpec
3. Gmail, agile development and user experience design

Now ask yourself, in which of those pictures would (a sealed, always on, always connected) tablet make more sense?

In all of them (although the beach one still seems like a bad idea.)

Related posts:

1. iPad: How big is the space between laptops and iPhones?
2. Where the iPad will take over: 15 examples
3. iPad: Instant Reaction to Apple’s Tablet Event

... it's hard not to think about how much easier some people's lives would be (hi Mom and Dad) if they could trade technical complexities they don't care about for vastly increased simplicity and ease of use.

- John Siracusa, ars technica

My parents were technically savvy enough (with a little help from their sons) to start using Skype video in their mid seventies, prompted by the arrival of grandkids halfway across the country. But for them, it was always a cumbersome affair:

1. Arrange a time to have the video call.
2. Move the laptop to the dining room.
3. Call on the telephone to tell me that they're using Skype on the computer.
4. Initiate the Skype phone call.

Needless to say, this did not happen all that often.

This past Christmas my brother got them a Skype Video Phone. They set it up with a little help from us, and when we told them to just treat it like the telephone, they got the idea. Now, they are making video calls much more frequently - not just to the grandkids, but to our cousins in Switzerland and South Africa.

They traded complexity for simplicity and ease of use, and though the skype video phone will not end up being a success on the level of the iPhone, it's already brought my parents a lot of joy, and is part of a trend towards more simplicity and ease of use. It's one major reason the iPhone is as successful as it is.

Now imagine that simplicity and ease of use in a multipurpose, always on device with a bigger screen. My parents wouldn't need the skype video phone, they'd just have that as an app on their tablet.

Related posts:

1. Single Purpose Devices vs. Flexible Platforms and Functional Cases
2. iPad: Instant Reaction to Apple’s Tablet Event
3. Where the iPad will take over: 15 examples

photo credit: matsuyuki

I've made my fair share of predictions, and this may seem to be a layup, but I think it's a prediction worth making anyway: mobile devices and applications will transform business and every day life in the next decade.

Why does this seem like such a layup? Well, look at the iPhone and the ecosystem of applications and companies springing up around it. Android and Blackberry are trying to jump in on the business and everybody and their brother is cooking up a connected mobile device. And yes, that's obvious. Mobile devices are going to increase in importance in 2010 and if you don't already have an iPhone app cooking to complement your other online channels, you're behind the times.

But if you're just thinking that more iPhone applications are going to be the end of it, you're in for a rude awakening. Businesses have just started consolidating after the disruptive years of the 90's and aught's, with the transformative effects of the web largely digested by the marketplace (the newspaper industry is still thrashing but will soon succumb). A new disruptive decade is dawning that may see the passing or fundamental transformation of industries as varied as telecom, credit card and broadcast television/cable. Prepare to take your business through a roller coaster ride every bit as challenging as the web revolution.

What Will Change First? Telecom.

The introduction of the wifi chips into the iPhone broke the charge-by-minute mold. More and more carriers are moving to a flat rate and hybrid connection types will be standard on all mobile devices within a few years. Bandwidth will be purchased in bulk as it is between Amazon and carriers, leaving the consumer (in this case Kindle users) out of the transaction. Connectivity will be sold by the device vendors, not the telecoms, as a part of their offering. The customer relationship will be with the device vendor (much as you relationship with the iPhone is through Apple, not AT&T).

What will change next, or as a result of this enabling transformation? Lots of things:

1. Larger screens, always on solid-state mobile devices with long battery life, and higher bandwidth means that content distribution is moving away from the airwaves and cable and coming to a handheld device near you. What iTunes did to Tower Record will happen towards the end of the next decade to cable and broadcast. Like my friend who gets most of his content through Netflix and Hulu, they'll be saying "I have a TV, but I never turn it on."
2. Somewhere in the next few years, someone will invent a reliable and secure way to make payments through mobile devices. It will get broad adoption, and after a few hiccups and scares (Remember "Is it really safe to give my credit card information via SSL?"), they'll be acquired by Paypal and we'll be paying for all of our Xmas presents, in stores, with our iPhone Ultras. The banks and credit card companies will fight this, but before too long you'll be getting lines of credit and debit mechanism through your mobile devices. Time to cut up those credit cards, because they'll be useless.
3. Secure mobile devices will enter into every corner of the workplace and cause another productivity boom among those workers who are not tied to the cubicle. Since they use mobile devices in all other aspects of their lives, these will not be expensive new devices with steep learning curves. They will be based on widely existing technology (maybe Android?) and their use as natural to the workers as breathing or browsing Facebook.
4. Flexible, foldable displays will make an entrance late in the decade to make the size of mobile devices irrelevant.

These four fundamental shifts along with the change in the telecom will drive a whole new set of businesses, both products and services. New artforms will spring up, new ways of presenting information, new ways of social and political interaction.

As a Business, Take Nothing for Granted

Those sound like plenty of transformative changes to keep most businesses, large and small, either plotting to take advantage of them or worrying about their future. If you're the sort to embrace change, then there are a few steps you can take to prepare.

1. As a business, don't assume you know what your customers want. Your customers may have selected your product, for example, because it was a safe choice, not because it had the best features. Your competitors (or new, mobile entrant into the market) may have better, more informed customers and may be getting better feedback and developing a better product that will crush you in a few years time. The risk of this happening is greatly elevated when a new technology is destabilizing existing business models.
2. Do user research. The ways in which people are consuming products and services is expanding. Making naive assumptions about your customers will leave you delivering new software that behaves just like your old software, a sure recipe for obsolescence.
3. Invest in User Experience Design (UXD). UXD can help you with context. Why is context important? Because your customers aren't going to be just sitting in a cubicle or at home. They're going to be in stores, shopping, or out on the road, deciding where to stop to eat, or on the sidewalk, trying to find a cool coffee shop. Their context is going to be different as are their goals. The most successful businesses are going to deploy software that understand the importance of context and optimizes how they can achieve their goals in the environment (context) they are in.

Yes, definitely, the bar has been raised to be successful in business. If you're already uncomfortable with your web channels, then this is another headache you're going to have to handle. But if you think of it in the same way that you think of your web presence, you'll miss the boat.

Related posts:

1. 6 Tips for Designing Mobile Interfaces
2. Apple’s Earnings Call: Enterprise iPhone Adoption Growth
3. Single Purpose Devices vs. Flexible Platforms and Functional Cases

photo credit: tallkev

Last weekend I was watching a movie with my kids. In the movie there was a chain of monkeys that needed to pass on the message from one character to one on the other side of the chain. The message went something like, “Don’t throw us over the wall. There must be another way. We will all be killed.” As it went through the chain and the receiver heard, “Throw us over the wall. It’s the only way. Banana.” The scenario seems ridiculous, but its roughly equivalent to how many companies approach software product design. Often times companies don’t realize they are creating a product at all. They think they are just running a project and focus only on delivery of that project as if it is the only artifact of their work.

The problem stems from the fact that when organizations reach a sufficiently large size they must focus on consistency of delivery and efficiently using people’s time. For large organizations this is part of the mix that makes up their competitive advantage. However, the sheer size and number of moving parts required to enable clocklike consistent delivery leads to the most knowledgeable people about the customer never directly speak to the people responsible for building the product. Or translated into a traditional SDLC, the definition/high level design team isn’t communicating with the build team. In my experience they are usually two different groups of people. I’ll give you an example:

A while back, I was leading a software development team creating a product to be used by all 170,000 of my customer’s employees on a daily basis. They happened to have a team of user experience designers and wanted to take on the “big picture” part of the design themselves. This company could afford the best and the brightest talent - and was able to attract them. Individually the folks on this team were talented and knew their craft well. I actually learned a lot just from my brief time with them. However, once we got the design in hand it was obvious that the usability team’s artifacts weren’t going to work for the project. They didn’t meet the end user’s needs nor were they implementable within the time we had available for the project. The client’s design team literately spent months of time showing users lo-fi prototypes, running focus groups, and understanding usage statistics from similar applications. But, the simplicity the end users craved didn’t match the complexity of the business rules required. Upon further investigation the customer’s design team never was given a business level view of the problem to be solved. We tried to merge the business requirements with good usability, but ultimately the franken-design didn’t work. We had to throw out the big picture design and use them as ”guidelines” instead. Clearly it was a waste of talent and a haphazard way to build a product.

In hindsight the design team should have been presented the complex business rules so that their design could incorporate them from the beginning. However, the customer’s SDLC only allowed the design team to be engaged in the definition/high design phase of the project. Once we got to the design phase they were hard to find. By the time we got into the build phase the development team was simply a distraction from other work for these designers. A better model would have kept the designers on the project as each piece is built. I’m not suggesting full dedication to the team – 40 hours a week. That would be nice, but that’s not likely possible in most organizations. I’m suggesting a small time commitment over a long period of time.

Most of the time projects are actually building products. If you are building a product, but focusing SDLC metrics and efficiency, keep in mind that your phases are likely making walls around teams and causing ineffective communication between them. As Matt from 37Signals points out, “Inefficiencies are what make you special.”

Related posts:

1. Who values your product and do you value them?
2. Design Doesn’t Just Mean Color
3. Tech Terms that Drive Business People Crazy

A couple of days ago I happened upon an interesting article about the difference between art and design. The author makes a lot of interesting points, and whether you agree or not with the statements he makes, the article does make for a great conversation starter.

Art and design are two different words, and some say two different worlds as well. The use of each often comes with a distinct connotation. I could go on about how design's goal is to solve a problem, whereas art doesn't necessarily always have a problem to solve. I could talk about how art doesn't necessarily require a common user experience, whereas design more often than not does. I could expand upon that by discussing how art doesn't require that a thing be usable, whereas design is often judged in part or whole by its level of usability. I could even discuss how art can be effective whether done collaboratively or not, and contrast that with numerous examples of how here in our agile software development environment at Pathfinder we find collaboration inseparable from our design process.

But I could also talk about how much art and design overlap and blend, so much so that it becomes difficult to make concrete distinctions. And how, sure, software design is about solving a problem, but it's also about solving a problem beautifully.

Art versus design, the art of design, or the design of art...it's a never-ending debate, and the usefulness of this debate is also debatable.

The art versus design topic definitely can be a fun one to banter about. The author of the article had some very interesting points, especially regarding the purpose of design being to communicate a message and motivate the user to act. He makes an important point that, "If your design communicates a message other than the one you intended, and your viewer goes and does something based on that other message, then it has not met its requirement. With a good piece of design, the designer’s exact message is understood by the viewer." And it was nice to see too that he included his designs for the article as downloadable wallpapers.

But in the end, I think the author of this blog post said it well when he said it's not really our goals that are in conflict when we talk about art and design - just our definitions. So perhaps rather than elaborating on terminology, we should focus more on clearly expressing our goals.

Related posts:

1. Integrating Design and Agile Development
2. Week in Review
3. Developing Good Wireframes Ahead of Visual Design

I've worked on more than a few software projects over the decades and one of my favorite little misunderstandings is the Importance versus Effort disconnect. That's where non-experts assume that because a particular part of a software system is more important than another, it must also take more effort to develop. That is rarely the case and, in fact, importance -- however that is defined -- is rarely a driving factor in determining effort or cost. This sort of misconception can result in some planning and budgeting mistakes, sometimes to comic or even tragic effect.

To illustrate, I can point to a trading system that I worked on (the names have been changed to protect the innocent). The average size of a transaction in this system was over $1 billion in 1990's money. The part of the system that resolved the transactions was really really "important," but the part of the system that allowed an application helpdesk to support users by seeing what their user's saw cost 60% more to develop. That's right, an "unimportant" helpdesk module was more expensive and took more effort and cost more than the "important" backend that handled billions of dollars a day.

There are lots of reasons why one system can be more expensive to develop than another. One recurring and important reason is the amount of user interface your application has. By that I mean a user interface for a real flesh and blood user. One of the reasons that the above trading platform had this mismatch was that while the helpdesk app had lots of user interface requirements, the trading backend had almost none. It dealt almost exclusively with other systems through API's and data interchange protocols.

There's lots of empirical evidence that interfaces for humans are more difficult and expensive to develop that those for machines, but there's also a fair amount of theory on the subject under the heading of Human Computer Interaction (HCI). If you spend a little bit of time reading the referenced Wikipedia article, you'll see that there's an awful lot of cognitive psychology involved. In short, you can't just ask a human being to do those things that a software system can do -- parse 2GB of data, remember it forever and make decisions within a millisecond. No, human beings have limited memory, can't act very fast, have ambitions and emotions and all sorts of human frailties. All of these have to be accounted and designed for.

(We ourselves use an approach known as User Experience Design (UXD) to tackled this terrain. It's by no means the only approach, but it's stood us in good stead.)

So, what are the key takeaways for product managers and owners? Don't make emotional budgeting decisions. Just because your backend which is doing all of the financial transactions is important, doesn't mean that it should cost more than the nifty website that helps users buy your product or service. Listen to your developers and analysts on the subject of effort and cost, then make rational decisions based on what is essential for your business.

Related posts:

1. Software Development and the Construction Analogy
2. Software Development and Wasted Motion
3. Digging a Hole and Covering it with Leaves — The Software Development Version

photo credit: Sinaasappeljuice

At Pathfinder, we do our best to help our clients experience the software through the eyes of the user. Defining a feature includes explaining who will be using it, what they need to accomplish, why they need to accomplish it and how they’ll actually do it.

We start with personas (who) — they define the user base and let us identify the primary users whose needs we should focus on, which in turn drives the feature list. Personas also bring the human element into software development. Rather than using a vague term such as actor or user, terms that can easily be dismissed, we now have Myrna from Accounting, a numbers guru who is the primary user of the new software. Myrna is not so easily dismissed, especially once her needs and goals are identified.

We move onto user stories, all of which are written from the point of view of the personas:

As Accounting, Myrna needs to quickly extract time expended per project so she can calculate the actual costs.

Our user stories state both the user’s need (what) and business benefit (why) from meeting that need. The story is no longer some randomly floating idea; it’s now anchored to an identified user and given context within the scope of the business by specifically stating how the user and/or company can benefit from this feature.

From here we move onto acceptance criteria (how), i.e., defining how the user expects the feature to work. Since they’re written from the point of view of the user, they’re easy to understand and aid in experiencing the feature before it’s built:

Given that Myrna has clicked on Reports > Costing Report
   And that the costing report page has successfully displayed
When Myrna selects one or more projects
   And she specifies a date range
   And submits the request
Then the costing report will show the hours by project for each resource for the specified date range

Even without delving into the details (e.g., how does the user select one or more projects), you still have a pretty good idea of how someone will interact with this feature; i.e., you’ve established a foundation that interaction designers and information architects can now build on. Acceptance criteria, btw, are also great at uncovering any user story you might have missed, such as: does Myrna need to save this report after it’s generated?

Designing software with a user centric point of view begins with defining the Who (Personas), What (User Stories : User Needs), Why (User Stories : Business Benefits) and How (Acceptance Criteria) of feature stories. With this knowledge, we can then create a well-designed feature that we’re confident will meet the users’ needs.

Related posts:

1. It Starts with the User Story
2. Definition of a Feature (Given … When … Then)
3. The User Interface is the Root of All Evil

The task of wireframing in application development, as I've come to know it, should begin after user research has been performed, and a complete set of requirements gathered.  But what happens when, for whatever reason, you just don't have access to user research, or a full set of requirements?  What if all you have are some rather unspecific, vague notions of what the user should and should not be able to do?  Is wireframing at this juncture useful?  I say yes.  With incomplete or even almost non existent information about target users and or requirements, wireframes can still be a valuable tool in the interface designers toolkit.

The key to a wireframe's usefulness is that it is a visual document.  Presumably it will be presented to one or more product stakeholders, and they will have the opportunity to review it and comment.  Having something visual to respond to is one of the easiest ways to generate ideas, and identify incomplete specifications.  A good assumption is that if a product's requirements are incomplete, someone at the wireframe review will notice the gap by responding in the context of the visual presentation.  "Where is the Cancel button?  Oh...not in the requirements?  Well it's obvious that on this screen the user will need to be able to cancel, so we have to add that as a requirement."

In this way, a wireframe can be an ever evolving document, which begins by starting the requirements conversation.  Of course ultimately, just prior to feature development, the wireframe should have all of the necessary specifics so that the developers can use it as a guide (along with the relevant user stories).

Related posts:

1. Exactly What are Wireframes?
2. Writing Agile Requirements
3. Developing Good Wireframes Ahead of Visual Design

Ack! On the one hand, good for them for alerting me that an error had occurred. On the other hand, what's up with that message? I had no idea what I could do beyond clicking ok (and after reading the message I wasn't sure all was ok). A bit unnerving, but it did get me thinking about how applications deal with error messages.

The idea that non-technical users will be viewing error messages is one of those things that tends to be overlooked. You’re so focused on getting all the features up and working that dealing with errors on the presentation layer are often left out of both design and implementation.

Even if time is crunched on a project, however, here are three scenarios you should always cover in a user-friendly fashion:

Validation Errors

At a minimum, submitted forms should validate that all required fields have data and that certain data (such as email addresses) are properly formatted. My personal preference is to catch the obvious errors (e.g., empty fields) using client-side validation which gives the user instant feedback and allows them to correct their errors before actually submitting the form. Regardless of whether you’re using client or server side validation, however, you should still alert the user as to what went wrong — without using technical lingo — and highlight the fields containing the errors.

404 Errors

Design a useful “page not found” page. Make it as clever or funny as you like, but make sure you give the user alternative ways to find the page they were looking for so they don’t feel so helpless. This can be done by providing a site map, a search box or a list of top-level categories.

500 Errors

When a page blows up, unless you’re in a development environment you never want the user to see the stack trace. So, make sure that (a) there is a page in place to display when a 500 error occurs, (b) the app knows to display that page and (c) it gives useful feedback to the user.

In an ideal world, of course, errors never occur (ha!) but should they happen, your job is to let the user know what went wrong and provide guidance on the next steps. Time spent up front designing good error handling will alleviate user frustration down the line.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Oops! Our Bad.
2. Usability review: Amtrak.com checkout process
3. Stop, Reload, Error Loading Page 404: Converting Web 1.0 to 2.0

To make a cheap joke and paraphrase a common quote, web developers and web designers are two groups separated by common languages. In our case, the languages are HTML and CSS, which are the output of both the web design process and the web development process. Developers and designers produce their HTML/CSS in different ways and with different goals. Here are some ideas for bridging the gap so that the developers and designers on your team can work together smoothly.

Designers and developers obviously have different goals for their HTML -- developers have issues of reducing duplication, organization, and performance that are largely not the designer's concerns. The designer is primarily concerned with how the HTML looks and behaves to the user.

By the way, I'm absolutely not trying to make this some kind of left brain/right brain thing. It's more of a software needs vs. domain expertise thing. Once upon a time, I was writing scripts that outputted router configuration files, and I had exactly the same issues with the router domain experts -- my software engineering desire to structure the code without duplication conflicted with the way the router experts liked to structure their hand-written configuration instructions.

Our teams have had success with getting everybody on the team using common tools as much as possible. This means putting designs and code in the same code repository, and it means the development team supports the designers in creating a set up to run the current development version of the app locally. (By the way, this article by Mindy Wagner might be helpful if you are trying to convert everybody to Git.)

From the developer perspective, if you are working with HTML provided by designers, it's important to keep the view layer of your code accessible to the HTML providers. Exactly what this means is subject to negotiation. Left to my own devices, I'd be putting all kinds of HTML generation in Ruby via helpers or something more esoteric. That didn't work out well when the designer needed to go mucking about in metaprogrammed Ruby code to start changing CSS classes. We do better with putting pure logical stuff in helpers and using partials to split view logic. I'm pretty sure that if I were to suggest Haml for a project, the designers would veto it -- Haml barely meshes with the way I think of HTML, the designers I've shown it to have basically recoiled in horror.

That said, everybody likes Less CSS, which seems to augment CSS in ways that seem very intuitive to CSS designers, and which are very satisfying to coders. It does all the things that you would expect CSS to do if it was a real language, but vanilla CSS works just fine. It really caught on quickly here.

From the designer perspective, get everything out of photoshop and into HTML/CSS as early as possible. It's just too easy to put stuff into a photoshop image that represents hours of development work, leaving the developers in the position of trying to determine which parts of the impossible image are vital, and which are just chrome. Doing the wireframes in HTML/CSS keeps the design honest.

We use this little hack to integrate wireframes into the development app, which is really nice for developers when working with in-progress designs.

Ultimately what it comes down to is for everybody in the team to take some responsibility for making the team work together. The developers need to make the code base accessible to designers and to be alert to basic design issues and flexible in adapting wireframes into the site. Designers need to help place their deliverables in a format that keeps the developer from having to guess how things are supposed to work -- nobody wants that.

Related Services: Ruby on Rails Development, User Experience Design, Ajax Rich Internet Applications

Related posts:

1. A New Workflow for Web Designers
2. Down with HTML + Code Markup!
3. Designers on Joel

Design encompasses both of these, and both are equally important. But by first addressing the software's information design & interaction needs, wireframes help you make sure the user experience makes sense, including that the workflows are natural and intuitive for users, and that the interactions are easy and clear. Without these, a site may not be very usable. Developing good skeletal wireframes before fleshing out the visual design is important for several reasons.

Focuses the Conversation
Visual designs tend to elicit more of an emotional response than wireframes. Hence, putting a fleshed out visual design in front of a client can divert attention from the structure and interaction of the page, and tilt the conversation more towards the color and graphic choices. Skeletal wireframes help you and your client focus the conversation on the business goals and the needs of the user.

Creates a Path toward Better Design
Wireframing and information design is really an evolutionary process. Design reviews, customer feedback, and user testing all help the information and interaction design evolve for the better as the project moves forward. Being open and flexible, without having invested deeply into a visual design, allows for the freedom to continuously create and recreate to meet the users' and clients' needs better. Good user experience comes from creating an environment and process that allows for more evolution in design.

Allows for Choices to be Driven by Users' Needs
A great deal of creativity, time and effort goes into mocking up a visual design, so it's natural to feel attached to it. The last thing you want is to feel locked into a certain user experience because you've invested in the visual design too much too early. Because your information design choices should be driven by users' needs and business goals first, it's important to develop good wireframes before investing heavily in visual design.

Saves Time
You don't always hit a great information design on the first try. When you work iteratively, your information design gets refactored and improved. Spending days creating visuals, only to find that you have to redo it because the underlying structure or interaction pattern needs to change, is frustrating and hurts your efficiency and overall progress.

Saves Money
In a world where time is money, having to redo work can cost you a lot. It is inevitable that your design will change. But redoing wireframes costs less in terms of time and money than redoing a visual design.

At the end of the day, if your software is usable and providing users with value, but has less than ideal visual design, people will still use it. However, if your software is confusing and hard to use, but has great visual design, people won't use it. So concentrating on the layout and interaction first will pay off in the end.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Exactly What are Wireframes?
2. The Hand-Off Between Information Architecture and Visual Design
3. Fresh paint or new drywall? The cost of changing IA or design mid-project

[...] this is completely at odds with how homes are normally built.  People typically choose a previously-implemented design, and only customize superficial features like countertops, cabinets, floors, and railings.  Houses from this plan have been built before, and the labor and materials cost are known from previous experience.

Building software is usually more like constructing something that’s never been built before: the first sky scraper, the Golden Gate Bridge, or the Hoover Dam.  The requirements are unique, the pieces have never been assembled in such a way before, and there’s an inherent level of risk in creating something new.  When this is the case, the Customer needs the services of an Architect, not just a Builder who stamps out deliverables in a cookie-cutter style.

I would add two points to his post:

• One additional reason that building construction is not a good metaphor for software construction is that it breaks down along scale. You can construct a scale model of a house to validate the concept, but a scale model of the software is the same as the software itself. An application's size is measured in features, not feet. That's why agile development seeks to deliver a minimal set of features as quickly as possible.
• We've folded User Experience Design (UXD) into our agile process as a way of getting to value more quickly. Feedback in agile is important, but if you can improve the quality of that feedback, you converge on good features more quickly.

Related Services: Custom Software Development, Agile Development

Related posts:

1. Software Development and Wasted Motion
2. Ten Keys to Successful Software Development: #9: Respect the Process
3. Agile Software Development and the Lazy Client Trap

Why use them?

Wireframes are a great communication tool for all members of a project team. Instead of an abstract list of requirements or a verbal description of a concept, the visual nature of a wireframe allows everyone to see exactly what it is they’re discussing. They are usually black and white (sometimes with shades of gray) schematics because we want to get feedback on the page structure and behavior, not the visual design. However, wireframes created for mature applications can readily incorporate existing visual design since that language is already defined and shouldn’t divert focus from the reason we’re looking at wireframes.

Annotated Wireframe

Although a picture is worth a thousand words, adding annotations to a wireframe lets the viewer immediately know the expected user behavior of various elements on the page. While a more detailed explanation of the behavior is generally contained in the design specs, adding a shorter version here is extremely helpful.

Here's an example of what an annotated wireframe can look like:

Who uses them?

All team members. Because they are a visual artifact of what is proposed to be built, they are an easy and cost-effective way to get the stakeholders to sign-off on how their business requirements will be translated to software, before any code is written. They also give development a heads up on what the page will look like and how it’s expected to behave; which means they also let QA know what to expect once the feature is ready for testing.

While I sometimes have to educate clients new to software development on the benefits of wireframes, once they see them within the context of a project, they're sold on the benefits and understand their usefulness.

Related Services: User Experience Design, Custom Software Development

Related posts:

1. Wireframes: Much More Effective than Interpretive Dance
2. Developing Good Wireframes Ahead of Visual Design
3. Wireframes in Omnigraffle 5

The benefits of Facebook connect Facebook is obvious. It'll gather more information about its users, and become more ubiquitous within the wider web, as users remain connected to its platform even while not actually on the facebook.com.

And the (potential) advantage of the relationship to third party sites, such as Yahoo are that those sites can become more engaged with their users by providing them with more relevant content as a result of having access to their facebook information. It'll also potentially be used as a tool for enhanced direct marketing, although Facebook will have to be careful to to repeat it's Beacon mistake.

The potential benefits to users of third party sites are that they'll be able to tap into their network (or social graph, as Facebook calls it) as a source of information on those third party sites, and not just facebook.com. As a hypothetical example, if I'm looking for a movie to add to my Netflix queue, and I, and my friends were sharing our facebook information with Netflix, then the site could theoretically inform me of my friends picks--provided they granted Netflix access to share that information--and that would be more helpful to me than anonymous recommendations.

I like the idea, in theory, and it's seems like an exciting new direction in the evolution of the way we use the web, if implemented properly. However there are some privacy concerns I have. In order to allow Yahoo to access my Facebook account, I had to give it the Ok on a couple of different requests relating to access to my information. The initial confirmation dialog:
Connect Yahoo! with Facebook to interact with your friends on this site and to share on Facebook through your Wall and friends' News Feeds. This site will also be able to automatically post recent activity back to Facebook.

Related Services: User Experience Design, <Facebook and Open Social Applications

Another dialog asked me to confirm this:
Allow Yahoo! to publish posts or comments without prompting me.
Posts will appear on your Wall, in your friends' News Feeds and in applications like Photos, Videos and Notes.

Now what exactly is Yahoo going to be posting on my Facebook wall? I don't want all my activity, once I am logged into the Yahoo network, to be potential fodder for conversation among my friends. This to me seems a little scary. Yet I went ahead and gave it access. I do know that it's possible to edit my privacy settings as it related to individual third party applications, including Yahoo. But I'm curious what kinds of Facebook wall posts Yahoo will make on my behalf so I haven't changed the settings.

Related posts:

1. Facebook apps: Not too late to compete on the user experience front
2. Mashups versus Facebook
3. 20 useful Facebook/FBJS developer resources

Related Services: User Experience Design, Flex, Flash and Air, Custom Software Development

Related posts:

1. Data visualization and the art of conveying information
2. 3D Data Visualization in Adobe Air
3. Flex Widget for Graphing Elections and Debt