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.
Principles
- 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.
Audiences
- 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.
Planning
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:
- 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. - 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.
Comments
Comment #1
rszrama CreditAttribution: rszrama commentedSome follow-up notes based on my review of this with Bojhan the last night of the sprint:
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.
Comment #2
rszrama CreditAttribution: rszrama commentedKeeping this for future reference: http://www.drupalcommerce.org/node/347#comment-896
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.
Comment #3
Bojhan CreditAttribution: Bojhan commentedComment #4
joshmillerJust 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 commerceguys.com and drupalcommerce.org for each of the following audiences (who aren't we talking to? who should we be talking to?)
Comment #5
bojanz CreditAttribution: bojanz at Centarro commented