I personally think prototyping is the way to go when creating a new software product (or any product really). You get to “blueprint” out how something is going to work, how the pieces fit together, and how it will really work once launched. I think most people are sold on the concept, so it’s a matter of how to build this close-to-real product that you can test with your user base. Do you use paper? Mock-ups? Tools like iRise and Axure, or get real and build a non-functioning ready to reuse front-end?

The first step is defining what you’re going to use this prototype for. Is it to drum out business requirements? Demo to clients before they write the big check? Or get something as close as possible to the real thing, so you can start the User Centered Design process and test your ideas on actual people that will be using your product.

Obviously I enjoy prototyping for the latter, getting real feedback that our team’s ideas were dead on, or widely off-base (never!). To do this, you really want to build the prototype in the technology you’re going to create the finished product in (usually HTML or Flex for web based software). This solves two problems: one, this truly is as close to the real thing as you can get. By using the actual UI technology you’ll be creating the final product in, you’ll know what can and can’t be done, users will get a real feeling for the responsiveness, animations, and interactions. It’s real, sans the months of backend development needed to power this prototype. And two, you can pass this finished front-end code off to the development team, taking pressure off backend developers who may not be well versed in front-end development.

Microsoft when working on Office 2007 did this very thing:

“if you’re trying to build a prototype that you want use as a blueprint, it should exist in the same medium as the final product.”

In the past when I’ve run prototyping projects, the teams usually consist of just one designer/IA, one developer, and a small amount of a backend developers time (to get some fake system data up and running). Depending on the maturity of your front-end development group, you may have sets of UI widgets and code ready to go, this will help speed up the overall process.

Dave Cronin from Cooper recently wrote an article titled “Industry trends in prototyping” – which I agree with about everything in the article – he lists out four reasons for creating prototypes: prototypes make your designs better, help facilitate communication, enable user input and usability assessment, and help assess technical feasibility and reduce development time. He’s also a fan of creating “real” prototypes where it makes sense.

I love this comment from Philip Fierlinger:

Prototypes, on the other hand, let people feel the flow and experience the relationships. Building prototypes allows architects and interaction designers to quickly identify broken pathways and iterate quickly to find better flows – by feeling the experience, rather than thinking about it in the abstract. Developers, designers and clients also get a much more tangible sense of what the end product will be.

Again, I can’t stress enough how a “real” prototype will give you the best feedback for the effort. We’ve also used these prototypes to help sell ideas to business groups. Imagine trying to sell an idea for a mobile app by letting your VP access it directly on their phone. This will beat out any PowerPoint presentation.

Garrett wrote on this topic years ago, and the technology is now easier to use than ever before. There are frameworks, open source systems, and reusable icon sets ready to be molded into your own prototype.

Using wireframes or paper for low-fedility prototyping is not necessarily a bad thing. Maybe your just testing internally, or you’re limited with your technology skills. There are discussions about what fidelity wireframes should be (both form and function). There are many tools at your disposal for creating wireframes and prototypes, and they’ve really just recently gotten easy to use. No longer are you stuck with Visio – here’s a list of some tools, ranging from very expensive to free with varying sets of features:

• Axure
• Pencil Project
• Balsamiq Mockups
• Adobe Flash Catalyst
• iRise
• OmniGraffle
• Lovely Charts
• Rapidrabb.it
• iplotz.com
• Prototype Composer
• fluidIA
• WireframeSketcher
• MockupScreens

Boxes and Arrows has an article from 2006 written by Scott McDowell, that goes over some of these options, but what’s really interesting are the comments below the article where designers talk from real world experience. And Russell Wilson from Dexo Design compares 16 prototyping tools (2008) and again, the comments are interesting.

I tend to use wireframes to quickly get across ideas and interactions. Something that could possibly be thrown away, or will be changed a number of times. Once the idea seems to stick, I move to high fidelity mock-ups, sometimes merging the mock-ups together in a slide-by-slide presentation showing the page flow with faked interactions.

GUUUI posted some links to videos showing lo-fidelity prototypes in action. Again, this can work to help guide overall concepts, but to get true feedback – you really need to have a higher level of fidelity.

If you’re in a good situation where you’re ahead of the product timeline, prototyping is your next step. Just like how a architect moves to a model, build out your prototype and test, iterate, improve, and in the end launch a successful product!

(additions)
Great post over at Adaptive Path: Rapid Prototyping Tools

When creating an online desktop experience, as Designers we want to choose the most interactive medium possible – then weigh that with the audience we’re designing for and make a decision. XHTML/AJAX? Adobe AIR? MS Silverlight? With each of these options we can create a highly interactive experience, with real-time interactions, large graphics, sound, and even 3D in some cases. And it’s something we’ve grown accustom to with better computers, better browsers, and more bandwidth.

But when Designing for mobile, we’re kind of partying like it’s 1999. With browser fragmentation, low speeds, and low adoption of mobile data – what interactions should you be designing for mobile devices?

There are four main ways to interact with a mobile device:

• Voice (Approx. 100% Adoption)
• SMS/MMS (Approx. 40% Adoption)
• the mobile browser (Approx. 15% Adoption)
• content via. mobile applications (Approx. 4% Adoption)

And within each of those segments it’s fragmented further with five different ways to display mobile content through a browser:

• Small Screen Rendering
• Reformatting
• Mobile Style Sheets
• Mobile Specific XHTML
• “desktop web” DeepFish / Mobile Safari / S60
• … and all the different browsers (40+)

and at least eight ways to develop a application for the different devices:

• JAVE ME
• BREW
• PALM OS
• Windows Mobile OS (and Smart Phone)
• BlackBerry OS
• Nokia S60
• Flash Lite
• Opera Widgets

So which do you choose?

I put together this graph to illustrate the different options:

Download PDF

I’ve updated the PDF above with more information – Download Updated PDF (400k)

I like Google’s approach, they’ve explored almost every interaction point, including voice with the new GOOG-411 service. You can get addresses, and look up business via SMS, web, or get a downloadable application – even a custom BlackBerry application that uses the phones GPS to determine your current location.

Now, if you use each of these I’m sure you’ll find the custom OS application the easiest to use, and overall the best experience. But, not everyone has the resources that Google has (in-fact I’m not sure anyone does!). This means you really need to look at your audience, the resources available, and make a decision on what to develop for.

A project I’m currently working on we ran into this very problem. We had vendors pushing applications, but the adoption for these are very niche – and our user research really didn’t support the cost to create a custom application. As a UX Designer, this is disappointing ;-) But wanting to earn that “D” in Designer, working with constraints is a good thing. So we decided to go with a mobile specific site – and that’s what I’m currently working on.

Just because you’re not getting the best interaction on a device, doesn’t mean the experience is reduced, it’s up to you to give people a great experience on any medium and platform – and that’s what makes a great Designer.

SXSWi has come and gone again, this was my fourth time to attend and it just keeps getting bigger every year. When I first visited in 2003 (or was it 2002?) Bruce Sterling was still throwing SXSWi parties at his home and FROG Design hosted everyone in their office, unfortunately that doesn’t really scale to the size of the conference today. But, the panels were as diverse and interesting as ever – and I came back with the following brain-dump:

(note to readers, I tend to take notes in bullet-point format, which is reflected below)

Emerging Social and Technology Trends

(More detailed notes here)

• Check out: http://outside.in/
• Check out: http://www.indie911.com/
• The age of sharing your information publicly is here to stay, it’s normal for “kids” – they wonder why you are not blogging what you had for lunch
• Room to add more control, maybe you only connect with people you’ve met with in real life (RFID to Linkedin?)
• In india you can send an email to a post address, and a post to an email address

Getting to Consistency

(More detailed notes here)

• If working on a suite of applications, look for “connection points” – the apps don’t need to be 100% consistent
• You don’t need to be consistent just for legacy sake
• There is room for some discovery within a UI
• Sometimes a clean break is the best way, when upgrading applications
• Remember: Goals no Features!!!
• Integrate what is valuable and saves time
• See when your users evolve. Adobe noticed things like RAW workflow, widescreen monitors, etc… Breaks based on user habits
• Watch out for reusing objects if they don’t provide the same experience
• Design for workflows
• Capture what the user wants to do
• Adobe found users all most always select the advanced mode when given a choice, they feel like they are missing out on something if the don’t
• Pick up on user patterns
• BMW has consistent “signatures” from the MINI Cooper to the top of the line BMW
• All about goals, again – goals not features
• Make it easy for developers and designers to stay consistent with guidelines and toolkits
• Use peer review to pick up on problems in consistency

Stop designing products

(More detailed notes here)

• Design from the outside in
• Check out: http://www.flickr.com/about/

Designing for Convergent Devices

(More detailed notes here)

• 10ft design vs. 2ft design vs. 6in design
• Control, Branding, Standards, Trust
• Check out: http://www.zannel.com/
• Look for the “Golden Pathway”
• Remember the ecosystem (not just your product)
• Support: Environment, Activities, and Device (Display, Input, and Platform)
• Remember things like: Screen, Font and Colors, Input Devices, Focus States, User Feedback, Task Complexity, and User Expectations
• Have the web be a companion for mobile. If possible have users fill out information on the web, then interact with the mobile experience.
• Keep it simple, get only NEEDED data upfront – and continue to fill out a user profile as your “relationship” goes on

Mobile Design

(you can download the full presentation here)

• 60% mobile users access mobile data once a month
• XHTML-MP is WAP 2.0
• Common devices to test for: Nokia S40, RAZR, Treo, “Give-a-ways”
• Check out: http://www.deviceanywhere.com/

Moving Corporations to Accessibility

• Use tools like: Contests, Awards, and Classes
• You need a evangelist within the company
• Have guidelines and resources for your developers
• Check out: http://www.webaim.org/

Get Unstuck

(More detailed notes here)

• Make sure your team feels like they are doing good work, being productive, and fulfilled
• Have an open process, open up to other teams in your organization
• Work with Design towards a goal
• “Just add value”
• Stop too much process
• Find the middle ground between user needs and business goals
• Have one member of your team always focused on the end solution

Mobile Application Design Challenges

(More detailed notes here)

• Check out: http://radar.net/
• Remember to be aware of the number of clicks in the UI
• Check out: http://www.smallsurfaces.com/

Design Patterns

(More detailed notes here)

• Focus on solutions, encourage good behavior, and remember – “reusable…”
• Most of the good design work is done in the “fuzzy middle” (hard to provide guidelines for)

Customer Service is the New Marketing

(More detailed notes here)

• Check out: http://www.zappos.com
• Zappos has a “Culture Book” they put out each year
• A recurring job title I keep seeing from the panelists is “Community Manager”
• Find ways to get closer to the customer, let your call centers talk to design/development
• Admit mistakes
• On one forum 60% of questions are answered by users
• 30boxes – 3 employees, 30,000 users, forum only help – they spend about 4-6hrs a week on customer service

Truth about Mobile

(More detailed notes here)

• Does your mobile strategy substitute, or complement your experience?
• Advertising is not ready yet
• Data usage is almost there (currently 32%), better to be ready sooner then later

SXSW also had a good mix of keynote speakers, with Will Wright’s being my favorite of the bunch.

Overall it was a great experience – I learned a lot, while being inspired to do more.

So there you have it. My brain dump, remember podcasts and vidcasts will be available here in the near future.

Are you going to Austin this weekend for SXSWi? Or maybe you’re heading for Austin to attend the new Apple Store opening? Either way, I’ll be around. Visiting all the great independent shops and restaurants Austin has to offer, as well as attending SXSWi for the fourth time. Interested in what panels I’m excited to see? (maybe not so much?) – but here it is anyways, my SXSWi list of panels:

Saturday, March 10th

• 10:00 am » Emerging Social and Technology Trends
• 11:30 am » Getting to Consistency: Don’t Make Your Users Think
• 2:00 pm » Kathy Sierra Opening Remarks
• 3:30 pm » Stop Designing Products
• 4:05 pm » Ruining the User Experience: When JavaScript and Ajax Go Bad
• 5:00 pm » High Class and Low Class Web Design

Sunday, March 11th

• 10:00 am » Designing for Convergent Devices
• 11:30 am » Making Your Short Attention-Span Pay Big Dividends
• 2:00 pm » Everything You Always Wanted to Know About the Mobile Web…but Were Afraid to Ask
• 3:30 pm » Learning Interaction Design From Las Vegas
• 4:05 pm » Moving Large Corporations Towards Accessibility
• 5:00 pm » People-Powered Products (or maybe Mash-up Culture…)

Monday, March 12th

• 10:00 am » Get Unstuck: Moving From 1.0 to 2.0
• 11:30 am » Mobile Application Design Challenges and Tips
• 2:00 pm » Dan Rather Keynote Interview
• 3:30 pm » Rails and AJAX: Building Enterprise-Class Web Applications (or maybe People Media…)
• 4:05 pm » Design Patterns: Defining and Sharing Web Interface Design Languages
• 5:00 pm » How to Create A Kickass In-House Design Team

Tuesday, March 13th

• 10:00 am » Customer Service is the New Marketing
• 11:30 am » 12 Values Shaping Technology’s Future
• 2:00 pm » Will Wright Keynote Speech
• 3:30 pm » The Truth About Mobile & The Future of Personal Devices
• 4:05 pm » Data Shrapnel
• 5:00 pm » Bruce Sterling’s SXSW Rant

I’ll be staying at the Hilton Garden Inn downtown, bowling on Sunday night, and enjoying Austin as much as possible.

Recently a developer was going over the browser baselines for a project, they listed them as: IE 6.0, Mozilla 1.5, Netscape 8.0, Opera 9.02 and Safari 1.2. I saw this and thought WAH? Mozilla and Netscape? No IE 7? Safari 1.2? Opera? Let’s take a look and see what should be the baselines for browsers in 2007.

First stop was to check out some global stats:

Looking at these two graphs, I think it’s safe to limit the browser testing to IE 6, IE 7, IE 5 (still has more market-share then Safari) Firefox and Safari.

A couple of points:

The next question I hear from developers is “Why not just develop for IE? Look at the marketshare?”

Well let me tell you…

1) You should be developing for a Web Standards compliant browser (Firefox) then “breaking” it for IE and other browsers. This is the current trend in modern web development, get on the train.

2) Firefox now has a large enough browser share to matter.

3) Mac users (although low in % for browser share) are a segment of the market you want to cater to. They are willing to pay a premium for better experiences, and a large number of them are part of the creative class, making them a very vocal part of the web (writers, producers, designers, bloggers, etc…). A group you don’t want badmouthing your products.

4) Ok, but why Opera? Well Opera really has the most potential out of the lot. This is due to Opera’s strong push to be included in embedded devices. I’ll just take one of the many examples – the Nintendo Wii – it comes with the Opera browser built in, and there are now 4+ million Wiis out in the wild with more and more being sold every day (or how about the 300+ million Nintendo DSs with Opera?). Opera is even being included in some DVD players.

So what should the browser stats be?

Here is my idea for some general guidelines when browser testing:

If you notice, I’ve included %s next to the version numbers. This tells the developer what percentage “correct” it needs to be from the supplied mock-ups. Where as it needs to look 100% in Firefox, it only needs to be functional in IE 5.5 and 95% in Safari.

How do you judge 95% in Safari? This should be up to the designers, if a image is off 10px off or some text is a little larger then in Firefox, then that should be OK – but if the tabs are broken and text is hovering outside a div, that may not be OK – it’s really up to the architect of the experience.

I’ve attached a PDF to this post with some more information, something to pass on to your developers if you see they are testing for AOL 4.2 or something equally as awful.