Skip to main content

Mobomo webinars-now on demand! | learn more.

As part of my work, I often create prototypes of Rails applications. My preferred tool for doing this is Serve. But as excellent as it is, it's a very thin application with no persistence layer. To be honest, I don't really want a persistence layer at this stage. But there are times when I want to be able to iterate over collections of objects the same way that I would in a Rails environment. Creating an index view of subscribers is a great example.

Now, I could just draft this all as html:

...but that's time consuming. Especially if you have more than a few. Sometimes you want to stress test a larger data set (to show pagination, for example, or to work out JavaScript performance on larger data sets) or just give a better match to real data.

To accomplish this, I use the Storable and Faker gems.

Enter Storable

Serve provides a views/view_helpers.rb file, which is where I will store my ruby code. Since Storable can read YAML files (and because I do often use fixture data in real Rails apps), I use YAML as my data store.

Let's set up the data store first, using a Subscriber model. You can go about this one of two ways:

  1. build your models by hand (the same way you would create fixtures for RSpec), or
  2. randomly generate a set number of models.

You should choose your approach based on what your end goal is; since I'm just trying to quickly populate a lot of data, I'll go with some random generation.

Enter Faker

The ERB loop uses the Faker gem to create a first and last name, which it then uses to create the object's key and describe the object's attributes. This setup will create 10 of these objects. I could even use this later to seed fixture data for tests; in that case, I'd define those objects manually.

Now that we have the data store in place, let's do something with it: create some ruby objects:

This creates a class that we can marshal our data in to, enabling us to create our collection. The field definitions default to being Strings, but (as you can see with :id) you can specify a type using Ruby's hash syntax.

Massage that fake data!

I've also added a full_name method to the class, since I know that I'll want to display a Subscriber's full name in the "first_name last_name" pattern. You can define any number of methods that you want here.

Next is a self.bootstrap method, which accepts a file path as a parameter. This reads in the specified YAML file, processing it through ERB (the load command with the ERB wrapper can be replaced by load_file if you're just using straight YAML), and then creates a new Subscriber instance for each object defined in the YAML file.

Finally, there's the self.all method, which similarly to the Active Record finder method of the same name, without the database call. It will search the active Ruby object space and return all of the objects of the Subscriber class.

This implementation of #all is a bit crude, but it works.

Voila

With all of that taken care of now, we can finally get back to our view and do this:

...which is much easier to maintain, especially if that bit of HTML code is rapidly changing. Storing the data in the YAML file (especially inside of a loop), means that adding/removing/modifying the object's attributes is much easier to do as well, and with a lot less typing.

Categories
Author

Last April we sponsored the first MoDevUX event in Washington DC and helped facilitate some important conversations about user experience design and application development with hundreds of industry experts.

We had the opportunity to take the stage to share some of our insight gained from developing beautiful, modern mobile applications over the years. Our presentation garnered a lot of feedback and even landed us a story in InTheCapital, DC's leading online news source for tech and startups.

We're pleased to report MoDev is back in action this September with another mobile-themed conference, MoDevTablet; this round they will focus specifically on keeping pace in the tablet era.

We're excited to sponsor MoDevTablet alongside giants like Adobe, BlackBerry and Microsoft. The conference offers more than 60 workshops and presentations over three days from September 13th-15th.

Once again, Jurgen Altziebler, our Managing Director of UX, and Anthony Nystrom, a Fellow at Intridea as well as our Director of Mobile and Emerging Technology, will take the stage. This time they'll be presenting "Tablet as a Utility", and will share case studies on developing tablet applications for real world, utilitarian cases where the functionality and design of the app has to enable someone to do their job more effectively. They will cover questions like:

  • How does the design of these apps differ from the design of novelty tablet applications?
  • What special cases do you need to take into consideration?
  • How to keep tablet in use without Wifi?
  • How to accommodate for working conditions like changes in light, differences in fingernails, and extended use?

We hope you'll join us for this exciting event in DC next week! Registration is still open. Several Intrideans will be there along with Jurgen and Anthony, so it will be a great time to pick our brains about your design and development strategy. Be sure to follow us on Twitter for updates throughout the event.

Categories
Author

Creating a more beautiful web, one application at a time.

Our website has always been more than just a sales tool for displaying our services. As a web development and design company our website is our brand; it embodies the essence of who we are: our values, our culture, and our discipline.

We don't take a redesign lightly; when we approach the task of a redesign we begin with long, thoughtful discussions about our company, our image, where we're going, and what we want to communicate about ourselves to the rest of the world. Our website has to exemplify our passion for elegant and functional design, quality code, collaborative work, and our obsession with emerging technologies.

For this redesign we sat down and had conversations with Intrideans where we asked questions like, "What is Intridea to you?" and "What do you love about this company?" and "What do you want to see more of on our website?". We reflected on their responses and went to the design team with pages of documentation including feedback on our culture, our path, and our history.

The new website was designed and developed with all of this in mind. They worked to ensure everything that we love about our company is reflected in the layout and design elements. We added some really great new features we're really excited about:

  • You'll find a new Community Section that highlights all the events we're sponsoring, speaking, and training at, a collection of our open source projects, slides to all of our presentations, and links to our most frequently trafficked blog posts for quick and easy reference.
  • We revamped our Portfolio Section with more in-depth case studies and illustrative examples of our work and added recent clients like Amazon, SocialCode, and Oracle.
  • We used responsive design techniques to ensure our website looks good no matter what kind of device or screen size you're using to look at it.
  • New About and team member pages that do a better job of showing you the kind of geniuses we have on the Intridea team.

For a more in-depth look at how we designed the new intridea.com I interviewed , the lead designer on the project and Andy Wang, the lead developer on the project.

Design

Renae: What did you draw inspiration from in the new intridea.com design?

Chris: Grid systems (960), traditional graphic design principles, modularity, timelessness, and simplicity. The new design had to maintain the Intridea image we've created over the last five years while redefining who we are and what we do to help us move forward.

Renae: What elements from the previous site did you want to preserve?

Chris: We held stakeholder interviews with our company founders and other Intrideans to get input on how they see Intridea as a company. The consensus was Intridea is an approachable, friendly, professional company that offers its employees an opportunity to do great things without feeling like they're in some sort of software grind-house. We sought to maintain that feeling and felt Intrideans, new clients, and visitors to the site should feel welcome and excited about us. We worked to make sure the new design helped evoke that kind of excitement.

Finding a way to incorporate the previous branding into a new aesthetic was a real challenge at first as I immediately wanted to scrap our previous designs and start fresh. Yet, after several initial comps I realized helping our brand to "grow up" didn't mean I needed to start from scratch.

So we scrubbed the site down and gave it a fresh coat of paint and detailed the hell out of it. I realized that our branding elements, the hills, people, etc, could be used to create delight in the design which is always fun. Take a look at our 5th anniversary image on the homepage for example - I created a person for everyone in the company. We preserved quite a bit of the site actually; the structure is pretty similar and elements of our original branding found their way in there without being the focal point.

Renae: How do you want people to feel when they see the site?

Chris: To feel they're experiencing something new and exciting. This is a totally different experience from what we've presented in that past. The content has been overhauled, there's a lot more focus on what we do and how we do it, our community image is strong and vibrant, and there's a focus on us - the people who work here, and that didn't really exist in the previous design. What we're really trying to communicate in the design is that we're a company of ridiculously talented and creative designers and developers who love working hard and solving problems.

The redesign gave us an opportunity to really show others that we're different from our competitors - we're not gimmicky, we're not trying to hide anything, we're just giving everyone a very clear picture of who we are. That's why I wanted the design to have a lightness to it; I think it gives a surprising sense of ease.

The recent trend is to use elements of minimalist, Swedish-inspired design but we wanted to show you can use interesting and playful design elements and still be serious and professional at the same time.

Renae: What were some of the challenges you encountered in the design process?

Chris: We do an incredible amount of things; yes, we make software but we also write, participate in conferences, teach others, make products, contribute to open source projects, support user groups, and help clients solve all sorts of interesting problems. I needed to find a way to make all of that information consumable.

In order to communicate everything we wanted through an elegant user experience we used a rigid grid system to control the abundance of information. We cover a lot of ground in small, modular bits. The hardest challenged though was in designing unique views for all the different breakpoints:

  • Almost every section of the site has a unique view leading to 14 different layouts.
  • We opted for 4 different breakpoints in our responsive design - 1280, 1024, 768, and 480.
  • Each of the 14 layouts had to be adjusted to meet the needs of each breakpoint resulting in a total 56 templates.

I'm really psyched about the new website. Consistently, clients have said our “friendliness” is what made the difference when it came to choosing a new technology partner. I think we've struck a nice balance in maintaining our friendly image while at the same time showing how serious we are about our work.

Development

Renae: Talk about your decision to start with a new, fresh codebase.

Andy: The old codebase for the site still had elements from the original version in 2007. Although we had been adding features and updating the codebase over the years it was time to scrap the old code and start anew. I built it with Rails 3.2.3 and that made adding new features a lot easier throughout the development cycle. It also puts in a better position to scale and improve the site in the future.

Renae: What were some of the challenges you encountered?

Andy: I only encountered two challenges on this project. The first was adjusting responsive views and tweaking Javascript effects; those cost me some time. All the front-end improvements and enhancements were challenges to a pure Rails engineer like me. But on the upside I became a front-end skills lover from this project!

The second, larger challenge was transferring all the old data from S3, including thousands of blog posts, products, projects and all related images and assets. I decided to move the old S3 repos to new folders and wrote a script to migrate all useful data from the old database for my local environment and then push my local database to our staging environment on Heroku. After that everyone was able to share the REAL data.

Renae: Did you learn anything new as you worked on this project?

Andy: Sure, I learned the skills to build responsive views for multiple browsers/devices. It’s really cool to build a website which is responsive to many devices at the same time.

I also learned how to use Pjax with Rails. A good lesson from Pjax is that if you have some other Javascript in the Pjax content you want to make sure you run the regarding Javascript in Pjax callback.

Using rails_admin saved us a lot time in building the admin sections and features. I think it’s great to use rails_admin for a pure CMS. Sometimes rails_admin doesn’t work well for complex admin logic or complicated admin actions, but it’s good for classic CRUD actions.

I also added integration testing for the contact form to make sure the form is always working correctly with Javascript validations.

Renae: What aspect of the code/architecture are you most proud of?

Andy: I'm really proud of several things:

  • On the Rails controller level I mapped all same categories of pages to a sample controller and this helps UX and UI designers to integrate their designs and markup quickly.
  • I made it easy to read the website structure based on the code base.
  • Abstracted business logic with simple models and just display whatever make sense to Content Manager from the backend.
  • Customizing rails_admin for multiple photo management with associations.
  • Adding Pjax and other Javascript effects, such as the blog pagination with two modes and contact form validations.
  • Responsive views control and adjustments.

Renae: How do you feel this site represents Intridea?

Andy: From a developer's perspective the new site represents us really well. First, it's awesome! Second, the new site uses many technologies such a responsive views, HTML5, the latest Rails, Pjax, OmniAuth, and rails_admin - and Intrideans love using new technologies in their projects!

In Short

TLDR: we've got a shiny new website. It's made from the dust of unicorn bones and infused with the spirit of a thousand minotaurs. It's simplistic beauty and hardcore function all rolled into one; it's the new intridea.com. We hope you'll enjoy it as much as we do.

Categories
Author

Jurgen and Anthony poke fun of the stylus tool and talk about fostering happy development teams in this exclusive interview at MoDevUX.



The short, 5 minute video gives a glimpse into how we work at Intridea and ends with some amusing banter on the state of touchscreens and the lingering use of the stylus.

Of note, Anthony explains how giving developers time to work on personal projects supports the company in more ways than one:

  • Allows our developers an opportunity to build up a library of open source work.
  • Many projects we do for our clients are massive in scope and individual developers don't always feel a sense of ownership or completion as frequently as they might like. Anthony explains, "Everyone in the organization needs to experience that level of execution." Encouraging developers to work on personal projects gives them more opportunities to feel that sense of ownership and completion. This philosophy is "always a positive outcome and never a waste of time", Anthony says.
  • It's training - developers learn new technologies to use in their projects. The knowledge they gain is put to use on client projects and spread to other developers, keeping all of us agile and bleeding-edge.

To see the full interview (and find out why we think the stylus is so "1999") watch the video and let us know what you think in the comments below or through Twitter! And be sure to check out the other interviews from the MoDevUX event on their YouTube channel.

Categories
Author

Last week we sponsored MoDevUX, a mobile conference in Washington, D.C. led by vanguards in the mobile development and design industry. In addition to learning about emerging trends from the diverse crowd of presenters and attendees we also shared a bit of our own "secret sauce".

Anthony Nystrom, our Director of Mobile and Emerging Technologies, shared the stage with Jurgen Altziebler, our Managing Director of UX to tackle the topic of "Development and Design: When the Two Must Act As One".

Through cultivating a culture of quality in both design and development we've gained insights on the formula for success among teams of developers and designers. MoDevUX was an opportunity for us to share those insights with the greater mobile design and development communities.

Designoper, Developer or Designer, the point is that recognizing each other's skills while sharpening your select personal skills is what a team is built upon. Certainly there are stars, however stars don't scale but teams most certainly do! And like any business that is looking to grow, it must rely upon teams that are less interested in their personal prowess and more interested in their unified presence.

Great Products: Under the Hood

If you're building a product you already know that it's important to know your industry, understand your users, define a clear vision and path of execution, and to be bold in your approach. But what role does your team of developers and designers play in the overall viability of your product?

We believe the DNA of any mobile or web product is embedded in the team(s) that are executing on the vision. Ultimately, every product is really just someone's good idea made accessible by teams of programmers and designers. Therefore, the most important factor in the success of your product is the team of experts building it. At Intridea we've been honing the process of creating these teams for years, and with great success! We do it in large part by making sure our teams of developers and designers are working together, not autonomously.

Building a Design & Development Team

Often, design teams work in isolation from development teams and in many cases design is outsourced to other agencies while development is done in-house or vice versa. But there's no doubt about it, a great product experience is the direct result of a good working relationship between the teams building the functionality (the developers) and the teams creating the aesthetic experience on top of that core functionality (the designers).

Of course, simply knowing that designers and developers should work hand-in-hand doesn't mean it's going to be easy. After all, designers and developers are different breeds and both groups work in distinctly mysterious ways. The trick to building solidarity in a product team is to hire the right kind of people in the first place.

While you might be inclined to seek out "rockstars" for your team, keep in mind that superheroes get bored easily, they're hard to find, and they don't scale. We have found that it's more advantageous to focus on hiring specialists who meet these requirements:

  • Have the skills (and attention span) to see a project all the way through (even that last 10%)
  • Are great at a couple of core things but are eager to learn beyond the bounds of their specialty (i.e., beware of "backend" developers who refuse to do "frontend" work)
  • Leave evangelism to theocrats: you want people who aren't afraid to use different technologies (whether they're cutting-edge technologies or older technologies that just happen to be the right tool for the job). Find people who love the challenge of creating something incredible regardless of the tools and processes used to get there.
  • Value form as much as function. It's important to see the inherent value in both a well-architected application and an easy-to-use, beautiful user interface.

In a symbiotic designer/developer relationship, both sides will, at some point, be faced with setting aside ingrained methodologies in order to collaborate effectively. What's actually happening in those cases is something like this: designers are learning something new about practice patterns in development, and developers are learning something new about user flow and experience from designers. When designers and developers work together in such a way, both teams gain something and will be more agile, productive and innovative on future projects.

Setting the Team Up For Success

Managing a product team is generally no easy task. Ask the design team to work in collusion with the programmers and it's sure to get even more challenging. Jurgen shared his strategy for creating a "balanced" team and setting them up for success on any project.

  • Team Building: This is an important first step. Assign an internal project (maybe a redesign of your company's website) to a developer and a designer. In this situation they will have to manage the project together, understand how the other one works, communicate in-depth about scope, features, and blockers on the project, and deliver a finished product.
  • Field Testing: Once you've ensured that the designer and developer can work together, pair them on a mid-sized client project. This adds a bit of necessary pressure because client deadlines are often more strenuous than internal deadlines. Additionally, a client project will introduce more variables for both sides. They'll have to think about things like client expectations, changes in scope and direction for both UI and architecture, and more.
  • Heavy Lifting: Now your designer and developer are battle-hardened and ready to lead the troops. Appoint this dev/design duo as the lead for larger projects that have multiple designers and developers. Their experience will aid them in helping other designers and developers work together, maximizing the results of the process.

But I Just Want A Good Product That Will Be Profitable

You have an idea. You need a product built. It sounds easy enough. Do you really need to spend all this time thoughtfully building the team behind the product?

In short, yes. Great products fail all the time; and not because there wasn't a good idea behind it. They fail because the teams building the products couldn't meet at that magic place - the precipice of awesome. (No, really - amazing things happen when designers and developers work together closely!)

Keep in mind, there isn't a lot of room for failure, especially in the mobile app market where users are educated and discerning and the competition is cutthroat. It's not even that users are "demanding" sexy interfaces and well-built applications - we're beyond that. Today, users just expect it. And if your product doesn't meet expectations your users won't even complain about it - they'll simply move on to another application that does it better.

These are problems that you rarely see when you have a team of designers and developers working closely on a product because simple issues like awkward user flow, unintended behavior within the interface, and architecture miscalculations are caught more frequently and earlier on in the process.

The Secret is in the Sauce

So there you have it - a sampling of our "secret sauce". TLDR: Hire smart people who value quality and aren't afraid to cross the "party lines".

Be sure to go through the complete slide deck from our presentation at MoDevUX, and check out our portfolio where you'll get to see some great examples of recent products and solutions built by our teams of designers and developers! Additionally, the full set of photos from the event is available on our Flickr page.

Do you have insights on helping designers and developers work together on projects? We'd love to hear it. Did you see our presentation at MoDevUX? We want to know what you thought. Leave your feedback below or reach out to us on Twitter.

Categories
Author

Ted O'Meara departs today for Salt Lake City, Utah where he'll spend the next few days immersed in the ever-evolving community of Ruby and Ruby on Rails developers. He's headed for destination: MountainWest RubyConf.

Ted came to Intridea two years ago as a designer and in just a short time he's proven to be a dextrous and pioneering leader. Not only has he become an accomplished project manager, he also plunged into the development world in an effort to become a more knowledgable and powerful designer. He did it. He crossed the streams.

While total protonic reversal was not a direct consequence of Ted's actions, he did actually learn a thing or two about the gaps between developers and designers and how small divergences in processes between the two groups effects the products they build. He'll be sharing his insights and solutions at MWRC this Friday.

In his talk, "UXDD (User Experience Driven Development): Build for your users, not your tests", Ted will propose practical and technological solutions to ways developers can increase the overall quality of their applications by aligning and testing their work against the user interface and flow.

In a candid example of why this is important, Ted posits the following user story:

Given that John has 30 pies
When he eats 3 of them a day
And he eats them for 10 days
Then he should not be hungry

And then adds "...but he might have gained 50lbs."

Throughout a project's lifecycle there may be several additions or changes to the overall user flow and back-end architecture. Following the principles of test-driven and behavior-driven development head-down might cause you to miss glaring errors in functionality for the user. So go see Ted's presentation this Friday at 4:30 pm for a Complete and Perfect Solution™ - he'll fix all your problems, ever. Just don't tell him I said so.

Categories
Author

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.”

Categories
Author

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!

Categories
Author

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

Categories
Author

Demosphere, a leading provider of web-based administrative tools for youth sports organizations approached our mobile development team to help give their users mobile accessibility. For some time, they have provided an IVR interface to youth sports organizations to phone in results of soccer matches via cell phone voice commands. Demosphere wanted to break into the mobile app space because they knew that's where their users were; so, they asked us to assist with creating custom mobile applications for Android and iOS devices.

One of the primary directives was to give the mobile apps functionality and aesthetics similar to the system Demosphere users were already accustomed to. Our team worked closely with Demosphere to define a look and feel that would mimic the experience offered by the already popular voice system. We were able to utilize the structured interactions of that system to quickly and elegantly develop an Android and iOS solution that provided the same login and interaction system as the voice interface, coupled with a familiar and stylized input system.

The UX team worked directly with the client to create blueprint documents that covered the use cases and interactions that would be most straightforward for their users. Following that phase, they worked with their marketing department to define a UI that was on target with their brand.

In working with our vision for the user experience, German and Yincan engineered the development of the Android and iOS applications.

We employed a Kanban agile process for design and development; this lean development practice allowed us to consistently deliver in-process working versions of the applications and adjust to Demosphere's feedback as we developed. Following a few short weeks of development, Demosphere recently announced PhoneItIn for Android and iPhone.

PhoneItIn™ is Demosphere's revolutionary score reporting system. Rather than reporting scores in front of a computer, you can now report scores on the go from your mobile device. For those with iPhone or Android devices, a free app allows easy score reporting with no phone call required!

Ashley Ralph, Demosphere Blog

The whole process went smoothly thanks to utilizing web-born development practices and a tight feedback loop. Congratulations to the Demosphere team on penetrating the mobile app market!

Categories
Author
Subscribe to Development