How can Eventbrite be a better service

"That is far too complicated!" Groaned the managing director at the flagship of his company, an application with which they had generated 80% of their sales - until a competitor came up with an easier-to-use variant and that changed.

“I don't know how it got this far,” he continued, “but now we have so many features that I don't even know how to do anything. I wrote the first version myself. The next release HAS to be easier. "

The managing director may not know how his cash cow got so complicated - but we do. The market maturity model explains this development.

What happened before

As I explained in the first part, it has been shown that we are dealing with four stages of market maturity. Every market for a certain product obviously goes through these four stages, and with it every successful (web) application, some faster, some slower.

This process starts at the technology stage, where customers don't really care how easy a product is to use. They are only interested in the product being able to do something new. If the potential is big enough, they pay for training measures without even blinking an eye in order to bring their people closer to even the most complicated interface.

However, if a competitor enters the scene, this heralds the stage of the features. This is where the race for the development of new and better features begins with the competition, which in turn is working on additional functions to enhance their application. The focus is on functionalities and short reaction times are important, because corresponding requests and inquiries come from all directions.

If a product is useful, it will win customers' favor. Once that happens, competitors will want a piece of the pie and offer products with alternative, additional capabilities. This is what drives the market leader to add further features and to push the product far beyond the original version

Stage 3: Focus on the user experience

There is a certain irony in this: if a company gains market leadership, it is forced to destroy its own model of success, so to speak. To remain competitive, the company must respond to market needs, quickly and immediately. With each reaction, the product moves further away from the original - whose simplicity may just have made it so successful.

The transition to the user experience stage is quickly identified: customers stop being interested in additional features and start asking for simplicity. Enterprise customers are concerned about the cost of training new users to use the application. They complain that they pay for features that nobody uses. They want something to do their work with, without the theater of all the extra functionality.

The folks at the weather site have added features regardless of loss. should provide the most complete service and really cover anything weather-related. The result is a whole jungle of functionalities.

The sitemap

But as a rule, the visitor to a weather site is looking for nothing more than a simple weather forecast. This is where comes in: go to the page and fill in your address; The answer is a big yes or no, depending on whether you need an umbrella or not, according to the forecast. No ifs and buts.

The homepage

Well, that's an extreme case of simplification, but it gets to the point: At this stage, customers are fed up with bloated applications, it becomes more and more difficult to justify the need for upgrades, and the benefits of new versions are barely revealed.

Third stage development: untangling the bulge

Preparations for the user experience stage should begin while those involved are still focused on the features. In particular, the really useful functionalities must be identified and those that may only exist for their own sake. This requires reliable knowledge of why users use an application and what they want to achieve with it.

The advancing competitor has an easier time than the market leader at this stage. He can work diligently on the functionality that makes the user experience perfect.

For the market leader, on the other hand, the situation is more complicated. If those responsible realize that the complexity of their application has led to a loss of market share, the game is lost. You need to have a suitable strategy in the drawer beforehand.

The problem is the gigantic mass of functionalities that they have gradually woven together. And simplifying an application requires more than just making complex functionality look superficially simple. It is important to fundamentally rethink workflows and untangle the optional jumble of functions.

In the user experience stage, the flagships of usability research are booming and have a high return on investment: Personas, the scenario method, high-frequency prototyping and components make work significantly easier. It is important to develop a viable vision of the future user experience and let the many players run in a common direction.

The optimal starting point for additional user research is the out-of-the-box experience: If we observe users during the very first experiences they have with the software, we are impressively demonstrated what works well and what does not at all in a dramatic way and on all levels.

Stage 4: Support mass deployment

At the mass deployment stage, the things that we have developed are tied into unfamiliar environments. Former stand-alone applications - maps, text tools, calendar functions or purchasing management - are integrated components in other applications.

At this stage, the customer's focus shifts again. It is no longer the end user who decides whose components he uses, but the integrator. Programming interfaces and customization options are now more important than the individual functions themselves.

Development in the fourth stage: learning to integrate

The people at are faced with a challenge: You want your event booking service to seamlessly integrate with the presentations of the events they are supporting. It quickly turns out that this is more difficult than initially assumed.

For example, when the popular organization for military enthusiasts and gun freaks, Appleseed Project, announces one of their boot camp weekends, they need to offer their customers an easy way to register. They do this through Eventbrite's registration and payment system.

The scheduling on

The Appleseed page for the corresponding event has a characteristic appearance: It fits in with the rest of the website, has the same color scheme, the same layout grid, the same typography. Whether you like it or not - the design is definitely striking.

The Appleseed registration on

Clicking the register link for a special boot camp weekend brings us to the Eventbrite registration page. Again, it's neatly and consistently embedded in the Eventbrite website, but it's radically different from the Appleseed design. So there is a very unsightly cut here that can cause confusion on all sorts of levels.

At this stage, the point is to say goodbye to the distinctive look-and-feel of a stand-alone application. Most importantly, design teams need to understand how the integrator intends to embed elements. You have to find out where customer-specific adjustments are necessary and what must not be changed in order not to endanger functionality.

The biggest hurdles are to understand the user experience when working with the programming interface and other protocols and to ensure seamless transitions to all environments in which the design is integrated.

Know the current stage

In our experience, a key success factor is knowing what stage an application is at and what is needed to move it to the next stage. The best teams build applications that match the market maturity and know that things are about to change.

This article was originally published on August 19, 2009 under the title “Deriving Design Strategy from Market Maturity, Part 2” by Jared M. Spool. Jared M. Spool is one of the leading usability experts of our time. You can access his website at You can find more articles by Jared M. Spool in the Usability Special from // SEIBERT / MEDIA.

ConsultingJared SpoolPersonasSoftware DevelopmentUsabilityUser-Test