Wufoo is a very effective and easy to use form building tool that allows normal people (i.e. marketing managers and other non-techies) to build web forms quickly and easily without knowing programming. The form entries are collected in a database, and can be exported out to Microsoft Excel.

Or, isn’t Excel the marketing manager’s best friend?

You can have your designers make design changes with a CSS editing area, but the forms are designed to be very usable (I was impressed), and for short term form management, this is a great tool. For a longer term project, it’s better to go with custom programming.

 Comments | Comment

I just recently appeared on a panel talking about Agile development and User Experience, the benefits and the pitfalls. It was fun to have a discussion with people of other thought processes about agile and waterfall, but I’m a huge proponent of doing development and User Experience this way.

My first experience with Agile was April 2001, and I’ve run several projects with it since. That original project was as Product Manager for Escrow.com, and we ran iterations for almost a solid year (close to 20 iterations or sprints).

The result? A profitable company with a profitable product.

Three of the projects I worked on went by the wayside. There’s no accounting for issues with company culture. However, five others, including Escrow.com, launched successfully and have had varying degrees of business success. Agile doesn’t guarantee a breakthrough product, the hope is that it removes development process as a risk.

This first thing I’m going to do is define Agile development so we’re all on the same page.

Agile methodologies, or cultures, generally have the following:

• Short development cycles of two to four weeks and are usually called iterations or sprints depending if you’re using Scrum or Extreme Programming.
• Almost daily communication through short meetings, called standup meetings. They report what you are working on yesterday, today and tomorrow so any issues can be discovered early. The purpose of the meetings is to encourage further communication offline. Therefore, meetings are short. If you’re going over 15 minutes, it’s too long.
• Development progress that is measured through what’s called burndown and the product backlog.
• Clients, or product owners, that are intimately aware of progress and prioritize based on product needs. Everyone has a voice in what the product is.
• A process that is adapted to the team. They own the process so they get to use elements that work for them.
• This is key: people who are upfront about their responsibilities and don’t hide their roadblocks.

It’s also key to note that I used the word “generally,” because the process is defined by the teams that use it. So, some may only use elements of Agile and Scrum.

I’ve seen Agile work well for products that require constant improvements, but it’s hard to adapt it to a new development unless you have some time to adjust the process while people are learning. Short projects of less than a month make it hard to do a scrum-like process. I can’t imagine using Agile for a hardware-based product.

But for the web, where everything is changing, it’s great.

Here’s how to convince most User Experience teams that Agile can work:

You get direct access to the developers

One of the major complaints I have about most waterfall environments is that once you write the functional requirements and wireframes, you’re pretty much done. Developers push back, you miss 25 to 30 percent of the requirements because you just didn’t know or no one read your requirements, and there’s always the, “Well, that’s not what I meant” misunderstandings because there was a different interpretation of the wireframes.

I’ve run a Scrum-like process over the phone (I’m doing so for a current project), and the main purpose of the methodologies is to encourage more communication; with daily meetings and constant touching, you usually can walk over to the developer and ask to see the work.

If there’s an issue of the design not working the way you want it to, you can negotiate with the developer to build it in a way that achieves everyone’s goals.

While you don’t get to do as much research, what you do get is to see your work in action sooner

Waiting three months until you see your work turned into real software or website development? This is the process for you. The rub is that most of the time, you’ll get to do two weeks to a month of research at the very most before developing wireframes, or user stories, and that’s okay. Unless you’re inventing the new iPhone, why would you want to do that?

Usually you develop a lot of areas with stubs (i.e. “We’ll do that later, but just put a page there.”) and concentrate on the big functionality. Your initial stab at what to build is called sprint or iteration zero, and in most environments you’ll stay one iteration ahead of the developers. This gives you a little time to move and adapt; and, in some ways, it doesn’t allow you to over think a feature.

From Agile Product Design:

User experience people working on Agile teams become masters of development time travel, nimbly moving back and forth through past, present and future development work.

You’ll see your work as they build it, and you’ll also spot issues in days instead of weeks.

Agile doesn’t mean no requirements. It means requirements that work for the team.

Since the team decides how to build the process, that means the requirements can take whatever form the team wants them to take. If you can’t do wireframes or HTML mock-ups that fast (I can), then this process will be a tough learning curve. However, one of the panelists had a great idea: go to another website that has approximate functionality and copy it, beacause how many times do we need to redesign a lost password process?

I’m a big proponent of the whiteboard or throwing the wireframes up on the wall in printed format; talking through a feature instead of looking at it in a PDF is a much more effective way of communication.

To mitigate direction issues, what I did was develop a really high level style guide to make sure we had a holistic view of the system, then did not annotate wireframes. The developers knew just the form or text elements; and if they had a question about functionality, either they asked about it in the stand up meeting or contacted me separately. Occasionally, I was diving into the code myself to write error messaging, which was okay.

Sometimes, it’s not what you communicate but what you don’t have to communicate that makes all the difference in the world.

If there was particular communication that we felt wasn’t needed, we would cut it out of the process. Who   reads all the requirements, anyway? Usually just the User Experience folks do, while arguing with the developers. That’s an important distinction. If management is forcing something down on the team, Agile isn’t going to work. It’s not about the tools; it’s about the people using them.

If your initial pass doesn’t work, it’s not stuck in the final product.

While there’s not a lot of time for formal testing, there’s plenty of time for guerrilla usability testing. That means you have to bring in or find some test subjects to throw against your ideas. This does not mean you should write formal reports, (there’s not enough time for that) but it does mean you should do enough testing to make sure your product is going in the right direction. You won’t spot every issue, like rocks and sand: you’ll catch the rocks and have to worry about the sand later.

It allows you to fail quicker. If there’s something you spot that’s really, really off-base, you can propose to fix it in the next iteration.

The other members of the team may agree. I’ve pulled features in previous environments without serious implications, and all we lost was a week’s worth of work or less.

Smart Agile teams also pair user experience designers with quality assurance analysts to write test plans for test-driven development. Developers would recieve test cases even before they started development so they knew what they were aiming it. This is great, because QA is one of the best groups of people to do usability testing on. They spot potential issues even before the developers do.

On a few projects that I’ve been on, we saw a 50 percent drop in defects reported and had fewer reworked features.

That’s huge.

You can see progress almost immediately.

One of the biggest frustrations of working in software development is waiting for something to be built. Agile takes away some of that frustration because instead of developers waiting until the last three weeks of a three month project to show results, developers can agree upon delivered features after the first iteration.

This creates a sort of washing machine effect to gathering requirements   and software development. You keep moving toward a common goal of building the final product. Instead of seeing huge leaps of functionality with possible huge leaps in missing the target, tasks are built in bite-sized chunks so you have a better idea of meeting your goal. You also get an idea of whether or not your estimates for building the product are on base, and what you have to adjust before.

It’s about making it to the finish line, one inch at a time.

The 80-hour workweeks are gone… sort of.

One of the rules we had at Escrow.com is that no one worked over 45 hours a week; and if they did, I kicked them out of the office. Two similar projects that I worked on had the same approach.

This was very important from a few standpoints:

• Developers and User Experience designers without a life are angry people.
• Tired developers are ineffective.
• Estimates only are effective if there’s a decent control mechanism.

The main benefit was getting a true gauge of process. How many have been on projects where the developers worked slowly until the last month, then crammed a bunch of hours in to the get to the finish line? How good was that product, really?

Doing estimates well is essential to Scrum and Agile, because then you can accurately decide what’s important and what’s not.

At BidRx, only after we attached Scrum did we get an accurate assessment of what was possible from a User Experience and Development standpoint in a sprint.

That means that developers and user experience designers have to have a good idea of what they can produce within the framework of a normal workweek. Being wrong the first couple of sprints is fine, as long as you can get closer each time. Remember, it’s about attaching iterations to the process as well as the product.

Your voice is heard, period.

One of the greatest things about Agile development is that everyone has a voice. That means that if there’s something you don’t like in the process or the application you are building, you can express your opinion instead of being on the other side of the wall from the developers.

There’s always a user advocate in the process of building the product.

The conculsion

Agile isn’t for everyone; however, when it does work, it works well. It does require a different mindset, and there are flaws to overcome.

Random Thoughts mentions the following downfalls:

• Loss of the holistic view of the system
• No time to prototype everything before development starts
• Lack of extensive requirements
• More development teams working simultaneously, same UX resources
• Fast delivery means less time for testing and iteration
• Loss of time for user research projects and general research and development
• A need to track UX worth and work before a project is completed

I only agree with the two that are in bold. That said, we have to try something different, because waterfall isn’t working.

Some other links:

• Scrum Club
  
• Agile UX

Blog posts:

• 10 key principles of Agile Software Development
• Twelve emerging best practices for adding UX work to Agile development
• Jacob Nielsen Speaks (Because he’s selling something)
• The missing piece: how interaction design can add to Agile

 Comments | Comment

Online Marketing Summit is one of my clients, and I’ve been working with them on doing some slight changes to redesign their site. The base design was very attractive and functional; we’re going through the process of making improvements to make the site more usable and effective. The Online Marketing Summit has a very strong core audience, but they need to reach out to new attendees in regional markets that could benefit from these networking and educational events.

How did we attempt to make it extremely clear?

It’s called Online Marketing Summit for a reason

Just the title alone is a great draw.

It’s a long company title (and even longer URL), but there’s no question the people that get to the site are potential attendees, which in other words guarantees targeted users. It’s not clever, it’s not cute, it just states exactly what the event is about: online marketing. The partnership with ClickZ adds extra credibility because they are a website that’s very popular with online marketing professionals.

Som websites use a motto or a headline that’s way too vague — most of the time, it’s just better to say exactly what the product or event is, and how it will benefit them.

The navigation at the top of the site clearly states this is an event. “Cities and Agendas”, “Register Now” and “Speakers” doesn’t make it seem like an e-commerce site, that’s for sure.

Use headlines that clearly state why an attendee would want to go

The headlines and each action item we used were:

• What: Join The OMS Regional Whistle Stop Tour
• Why: Learn from the Marketing Experts
• How: “Next Steps”
• When and where: Event cities and dates

Additionally, we emphasized particular words in the main call to action graphic (“best practices”, “expert online practitioners”, “share ideas”, “marketing peers in 13 cities”) that may attract attention. Sometimes content gets lost in the mix, so emphasis of certain words helps the user scan content. Don’t over do it though.

Call to actions are very clear and allow for active or passive participation

All of the call to actions were labeled with active words (“Register Now”, “Get Updates”, “Get Certified”, “Win A Free Entry”) that allowed the user either to be active about signing up (“Register Now”) or passive that they can sign up later (“Get Updates”,   “Win A Free Entry”).

According to some of the event companies, almost 75 percent of their entries for events come in the two weeks prior to the event, especially for regional conferences. Capturing the passive audience is very, very important; they will need to be reminded to be attend.

This target audience is a marketing group, so they don’t mind the site being junked up with a few extra call to actions as long as it’s effective and designed well. That’s important, knowing your audience.

 Comments | Comment

Apple Introduces Revolutionary New Laptop With No Keyboard

What I want to know is how much the Onion spends on these videos.

 Comments | Comment

Welcome a to podcast with Linda Coss, author and a web marketing content expert based out of Orange County, California. Her site is Plumtree Marketing. Today, we talk about the importance of great headlines.

Download the MP3.

[podcast]/_podcast/usabilitycounts.com-006.mp3[/podcast]

 Comments | Comment

"Word of mouth" is one of the most valuable forms of advertising. It's powerful, effective, and very inexpensive! Your satisfied customers can be your best spokespeople and biggest cheerleaders.

However, even happy customers can use reminders that they ought to “tell a friend." How can you encourage customers to do so? Here are some ideas:

• Create a formal "tell a friend" program whereby you reward your customers for spreading the word.
  Include a flier about your business and the products and services you offer with each purchase; encourage customers to pass this flier on to a friend.
• If you have a "bricks and mortar" office or store, place an attractive sign in a visible place encouraging clients to tell their friends about your business.
• If you send out regular emails to your customers, add a P.S. suggesting that they forward the email on to others who may be interested.
• Order a roll of pre-printed "We love referrals" or "I'm never too busy for your referrals" stickers, and place these on your letters, envelopes, brochures, invoices and other printed materials.
• Ask! A great time to bring up the subject is just after your customer has expressed their satisfaction with your product or service. "I'm so glad you're happy," you could say. "Do you know of anyone else that could benefit from our service? I would certainly appreciate the referral!"

A positive testimonial about your company – delivered directly from your satisfied customer to a potential customer – is one of the most powerful forms of advertising there is. It pays to encourage your customers to tell their friends about your business.

 Comments | Comment

Yeah, that’s about right. Stolen from Dilbert.

 Comments | Comment

This article is brutal, but I think all consultants have dealt with some of these scenarios.

I like the tips even better.

Here are some ways you too can avoid bad clients:

• Thoroughly research your prospective clients before working with them
• Discuss and outline all project details before accepting a client
• Be honest with yourself, and don't take on new clients out of desperation
• Follow your instincts, and don't take on clients that give you a bad feeling
• Watch out for catch-phrases, under or over communication, and other potential clues of a bad client

 Comments | Comment

You just can’t make this stuff up. I like the sales guy simulator.

 Comments | Comment

So…funny.

 Comments | Comment

Welcome to podcast number four with Kim Proctor, former Web Marketing Director for the Christian Science Monitor, and her site is Customers That Click. Today, we talk about the importance of the quality of retaining and communicating with customers.

Download the MP3.

[podcast]/_podcast/usabilitycounts.com-005.mp3[/podcast]

 Comments | Comment

I honestly believe there is no better time in recent history to do a startup than right now.

The tools are much easier to use to build websites, and there’s a lot of talent that’s on the market to help you do it. Of course, money will be an issue, but it’s even less of an issue than during boom times. I’m working with a few startups, and there’s a certain exhilaration of creating something   new.

This is something I forgot then remembered going through Startup Weekend LA, and it was interesting seeing the mix of people interact in a creative environment. All six teams got a project out the door, but each with varying levels of quality and efficiency.

There are a few caveats. I’ve been there many times before, and they aren’t all rosy dreams and promises. Startups depend heavily on having the right mix of talent; ideas of cheap, but execution usually isn’t, and it takes more high value people than truckloads of cash.

(Or, ask Microsoft about Sidewalk. Ouch.)

Some of this is written with a company in mind, but many startups now may be just one or two guys in a garage. Really, there is no better time. Read on.

There’s no such thing as first to market

Remember Excite? Web Crawler? Altavista? Shopping.com? Sidewalk?

They were first to market, but they didn’t have a product that was effective as Google. Google was very, very late in the search game. Facebook was late in the Social Media game. Who’s standing now?

Building and growing businesses is also about creative destruction. Products die and rise again. If you have a compelling story and feature set, people will flock to your site like bees on honey. It means you are serving a market that’s under served, and that you’re first to the market with something.

One person that has an idea can be a startup

All you need for a startup is the people with skills that can get it out the door. That means you need can do people that have the right attitude about being hands-on and getting things done, because at the beginning, there isn’t going to be enough money to hire a branding company, or even less to hire writers for the website.

You don’t even need a company structure: you can get it going just enough to start generating revenue, show it off to venture capitalists, and voila, you’re the next Jason Calcanis!

For example, to get a project out the door, the customers (or even better venture capitalists) aren’t going to be looking under the hood of the programming, or much less caring about the perfect user experience; what they will be looking for is a product they can use. Having the right mix of people (for example, a designer, developer, sales person and product person, with a 25 percent emphasis on each) is a great place to start. But it can be just you and a friend — or just you.

How do I know? A new client I just met with. Two people. Internet business, profitable, five years running. And now they’re looking to improve the user interface to increase revenues more.

Don’t hire your friends, it’s bad for business

As the company grows, so does the team. Founders go by the wayside (read: you’ve just been promoted to Director of Special Projects after working 80 hours a week?). Sometimes, the person that really helped out in the beginning can’t help out   later because they don’t have the particular skill set to adequately drive the product or help the company.

Sometimes, founders shouldn’t run the company after the company reaches about 100 people. This is happening with one company right now that I know of, where one of the founders is actually hurting the company.

The end goal in any startup is to get to the right size of the business, and if that means you have to fire friends or let the adults take over, do it. It’s about money, and most founders have a sizable piece of the business where they shouldn’t have to worry about cashing out if the right people are brought in.

Most founders also wouldn’t get hired at their own company, because frankly the people hired after that were brought in for the purpose of building something, while the founders had the idea.

Hire people you trust that can get the job done, but you are disconnected enough to if the time comes, you have to let them go. I’m not saying that you shouldn’t ever work with your friends, but what I’m saying when the time comes, and money’s on the table, there’s a good chance they won’t be your friend.

Do hire people you know and trust

In a startup, someone that isn’t pulling their weight is so obvious, you’ll see complaints for months. If you bring people into the startup, investigate their background throughly, including whether they can handle a startup environment. That means if their last four jobs were with large Fortune 500 corporations with education reimbursement and 40-hour work weeks, they won’t like a startup.

Read their LinkedIn profile, talk to their friends, reach out to the community to see if anyone else knows about them. Remember that you’ll be seeing more of this person for a while than your signifcant other, so if you have to work with them that much, you better be able to work with them that much.

Who has the money makes the rules

If you have reached out to angel funding or venture capital, or one of the founders is funding the project out of their pockets or their parents’ pockets, they’re driving the bus.

In fact, I’m going to make a crazy recommendation: at least one person on your team should be the sales or business development driving force, and they should have a track record to driving deals to completion.

I’ve seen many of company that was driven by the technology team or another team that wasn’t sales related, and that’s just a bad mix: developers aren’t trained in business, and it’s really all about the focus on the customer.

Why?

That person in the startup will be the driving force to getting customers because 1) they will know what the customers want, and 2) their primary, first, only and last concern is figuring out how to build product that actually makes money. That said, the sales person or money person should be reigned in once in a while, especially when proposing features that will help one small client instead of scaling the greater client base.

In any case, you’ll get the occasional stupid feature because the venture capitalist wanted it, or dad with the trust fund it was a good idea. That’s okay, just limit the damage.

Think Harry S Truman: the buck has to stop somewhere.

There’s never enough money, so plan for it

Jason Calcanis sent out a great note earlier this week about money relating to startups (and few know better than him). His key points were, “what ever you have, stretch it.” That means cutting deeply, cutting swiftly, and showing the investors, one of them you, that you’re serious.

There’s this thought process that everyone internet company should be be big, and that, frankly, shouldn’t be the case. He stated in his email that some companies seems to get more done with 25 people than 40. I remember working for Stamps.com when we were at 550 people, and I kept thinking, “There’s too many people here.”

Lo and behold. They cut.

If I had one piece of truth for every entrepreneur out there, this is it: don’t over hire. Focus your energies on hiring people can run as fast as possible, and focus only on the most important features. If you don’t have enough people, don’t build it, because if you hire too many people, you’ll be cutting those people later.

If you really, really need people, hire contractors that you know are going to leave sooner or later. How do you know there’s too many people? You’ll know. When you have four or five non-performers, you’ll really know.

Every startup has a ramp up phase and a ramp down phase to the real business. Startups should be structured and planned accordingly.

Your carpenter shouldn’t be designing the house

While everyone has an opinion about web design, user experience, product management, and other marketing points, that doesn’t make them uniquely qualified to manage a project through 38 iterations of a logo design (except, of course, if I’m the consultant). There’s a reason you’ve brought together the people on your team, and they should be allowed to do their jobs.

That doesn’t mean their shouldn’t be opinion; if you’ve hired some good people, though, ideas that aren’t as effective will be shown as so through discourse and disagreement, and well thought out answers will lead to the path of the righteous product.

It’s about everyone realizing their role in the company and not interfering to a negative aspect other people’s roles. Someone has to be the drummer or the base player, and it just might be you.

There are a few drummers that come to mind (Guy Kawasaki, Ringo Starr, Adam Clayton), and they seem to be doing okay, right?

Don’t build on some exotic platform

Every once in a while, I hear of a startup of that builds on some exotic software platform like OpenLazlo. That platform might have some advantages, especially in a rich media environment, but here’s a couple points to remember:

• If it were so good, everyone would be converting to it. Software likes a good stampede, and while there may be caveats to using .NET and Java, there’s a reason it’s everywhere: there are a lot of developers using it or with experience in it.
• It’s going to be really hard to find developers if the site’s built in Python and Ruby on Rails. Developers love a new technology, and startups are the green field of using it. That means all those maintenance projects using other languages go by the wayside, there are no tools, but there’s this promise of building it really fast. Until, of course, you have to hire more people outside of your circle of friends. It’s a really bad idea to set your sights on a technology that you’re going to be paying developers a premium later.

There’s no harm on developing on PHP if it gets you out the door and beyond, and there’s no harm also developing a site as throwaway code if you know and plan for it.

Focus on features people will use, instead of silly administration tools used by five people once a month

The best thing about a recession and a lack of money is that companies do more research on figuring out exactly what their customers need or the product features that are required to get the project out the door, instead of just throwing stuff against the wall (read: Google). This is because money is tight, and every dollar counts.

If you are building features, focus on the ones that help the greatest number of people — for example, a feature that helps 100,000 people is better than one that’s going to help 100 people once over a year, and it has a lot higher return on investment — because that’s where the value is.

Make a big long list of features, write them up on a whiteboard, and guess (really, guess) how many people will be using a feature, what percentage of the time, and if it can be done by hand.

This could mean going into the database directly to enter information, or relying on less than automated tools. If it’s more of serving a small group of people some manual work that can easily be done, don’t do the feature.

Don’t let perfect stand in the way of good

Thinking that you’re going to have every feature perfect on the first version is an unrealistic expectation; that’s why it’s the first version, and the early versions of most software usually suck (read: Microsoft Windows). That said, that gives you a lot of room to get better, and that should be your goal — do just good enough today to improve upon later. Your users will excuse a few issues at the beginning if you’re upfront with them.

The first rule: work in iterations.

Agile development is an awesome culture for startup development, because the team knows there are going to be areas to refactor, and parts of the software that just aren’t going to be working. Knowing that is a huge release of stress, and allows the team to move forward.

The most important goal should be getting something out there that accomplishes to goal 80 percent of the time, and keep working on it.

Lastly, remember, 90 percent of startups fail, learn from it

There’s a reason only three startup ideas have survived Startup Weekend around the country: most startups don’t see the light of day for all kinds of reasons, mostly because there wasn’t enough thought put into developing the product. That goes the same in the real world, sometimes for not having enough cash, sometimes for having a poor product strategy.

It all depends on your attitude — if you remember that it’s the ride of the lifetime, you can live it and enjoy it. Forget about the money, and remember the joy of creating.

 Comments | Comment

One way to generate publicity for your firm is to become known as the “go to” expert in your field. Your business’ goals will determine whether your aim is to make a name for yourself nationally, locally, within your line of work, in relevant online communities or in some combination of the above. What can you do to establish yourself as an expert? Try some of the following tactics:

• Give Talks. Speak at meetings of community groups, trade associations and any other organization whose members would be interested in your area of expertise.
• Publish Articles. Write a regular column or series of articles for your local newspaper or for magazines or websites that are read by your target audience.
• Join Online Discussion Groups. Become a regular participant on the most popular discussion boards for your target audience. Be sure your signature line identifies who you are and includes a link to your firm’s website.
• Write a Newsletter. An informative newsletter can help establish you as a knowledgeable expert.
• Write a Book or E-Book. If you’ve been writing articles, turn a collection of them into a book. Even if you publish it yourself, this will make you a “published author” in your field.

Although becoming known as an expert requires an on-going effort, the benefits – increased exposure, leads and sales for your business – can make it all worthwhile.

 Comments | Comment

This is was once cutting edge Flash work. Scary.

Jakob Nielsen probably thought it was 99 percent bad.

 Comments | Comment

There was a certain mailing that I was on, and they were reacting to a post by Joel Spolsky naming the program manager as the owner of User Experience in some software teams.

I’ve actually held a position called Program Manager in the Microsoft model, and it was great: I got to work with great developers, and I gained a lot of knowledge about the technology I was working in. Personally, I would love to do that job again.

Back to the UX folks and their comments about the article.

Their opinion was slightly irritable (them being a bunch of cantankerous UX people like me, and I can be even more cantankerous at times). The way I look at it, Joel handed us a gift horse in the mouth. Here’s a well respected member of the software community saying emphatically that user experience matters.

He established:

• The most important function of a program manager is to design the user interface. Sure, we should know a bit about programming, but our job is to show through out experience and knowledge what an effective user interface is, and to help developers implement it.
• He established the value of functional requirements in some form as a deliverable that’s important to the process. That is more than, as he so rightly pointed out, 37signals has done over the years. 37signals is some kind of darling of the web community, and while they do some good stuff when if comes user testing, functional requirements is something they say not to do.
• He set the ratio of program managers to developers at about one program manager to four developers, exactly or close to what I preach. That, my folks, is job security. When I worked as   a product manager, that was a well oiled team. We produced a lot of good code, and I felt I could handle enough of the workload without working too many more hours.
• He also set that discourse and communication is important to great user interfaces. This includes conflict, iterations, data, testing and all the other fun methods that we do to get where we need to go. He basically established that there was value to that last mile.

Frankly, that was one of the better posts I’ve read for a while on any blog.

Great, you say. He didn’t say kind enough words about us UX folks, saying that anyone out of college could do it. Well, not completely true, but we do have to listen to him.

Why?

• He’s very well respected in the software development community.
• He has a company that’s very profitable based around a subscription model product that might not be the best looking product in the world, but developers love using it because of it’s ease of use and simplicity (try saying that about Bugzilla).
• He has a blog that gets a lot of traffic.

That said, there’s points in his blog post that could generate some disagreement; it’s up to user experience professionals to build bridges of understanding because, frankly, we’ve done a piss-poor job of explaining who we are, and what our value is.

On to the disagreements.

He did say that someone right out of college could do the job; I disagree with that.

Being an advocate for the user and the business takes training and/or experience, and isn’t something you can just learn from the programmers you are working with — they know less about user experience than you might — in the same way that a web or print designer needs seasoning even when right out of school.

They can’t learn typography to an adequate level unless they use it, motion design doesn’t just come to you, and more importantly, some of this field is something you can’t teach. You just have to have the skills and mindset for not only understanding the user but also understanding the business. That takes experience in design, domain knowledge, an understanding of what you don’t know, and where to go find it. They have to learn to fail, and learn from their failings so they can succeed.

To get to where I’m at, I’ve been working the web for almost 15 years (something that few can say), and I draw from all my unique experiences to develop user interfaces for my clients. That experience includes a background in writing, design, business and software development. As we all know, sometimes the greatest failings of people without the knowledge they need think they know more than they do; only as we get older do we realize how much we don’t know.

Great software architects architects are made, not born.

Joel, because of the peers he worked with Microsoft, learned wisdom far beyond what most program managers and user experience professionals would ever hope to, and he has used to it to advance software development. But this does color his view of the world, and it’s up to us to talk about where we have come from, so we can advance from all fronts, not just by being lucky enough to work at a company that at least was trying a process.

As the user experience field grows, it’s great to have other respected voices establish benchmarks that there is a need for user experience. Now we just have to work with them for everyone’s benefit.

 Comments | Comment

I came across this post on SitePoint, and noticed the page navigation. Eight pages. I have a few articles that should have been broken up into a few pages, and this article could have been condensed (how much can you say about successful freelancing?).

The main reason it was eight pages, it seems, is that there’s a poster ad on every page.

Users.

Hate.

This.

There’s a good chance very few people actually made it the eighth page.

This could have been a several part series — keep bringing the users back — or there could have been some editing. Users don’t mind scrolling if there’s some payoff, or the content in engaging. Gauge the content first, to see if people actually want to read it, and see if there’s ways you can break it up other than paging it like this.

 Comments | Comment

I’ve been there. Oh, I’ve been there.

 Comments | Comment

I’m working on an e-commerce project, and we’re trying to streamline how people buy items. There are a few difficult points that we’re dealing with on the site, but one interesting aspects of going through the process that most user experience architects would completely gloss over during their analysis.

We live in a world where it’s great we’re concerned with the user, but more importantly, there’s a business there that has real needs for customer conversion. This puts user experience at odds with business goals: how do you guarantee that people will checkout?

When you walk into a supermarket, you pick up what you need, walk over to the counter, and pay. More often than not, there’s someone behind you, and — you can’t leave. You have to buy that milk and cookies, and if you don’t, you have to return them, interrupting the flow of the purchase process with the person behind you.

In the virtual world, there is no-one behind you, but because of the anonymity of using the web, it’s okay to leave the milk and cookies right there. You never ever see that in the real world.

Buttons during the checkout process give users exits, some of which allow you to leave the milk and cookies right there.

It’s great that they can return to their bag, but by the time they get to the checkout process, they know either what they want to buy, or they’re looking for a shipping price (which is an indication of a user experience that needs review).

I usually remove buttons, and limit their interaction with other parts of the checkout process. Most users will select the back button if they are looking to return to other parts of the checkout process, and that is usually evident in the reports the web analysis tools display. More importantly, you’re reinforcing that they’re in a checkout line, and they should move along. I think we coddle users too much, trying to give them every opportunity to move around, especially if the site we have is based on a business.

That’s one way I resolve business goals that are more important the profitability of a site. What do you do?

 Comments | Comment

Welcome to podcast number four with Marc Danziger, a social media and project management consultant, and his blog is Charmed Particles. Today, we talk about the importance of the quality of community, and how it can affect the business goals of a company.

Download the MP3.

[podcast]/_podcast/usabilitycounts.com-004.mp3[/podcast]

 Comments | Comment

It’s been a wind down mode from Startup Weekend LA. It was a very successful event: six projects got pretty close to out the door. I don’t know how many other projects are continuing their work, but the team I joined is exploring continuing our work. There will be more on that later.

One of the learning experiences from the event is having  only two and a half days of product development time makes you focus on two things:

• Being innovative in ways in using the other team members to get work done
• Focusing on features that are  essential to getting the product out the door

Everything else was gravy.

We were lucky — we reused a framework from another site that we could use to build the idea. Most importantly we split up the tasks of what we had to do early on, and for a few of the features, we were able to delegate the work so no one person was absolutely getting killed. We had a small content editing tool and a primitive but effective framework so the other team members could add data to the site.

We focused on essential features by using a form of Scrum development: we listed all the features on yellow post-its on the wall. This allowed us the to prioritize based on need of the feature for a proof of concept demo. This is different than product development for a real product, because you can fake some things in a demo (like administration screens are totally unnecessary if you have PHP MySql Admin, and can access the database directly).

The result? By 2 p.m. Sunday, we were tired, but we had enough of a site that we could demo, and even more importantly, a site that we could eventually turn into a production product for a short amount of time until we migrated it to a real platform. That was actually one of the discussions that we had: preparing to launch a site that we all knew was completely throw away code, but something that could be migrated to a better architected platform.

What are your startup stories? How did you effectively get sites out the door while focusing on just the essentials?

 Comments | Comment