• Read more about Implementing DRY Magic Methods in Ruby

As a new developer to Ruby you might wonder how certain methods seem to be magically available without being strictly defined. Rails's dynamic finders (e.g. find_by_name) are one example of this kind of magic. It's very simple to implement magic such as this in Ruby, but it's also easy to implement things in a way that doesn't entirely mesh with standard Ruby object expectations.

Your Friend method_missing

The way that many magic methods are implemented is by overriding method_missing. This special method in Ruby is automatically called by the interpreter whenever a method is called that cannot be found. The default behavior of method_missing is to raise a NoMethodError letting the user know that the method that was called does not exist. However, by overriding this behavior we can allow the user to call methods that aren't strictly defined but rather programatically determined at runtime. Let's look at a simple example:

     class Nullifier       def method_missing(*args)         nil       end     end      nullifier = Nullifier.new     nullifier.some_method     # => nil     nullifier.foo(:bar, :baz) # => nil 

Here we simply told method_missing to immediately return nil, regardless of the method name or arguments passed. This essentially means that, for this class, any method call that is not defined on Object (the default superclass for new classes) will return nil.

While this example is certainly interesting, it doesn't necessarily give us more use in the real world. Let's take another example that actually does something useful. Let's make a hash that allows us to access its keys by making method calls:

     class SuperHash  'def'     h.something_else # => NoMethodError 

This behavior gives us something pretty simple yet powerful: we have manipulated the foundation of the class to give us runtime methods. There's a problem, though: using method_missing alone is only half the story.

Quack Check With respond_to?

In Ruby, you can call respond_to? with a symbol method name on any object and it should tell you whether or not that method exists on the object in question. This is part of what makes Ruby's duck-typing work so well. So in our example, we also want to be able to know if a method is there using respond_to?. So let's add a new override for the respond_to? method of our example above:

     class SuperHash < Hash       def respond_to?(symbol, include_private=false)         return true if key?(symbol.to_s)         super       end     end 

Well, that was easy enough. Now our SuperHash will return hash keys based on method_missing and even tell you if the method is there with respond_to?. But there's still one more thing we can do to clean things up a bit: notice how we have repeated functionality in that we check key? in both methods? Now that we have a respond_to? we can use that as a guard for method_missing to make it more confident:

     class SuperHash < Hash       def method_missing(method_name, *args)         return super unless respond_to?(method_name)         self[method_name].to_s       end     end 

Wait, that can't be right, can it? Can we just assume that we can call the key like that? Of course! We already know that no existing method was called if method_missing is activated. That means that if respond_to? is true but no existing method was called, there must be a key in our hash that caused respond_to? to return true. Therefore we can confidently assume that the key exists and simply return it, removing the conditional and cleaning up the method_missing substantially.

Now that you know how method_missing and respond_to? can work together to add functionality to an object at runtime, you have a powerful new tool in your metaprogramming arsenal. Enjoy it!

• Read more about Intrideans Headed to Shanghai for RubyConfChina 2011

November is shaping up to be one of our busiest months for events. This week our design team is in NYC for The Future of Web Design; Ted O'Meara will be in Baltimore next weekend to support Education Hack Day; Michael Bleigh just landed in NYC after presenting at Ruby Midwest, and he, along with all the Senior Partners, will be jetting off to China in two days to meet the Intridea East team in Shanghai for RubyConfChina and then to HangZhou to attend the first Intridea East retreat.

We're sponsoring RubyConfChina for the second year, and it's sure to be a great event; Matz, the "father of Ruby" will be in attendance, among 500 other developers and Ruby enthusiasts from China and beyond. Michael will be presenting a new talk:

Crushing Complacency: Reinvention and Software Development:

When developing software it's easy to allow yourself to become stagnant. Too easily we stop learning, stop revolutionizing, stop questioning because what we have is "good enough." Learn why and how a philosophy of constant competition -- with yourself -- can make you a better developer building better software. With examples from open source, polyglot programming, business, and life, this session will delve into how to keep yourself scrappy, young, and eternally hungry for better.

Michael's talk will take place directly after Matz's opening keynote. Later in the afternoon, Ping (Partner and Director of Asian Operations at Intridea) and Daniel (a Senior Engineer at Intridea living in Shanghai) are presenting "OSS and Startups" to the RubyConfChina attendees. Their talk will focus on tackling the challenges of profit through an OSS business model.

Be sure to check back next week for photos from RubyConfChina, the retreat, and presentation notes from Michael! And make sure you're following us on Twitter - it's a great way to get current information about open positions, open source announcements, event sponsorships, presentation materials, and more.

• Read more about Intridea Client Homezada Launches Home Management Software

Last week Homezada officially released their home management software, a complete solution to the dispersed files, incomplete records, and scattered maintenance reports that plague homeowners everywhere.

Homezada's formula is "Everything about your home in one place" and they're serious about that; their software allows you to easily document all the possessions in your home, track the value of all of those items, track household improvements (making it easier to remember what you've done to improve your house when you decide to sell it), access an ongoing library of to-do maintenance items, and maintain checklists of seasonal cleaning, yardwork and maintenance projects. The system can remind you when it's time to update air filters, schedule furnace maintenance, and so on.

Below is screenshot of the to-do list functionality of the application:

Homezada approached Intridea to draft the wireframes, help design the user flow, and refine the user experience. Our design team, led by Jurgen and Ted, worked with their internal Rails development team to deliver an engaging and intuitive user experience and to help stylize it within the Rails app.

We were excited to work with Homezada on such an interesting and revolutionary project. We encourage you to watch some of the short videos on their site to learn more about the software.

If you need design or development expertise on your project contact us today to learn what we can do for you; at Intridea we are helping hundreds of people bring their ideas to life!

• Read more about Michael Bleigh on Rails 3 at Ruby Midwest

Intridea Partner and open source crusader, Michael Bleigh, will be back in his hometown of Kansas City this week, presenting "Rails is the new Rails" at Ruby Midwest.

The sweeping changes brought on by Rails 3 and 3.1 haven’t just made our existing development patterns easier, they have opened up the ability for us to build new patterns that accomplish more in a more beautiful and efficient way. In this session you will see how thinking about new features in a different light can lead to real innovation for your development practices. Examples include baking routing constraints into your models, application composition with Rack, truly modular design with the asset pipeline, and more.

Coming off a huge month of open source development on OmniAuth (version 1.0.0 was just released this morning), and working onsite for a huge client in NYC on a cutting-edge Rails app, Michael is excited to share his recent insights on Rails 3. Be sure to catch his presentation on Friday, November 4th at 10:30 am, just after the morning break. Follow Michael on Twitter for updates from this (and upcoming) conferences!

• Read more about OmniAuth 1.0: Auth for All

Today I'm happy to announce that OmniAuth version 1.0.0 has been released into the wild. The result of more than a month of heavy development, the newest version of OmniAuth brings along with it a slate of new features, a whole new structure, and the tools to let OmniAuth be your only authentication library. The one thing that hasn't changed is OmniAuth's mission: to assume nothing about how your app works and what you want to do with authentication.

Breaking up the Band

OmniAuth was first written to abstract the common parts of authentication to external service providers like Twitter and Facebook. It launched as a small collection of gems that each contained many strategies (for instance, the oa-oauth gem contained Twitter and LinkedIn strategies). As OmniAuth's popularity grew five strategies became fifty-five. Releases became fewer and further between because of the overhead of managing pull requests and issues for dozens of strategies.

No more. Starting with OmniAuth 1.0, each and every OmniAuth strategy will live in its own gem. The downside of this for end users is that you will have a few more lines to declare in your Gemfiles. The upsides, however, are numerous:

1. There is no longer a gatekeeper to releasing an OmniAuth strategy. Just build a gem, release it, and link it from the new strategy list wiki page.
2. Individual strategies are free to make releases as often as they'd like. Users don't have to wait for a massive OmniAuth patch or minor release to pick up fixes for changing APIs or other improvements.
3. With a lean, focused core OmniAuth itself will be able to release more frequently and adapt itself to the needs of strategy authors.

As a final note about structural gem changes, OmniAuth 1.0 marks the beginning of strict semantic versioning for the project. For end users, this doesn't mean much. For strategy authors, that means that you can safely declare your dependency on ~> 1.0.

Identity for OmniAuth

As I began using OmniAuth in my day-to-day coding, I began to crave the flexibility of OmniAuth in even traditional authentication scenarios. I wanted a way to leverage the same unassuming, simple authentication structure even when my users logged in via username and password. Today, I'm happy to announce the first official release of omniauth-identity, an OmniAuth strategy that bridges the gap between traditional auth and OmniAuth.

With omniauth-identity you can quickly and easily set up internal identity management for your app that behaves exactly like other OmniAuth strategies. The library is simple but its implications are powerful: you can now treat internal and external authentication exactly the same in your application.

OmniAuth now ships with a Developer strategy that is essentially "fake authentication" you can use as a placeholder until you determine your app's real authentication strategies. Combined with the potential of Identity, authentication no longer has to be that annoying "first thing" you have to do before you can get down to the real business of building your app. Just drop in OmniAuth, use the Developer strategy, and implement other strategies down the road when it works for the timeline of your app. This is how I'll be building all my apps from now on, and since OmniAuth is just Rack middleware even Sinatra and other non-Rails apps can use the same techniques.

For more information on how to use omniauth-identity, see the README on GitHub.

Strategy Builders: Better Docs, Better Tools

For the 1.0 release in addition to all of the new features and structure I also tried to significantly improve the documentation for the project, especially for those who are interested in building a strategy. You can see the results of those efforts on the OmniAuth wiki which is the official repository of all documentation for OmniAuth.

Along with better documentation for developers OmniAuth 1.0 also brings along a more declarative DSL for building strategies. The new strategy API gives developers clear ways to implement consistent functionality and makes everything cleaner across the board. For more information on the tools available for strategy developers, take a look at the Strategy Contribution Guide.

App Developers: Consistency, Dynamic Strategies

While many of the improvements in OmniAuth are structural and made for strategy developers, there's also some great stuff available for everyday users of OmniAuth! Here's some highlights of new features that work across all strategies:

Auth Hash. Some small tweaks have been made to the omniauth.auth hash that is returned after authentication completes. For one, you can now access keys using method accessors (e.g. env['omniauth.auth'].info.name. The user_info key has also been renamed simply to info. The schema can be considered a stable part of the public API and any breaking changes will trigger a major version release (you can rely on OmniAuth 1.9 to support the same schema as 1.0).

Options Everywhere. As of OmniAuth 1.0, strategy authors are encouraged to make all strategy configuration happen through the options hash that is passed in on initialization. You will still have strategies that have additional arguments (such as consumer keys and secrets) for convenience, but even those can be configured instead by passing in a single options hash. This means that every configurable aspect of the strategy is handled at runtime, which brings us to the next improvement.

Better Dynamic Strategies. OmniAuth 1.0 makes it easy to dynamically alter strategies for each request using the new, universally available setup phase. Simply set the :setup option to a Rack endpoint and you can modify the strategy or anything else about the environment before passing it along to OmniAuth for normal operation.

Skip Info. Some strategies will be able to determine the UID without making additional API calls. You can pass true, false, or a lambda that takes a UID and returns true or false as to whether additional info is required. This gives you the ability to make fewer API calls for cases where you already have a user in your system, for instance.

Custom Forms. If you are utilizing an OmniAuth strategy that displays the standard OmniAuth form, you can now pass in :form => (true || false || lambda) to the strategy to instead render a custom form that conforms better to your application. This replaces the previous poorly conceived method of requiring /auth/:provider to return a 404 in order for OmniAuth to trigger.

Calling All Companies

Now that each strategy for OmniAuth is its own gem, I'm putting a public call out to any and all companies with APIs, but especially companies that are already on a Ruby stack. I would like to get companies on board for maintaining their own "official" OmniAuth strategies. This gives developers using your API the simplest possible means of authenticating to your service and will only help you get more developer traction and experimentation.

I'm also happy to announce that our first "official" strategy maintainers are none other than GitHub! You can say hello to the official GitHub OmniAuth strategy and be sure that any changes to the GitHub API will be safely transitioned into the gem immediately. My hope is that going forward many more companies will join the official strategy ranks. If you're interested in maintaining an official strategy.

Where's That Strategy?

Because of the structural changes to OmniAuth not all existing strategies are available at launch. I fully expect that in the coming weeks the strategy count will regain lost ground and even surpass the count as of the last 0.x release, but if your favorite strategy is missing from the official list here's what you can do about it:

1. Find the source code for your strategy in the 0-3-stable branch
2. Clone omniauth-contrib and add the strategy there
3. Follow the strategy adaption guide to update the strategy for 1.0
4. Submit a pull request!

The omniauth-contrib repository is a temporary repository for strategies that have been written but aren't robust and supported enough to have their own gem yet. This repository is not going to be maintained as an actual RubyGem and the strategies contained inside are meant to eventually be adopted by developers to become their own gems.

One More Thing

One last thing that I wanted to do for 1.0 is create a kind of living example that the community could update to have a simple example of as many strategies as possible. You can now visit omniauth.org and try out a number of authentication strategies that OmniAuth has to offer. The code is all open so you can see how simple it is to add and use OmniAuth in your applications today!

Welcome to 1.0

OmniAuth 1.0 marks an important milestone for the project and I'm looking forward to a new, leaner trajectory that lets us make changes more nimbly (and keeps the outstanding issue count low to zero). While the changes for 1.0 were mostly written by me, OmniAuth has been an outstanding community effort and it couldn't have gotten to where it is today without the efforts of @sferik and countless other contributors. I hope you enjoy the new release and look forward to hearing your feedback!

• Read more about Grease for Squeaky Products - Tips from QA Land

As a QA Manager who often oversees more than a dozen projects at a time across both client/services and internal/product development I get an inside look at what helps projects succeed. Today I’m pulling my head out of the depths of QA Land to give you an important tip that’s been rattling around my brain cage for the last couple of weeks:

The squeaky wheel gets the grease

In other words, speak up. And keep speaking up until something is fixed.

Now I know that proverbs are silly to use since many of them are so contradictory: “good things come to those who wait”, right? Listen up folks — in the world of software development, good things do not come to those who wait. In fact, waiting around does absolutely nothing except tank your chances for successful delivery and implementation.

People have all different kinds of reasons for not speaking up: they’re too busy, they don’t want someone to think they’re complaining, they don’t want to feel like they’re a burden to the person who will have to make the fix, they don’t want to appear to be negative, etc.

Whether you’re a developer, a designer, or just someone who happens to be clicking around in an application it’s vital to speak up when you encounter things you aren’t expecting, or bugs, or undesired behavior from the application. The people that are working with the project are usually so deeply involved that it’s easy to miss surface-level mistakes that might seem so apparent to someone else. And if you don’t raise your voice about it, it might not ever get “greased”.

Here are some basic tips for “squeaking up” and getting heard:

Do:

• Contact someone on the project and politely let them know what sort of ugly bug you’ve uncovered.
• Be as specific as possible about the problem – give information about what browser (and version) you were using at the time, which OS, etc.
• Take a screenshot if possible and annotate it, conveying the issue as clearly as possible.
• Be proactive and create a ticket, including all of this helpful info about the bug in the ticket notes. This saves QA a step and ensures it gets (and stays) on their radar.
• If the issue isn’t resolved, be sure to follow up with someone about it (politely, of course).
• Explain the reasons you don’t agree with a certain type of functionality, citing helpful examples.

Don’t:

• Yell about the problem from across the room, which will inevitably make the QA and dev team feel like you’re making a long-ranged attack.
• Contact someone higher up in the chain than you need to – just report the issue to the person(s) that is working with the code daily and can help take care of the problem. Going above their head is an adversarial move.
• Get angry if people disagree with your insights about a type of functionality – maybe you don’t see the reason for it, but the dev team insists, even after open discussions about it, that that particular functionality has to remain as-is.

In short, your product won’t be a great product if it’s chock full of holes, nasty bugs, odd functionality, and so forth. It’s everyone’s job to report the wonky things they come across, even if you don’t want to “bother” people. You can be “squeaky” without be “squawky.”

• Read more about Education Hack Day - Applications for Education

This November, a crowd of pioneering programmers will gather at Digital Harbor High School in Baltimore to create applications that provide solutions to teachers, students and schools.

The American Education system is a large, complex structure. It is often targeted as a system that desperately needs improvement, yet its proportion makes is seem impenetrable and unchangeable. As technology advances schools struggle to keep up. Teachers work to find ways to use technology on their own to improve their systems locally and to reach students in more modern and relevant ways.

If we teach today as we taught yesterday, we rob our children of tomorrow. -- John Dewey

Education Hack Day brings teachers and technologists together to create smart solutions to today's education-related problems. Developers will create applications from ideas that are being crowdsourced from local teachers and administrators.

Imagine an app that automatically calls a parent when a student is marked as absent to let them know their child isn’t in school. Something like this could be built in a weekend and could help curb truancy.

--Education Hack Day

Ted O'Meara, a Project Manager and User Interface Designer at Intridea will be at the event. He will be working on an open source BoardMaker-type application called Boardspeak that can be used by Speech Therapists working with individuals on speech rehabilitation, as well as assisting other populations facing cognitive impairments. Ted, who is also a grad student in the Human-Centered Computing Program at UMBC is no stranger to the relationship between education and technology. He continually looks for ways that usable, well-designed software can solve problems for others. Most recently, he has been working on CogConnect, a mobile rehabilitation application for stroke patients.

Other developers will be working on a cloud-based registrar, a large-scale student management package, a homework notifier app for parents, a Parent/Teacher conference scheduling application, converting science animations from Flash to HTML5 so teachers can show them to students on iPads, an application to aggregate information about literary events taking place in the area, among many other applications that address the emerging needs of educators in this mobile age.

Education Hack Day is the brain-child of Mike Brenner, a luminary in the Baltimore tech scene who has played a part in other ventures like Refresh Bmore and Startup Baltimore. Mike hopes the teams that create applications will go on to become sustainable product companies:

Our goal as event organizers is to provide the facility, the fuel (food + drinks), and the resources needed to creatively solve these problems. We also are working hard to make sure that the weekend doesn’t just end on Sunday. We want big companies and angel investors to reward our small teams and incentivise their continued progress through seed investments and pro-bono business development.

--Education Hack Day

We're proud to sponsor this event and we're anxious to see the applications that will be created and what kind of impact they have. You can help by adding your own ideas for applications, commenting and voting on existing ideas, or by sponsoring the event!

• Read more about Tickets, Milestones, and Estimates, Oh My: Choose the Right Tool For You

If you think a trip to the grocery store is a pain to plan for, welcome to project management! A web (or mobile) application can easily span 3-8 developers and designers, gestate over 3-6 months, and have just short of, oh... 501,478 minute details.

Intrepid PM's know: you need a system.

Online solutions like Unfuddle and Basecamp let you wrangle those tickets and to-do's into neat piles that your team can tackle with laser-focused, methodical precision. [You're preaching to the choir here. Jump me to the good stuff.]

But why?

There are many reasons why perfectly successful managers think they don't need a project management tool: too expensive, hard to set up, difficult to get a team on board, don't need it.

Let's get those out of the way now, shall we?:

• Cost: All of the tools below have a free or "freemium" model. For example, Unfuddle is free for teams under 3 people.
• Set Up: All content is accessible via straightforward web interfaces. Start with a few tasks, then expand.
• Team Buy-in: Once your team knows where to find tasks and project information, they'll be glad they don't have to wait around for you to answer.
• "But I'm awesome:" Let's assume you're a robot. Even if that were true, it would still take serious CPU cycles to repeatedly recall these details every time someone asks "what next?". Rely on a tool to remember it for you.

I present to you a throwdown an infographic:

I've used all of the following on at least one project that survived its way to production: Google Spreadsheet/Google Doc, Basecamp, Pivotal Tracker, and Unfuddle. Rather than pit them against each other, I like to think of them as different overcoats that you fill into depending on the unique temperament of your project:

• Team make-up: Are you working with engineers, designers, marketers? Clients? Are they comfortable online? If the idea of online-banking makes them cringe, go easy.
• Complexity: Are you fronting a few content pages, or are you building the next global-domination social networking site with searchable video and artificial intelligence? I'm kidding. Of course you are.
• Team size: Bigger teams need bigger spaces. With simpler tools, you'll end up crashing into each other during day-to-day use.

Just tell me what I should use already!

We here at Intridea like to use Unfuddle for the majority of our projects, but by no means is it the ideal solution for all projects. Let's look a bit more at the tools above, going from simplest to full-featured:

Google Spreadsheet: Do you need to collaborate closely with a client? Avoid bogging them down with overly technical details and code commits. Especially in the "crunch time" right before a project launch, a familiar spreadsheet might be more appropriate.

• Pros: Familiar, easy to learn. Real-time collaboration.
• Cons: Limited functionality and content types. Unwieldy.
• Good for: "Crunch mode." Sharing real-time status with clients.

Basecamp: Are you starting a small project with just a handful of core features? You'll benefit from the simple to-do lists that tools like Basecamp offer. Threaded messages are helpful for teams still in heavy brainstorm mode (get these discussions out of the inbox!).

• Pros: Intuitive interface. Good for discussions. Integration with Backpack, Campfire, HighRise.
• Cons: Limited; not meant for bug tracking or user stories.
• Good for: Small sites, non-profits, early discovery phases.

Pivotal Tracker: If your team is mostly engineers trying to Get Things Done, Pivotal Tracker might be the right fit. Its best feature is "velocity," a magic calculation to surface tasks that will make the most efficient use of your team's time based on past performance. It helps to be familiar with agile methodologies, since you'll have to estimate each task using story points for this to work.

• Pros: Quick drag ‘n drop interface. Intelligence (i.e. "velocity").
• Cons: Doesn’t allow for a lot of description. No real milestones.
• Good for: Engineers, small or unvaried teams, few decision makers.

Unfuddle: Unfuddle has a lot of great features, but three in particular make it our tool of choice for medium-to-large projects with any team bigger than one: automatic ticket resolution from code commits, full-fledged ticketing system, and milestones to group tickets together.

• Pros: Friendly for teams with varied roles. Integrated with code repository. Fine access permissions.
• Cons: Overkill for small projects. Slow load times.
• Good for: Team of 2+, especially if your project is well defined.

More on Unfuddle next week in this series, including: how to trick out your setup for maximum productivity and agile practices. Be sure to tell us what you use in the comments below!

• Read more about Supporting a Bright Future in Design at FOWD

In just a few weeks, our design team, led by Jurgen Altziebler, our Managing Director of UX, will descend upon Manhattan for three days of intelligent discourse on the future of web (and mobile) design at this year's highly anticipated Future of Web Design (FOWD) event.

We are sponsoring this remarkable event which brings over 500 talented designers together for intimate sessions on the most current topics in web design. Top industry experts will be flown in to lead two days of informative sessions in which attendees will learn about the future of everything from HTML5, CSS3, Compass, Sass, Mobile UX, iOS design, Haml, responsive web design, content management systems, branding, animations, and JavaScript, which will be followed by a day of in-depth workshops.

We're looking forward to connecting with other designers who are interested in the future of this industry and to supporting a future of good design. Be sure to say hello to our team who will be available all three days to share their knowledge and insight gained from designing web and mobile applications for lean startups, enterprise giants, and everyone in between. Follow us on Twitter for updates and announcements leading up to the event. We'll see you in the Future!

• Read more about UX For Suits

This article focuses on the correlation of UX and brand equity to quantitative measures that we see in market value.

User experience (UX) is a catch-all term that we use in the software industry to describe the overall feeling an end-user gets when using a product. The UX is the attitude that is triggered when using (and subsequently thinking about) a company and their products and services. Since your user's attitude affects their future behavior toward your brand or product, a good user experience is vital to product adoption, engagement and loyalty.

We all enjoy using a product that has been well-designed. But does the design of a product have any impact on stock prices? If it does, would that encourage Product Managers to allocate more resources to UX?

The Stats

In a 2004 study on "The Impact of Design on Stock Market Performance", the Design Council identified 63 companies to be effective users of design and analyzed the performance of them with the other UK FTSE quoted companies over a ten year period. They reported:

The key finding of the study is that a group of 63 companies identified to be effective users of design outperformed the FTSE 100 index over the full period by 200%, and also beat their peers in the recent bull and bear markets.

A number of prior studies have been undertaken around the world but all have been limited in their methodology or scale (see Appendix 1). We believe that this study offers the first conclusive evidence for the relationship between the effective use of design by corporates and an improved share price performance and therefore greater shareholder returns.

In 2006, a design group put together the UX Fund, an experiment to test whether companies that provide good UX see it reflected in their stock prices. They invested close to $50k in companies that had a history of innovation, had loyal customers, and that took care in designing their websites, products and user experience. The results? A year later the UX Fund matured a whopping 39.3% and the companies they invested in often outperformed their closest competitors.

Examples

Despite the (small, but increasing) research linking good design to stock values and despite the vital role UX plays in brand adoption and loyalty, investors and key decision makers of publicly traded companies rarely take UX into account when determining what drives their brand's market value. While a company's stock price is affected by an infinite number of forces, value can be closely related to the overall experience their users and customers derive.

We can spot trends and wild fluctuations in performance between companies that exist in the same market and create similar products but have widely differing approaches to UX/UI. Apple and Microsoft are a perfect (if not entirely overused) example. Apple's users (and even many of Apple's critics) tout that Apple products are better designed and engineered than Microsoft’s counterparts. If you have watched Objectified you know how serious Apple considers the user experience when designing a product. Apple users prefer the way they feel (and look) when using Apple products. The innovative simplicity of the UI creates a satisfying user experience.

Steve Jobs took design more seriously than most of his contemporaries, and saw it as much more than just the final layer over a product:

In most people's vocabularies, design means veneer. It's interior decorating. It's the fabric of the curtains of the sofa. But to me, nothing could be further from the meaning of design. Design is the fundamental soul of a human-made creation that ends up expressing itself in successive outer layers of the product or service. Steve Jobs

The subjective divide in UX between Apple and Microsoft brands can be quantitatively measured in market value; Microsoft’s stock has remained nearly stagnant over the past 10 years, fluctuating between $20-40 per share (despite new product releases and acquisitions), while Apple’s has grown over 3000%.

Myspace is an example of how bad UX can lead to major losses. In a recent UX Magazine article, "Myspace's UX-Induced Death", the author discusses all the ways in which Myspace failed to engage and ultimately retain their users. Many of Myspace's users were initially pleased with the unique customization features of the app, but it was that level of customization that eventually led Myspace to the grave. As Myspace's users grew up and as other companies created the future of usability, Myspace stayed the same. Many of Myspace's users desperately wanted the service to succeed and lingered, hopeful for years that the company would find its way.

News Corp stock only rose 1% over the 6 years they owned MySpace. Compare that with Facebook’s estimated valuation over the same time frame, and you can see that Facebook (with its relentless focus on the user interface) rose upwards of 5000%.

Where Do All The UX Resources Go? To The Creep!

Feature creep, that is. In an article from UXMatters, Ben Werner identifies a common reason many Product Managers overlook UX, and it's not because they don't appreciate good UX - it's because they are won over by the allure of feature creep:

Competent management does realize that the user experience is critical to the long-term health of their company. Unfortunately, when developing software, the temptation to steal from the feature-list cookie jar and try to squeeze just one more feature into the current development cycle by skipping UX work is simply too great for most Product Managers.

He goes on to suggest that the best way to advocate for UX resources is to speak the language of the Product Managers - bring it back to dollars - and outlines a process for measuring the value of UX.

Most Brand Managers do recognize the value of UX. But allocating resources to UX within the complex decision matrix often gets overlooked. Although extra features might score the company more profit in the short-game, a better UX will score more in the long-game.

Bottom Line

So here's the bottom line: brand equity and user experience is measurable in some fashion. In light of how users respond to products based on their user experience, it would make sense to assess feedback about a product's usability and user loyalty right next to quarterly reports as indicators on whether or not to pull the trigger on buying stock. For those investors looking for long term gains, the overall success and temperature of public opinion on the company is key in order to see sustained success - and public opinion is derived, in large part, from the collective user experience.

If you care about how your users perceive your product, your brand, or your application, and if you understand the financial implications of what happens when users do (and do not) perceive it in a good light, then you need to care about UX. Good design isn't just a thin layer over your product; in fact, it's not a separate element at all. Rather, it's woven into every feature, felt in every interaction, and engages the user to the point where they forget about the design altogether, freeing them to just use the application to its potential.

If you don't believe me, then perhaps you can believe Google. Google was one of the first companies to vocally advocate for the user experience above all else, and it has worked out pretty well for them. From their "Ten things we know to be true" list they cite the user experience as the #1 priority:

1. Focus on the user and all else will follow.

Since the beginning, we’ve focused on providing the best user experience possible.

Google's Philosophy