The purpose of this issue is to identify the strategy we want to pursue for Drupal commerce, this summary will be kept up to date. Most of this is derived from talking to rszrama and others.

Overall UX Strategy

Drupal commerce is a technology product, it fills the need for a opensource e-commerce system that offers great flexibility and extensibility. It provides a base system on which shops can be build, extended by a great diversity of functionality contributed by it's opensource community.

We optimize the experience of creation and maintenance of medium to large sized webshops. The knowledge of our audience varies greatly, from shop administrators to senior developers - all for which parts of the interface need to be optimized.


  • Confident, developers feel confident the webshop will function appropriately
  • In control, shop administrator feel in control and are able to use the system effectively
  • Sales driven, businesses can optimize sales, by quickly leveraging new technologies and insights
  • Clean, the visual style is feels slim, in the background
  • Consistent, your using one application, with standardized patterns

We are not pursuing the user experience for setting up small webshops (e.g. Cafepress and Shopify). We will differentiate ourselves from competitors such as Magento and osCommerce, by providing a better ecosystem of functionality - where the Drupal commerce core is small and flexible and extended by modules for specific usecases, instead of providing a full "can do anything" solution.


  • Shop administrator
    The primary person who will be using the interface, after the webshop is build. Won't be familiar with the way that Drupal or Drupal Commerce does things, and wants to perform tasks like viewing a specific order, analyzing the sales and adding new products. The system needs to be very effective and efficient, in helping them perform their day-to-day task.

  • Developers
    Developers will use the interface when constructing the webshop. They will primarily be active in the configure parts of the interface, for example product types, rule configurations, cart settings and customer profile types.
  • Site-builders
    This is someone who is for example using Drupal commerce to build a webshop for the local theater, someone who can't really be identified as a developer and will build the webshop almost entirely using the user interface.

  • Business
    This audience is similar to the shop administrators, they are they are often the ones who make the technology decision to use Drupal Commerce. To them the ability to optimize sales, easy to learn for their administrators and ability to extend is important.


Current state
We are about to finish the first version of Drupal commerce, which will primarily be a development platform. We will do little optimizations in terms of UX. The current user experience is bad, basic tasks such as creating product(s), setting up a payment method and creating a price rule are quite complex and require understanding of the implementation model.

We are competing with strong e-commerce solutions, most notably Magento. Who have mastered the user experience of maintenance, but suffer from bloat due to offering a solution that tries to do everything. Small shop services have far superior user experience, and excel on most basic tasks.

Currently we have little to no resources dedicated to the user experience of the shop administrator or site builder, which will likely mean this is placed on the back-seat until the need for this arrives.

Future goals

  • Create a great site-builder user experience
    Using a installation profile, we wish to give site builders a experience, where they can setup medium sized shops with ease. Complex topics such as bulk-product creation, taxes, customer profiles and store management need to be simplified to fit the needs of this audience.
  • Optimize the shop administrator experience
    By using Drupal commerce on production projects, we can learn how to optimize the shop administrator experience - basic tasks should be optimized after actual usage.
  • Sensible defaults and patterns
    The user experience should be consistent, any module extending Drupal commerce should try to adhere to UI standards and any interface created in Drupal commerce should be easily extend-able for specific use cases.

Required actions
During the sprint in Paris 2011, we decided that given the resources available, 1.0 should focus on just getting the designed interfaces finished. For the 6-month development period of Drupal commerce 2.0, we will focus on the shop administrator experience. We decided this, because its critical to get this experience right to convince business to make the shift, future versions (e.g. 3.0) should focus on the site-builder audience, because this audience is what will get us mass.

In order to optimize the shop administrator experience, we need to gather fundamental insights. Ones that go beyond, feedback from developers. There are many ways to do this, a few suggestions below:

  1. Backlog of user feedback
    As companies develop Drupal commerce webshops, there will be a lot of feedback from shop administrators. Often solutions are made, but there is no feedback towards the actual product. A common practice is creating a log in which feature requests, or changes that are made specifically for an audience (in this case shop administrators) are noted. This means we have a rich backlog of which interfaces need changes, and with several companies involved we can understand the trends and set priorities.
  2. Usability testing
    User feedback from companies will get us filtered feedback. We will still need to gather insights on how people perceive and learn the interface. A great way to do this is by observing them, as they perform a series of tasks. This is also required to optimize specific interactions, how usable they are - and whether we can improve visual affordances and interaction flows.

Installation profiles

We will use installation profiles to reach different types of audiences, all profiles should be under constant development and optimization for the specific audience. We will encourage the creation of development profiles for specific purposes, like multilingual or multi-currency sites.

  • Commerce Base
    The starting point as developer for building a webshop, it will enable standard Drupal commerce modules and serve as a jumping board for creation of other profiles.
  • Commerce Kickstart
    The starting point as site builder for building a webshop. It's user experience will be optimized for this audience, providing modules that make it easier to create products, setup payment methods and administrate the webshop.
  • Commerce Dev
    This profile is for contribution to Drupal Commerce, it will provide a few defaults like enabling a number of Drupal commerce modules, Simpletest, setting up a PHP filter and some dummy content. It will only be promoted in the context of contributing to Drupal Commerce.

Note: This is just a first draft, a lot of this will need measurable indicators - in order to make it a proper strategy. I'd greatly appriciate any feedback, its often harder to think high-level about this, but its crucial given the importance and scarcity of resources in UX.


rszrama’s picture

Some follow-up notes based on my review of this with Bojhan the last night of the sprint:

  1. An elaboration on the "Clean" principle: basically, there is no branding. You look at the interface (primarily the back-end) and don't see "Drupal Commerce", just Drupal. This is one of the things that makes it easy for organizations to adapt DC into their own sites, applications, etc.

    As we're adding to Commerce, we need to be consciously aware that we're not adding any visual elements that are specific to Drupal Commerce. For examples you can consider the icons / custom styling used all throughout Ubercart. (You could argue the blue "Order total / balance" rows floated to the right on line item and transaction tables is a custom visual element, but even then we're using a Seven defined color.)

    In the context of general use, we're saying we don't want to get in the way of the information, just define how it's stored and retrieved.

  2. When you're trying to argue out an issue, the Principles are what you fall back onto.
  3. Regarding audiences, store administrators will be the primary users of the interface. If it isn't good for administrators, the product itself will suffer. If they love it, development shops will feel confident using it for more client sites.
  4. A big selling point to business owners to use the software is its flexibility. They're also interested in analytics, so we should ensure this is represented on the roadmap.
  5. It might be a good strategy for 2.0 to focus on the site-builder or store administrator audience. For the release, we'd want to pick what aspects of DC to optimize, such as the entire Order management process (Views, updates, revisions, payment management, etc.).
  6. Considering site builders / store administrators, there's the question of whether or not product creation needs to be simplified for 2.0. However, it may be that the target market for DC manages external product databases with automated imports / updates. Significant improvements in core may not be necessary.
  7. The issue with shorter release cycles is that people will not update on every release and eventually run so far behind in knowledge will not be able to catch up when it's time to update.
  8. We can only say "this feature or approach" is good if we have tested it with multiple clients. We should keep a backlog of user feature requests and UI feedback from clients. Ideally, this will be an open feedback log that the community builds - what is my client saying about this particular feature or interface? How have I had to customize it for their sites?
rszrama’s picture

Keeping this for future reference:

Basically, it's a current user frustrated by the developer oriented nature of 1.0. His comments provide some great feedback as we consider a store administrator friendly 2.0.

Bojhan’s picture

Priority: Normal » Major
joshmiller’s picture

Just wanted to chime in here about the audiences. I was looking for a nice list of Commerce people and Bojhan provided a fantastic list :) Below are simple embellishments on what was laid out above.

I want to use this list to start working out documentation tasks. This could also be used in working on sales language. Would be interesting to see a comparison chart on each page of and for each of the following audiences (who aren't we talking to? who should we be talking to?)

  • Shop administrator
    • View and Edit Order Details
    • Analyze Sales (internal or external?)
    • See a "Sales Report" (could be a simple view with counters)
    • Add New Products
    • Will not know the difference between products and node displays
  • Site-builders
    • Turn Key Product Images, Variations & Node Displays
    • Product Types & Fields
    • Cart Settings & Checkout Customization
    • Customer Profile Fields
    • "Site Recipes" (How do I create a store that sells downloads?)
  • Developers
    • Features Export of Views, Cart Settings, Product Types, Customer Profiles, Etc...
    • Product Types (Extending Commerce Kickstart Product Types, Programmatically creating types)
    • Rule Configuration, Export
    • Hooks and APIs
    • "Feature Recipes" (Would recommend a rule to change to modify the checkout process)
  • Business
    • Ability to Optimize Sales (Mobile Friendly?)
    • Comparison Charts
    • Administration Screenshots
    • Tight Analytics Integration and Sales Reports