Of the initial thoughts discussed in part 1 about using various usability strategies within Drupal development, the most important, and perhaps most aligned with achieving business objectives, is clarifying value.
Within the UX world, this typically means proving the worth of usability principles within a budget and timeline. My goal in this post is to take the most salient reasons for advocating for UX design in business decisions and integrate them with making development decisions.
Development Decisions within a Feature
The true sign of a successful development decision is one where the end product requires no explanation. (The formulation of this idea is indebted to Leisa's Drupalcon session.) Leisa Reichelt, for those unaware, worked extensively with the UX challenges in Drupal 7 and is spear-heading the Prairie Initiative.
The developer has gone from the simplified 'what does my feature functionally do' to 'how well does my feature work in the hand of users'.
Often, under the burden of bug report tickets highlighting an issue, we developers put our heads down, our Gunnar shades on, affix our headphones and hammer out our solutions until they work. 'Work' is typically limited to brief test scenarios, the absence of error messages, and development content.
Before closing that ticket, however, follow these important steps:
- Identify the key feature objectives
- Run down the UX attribute checklist for each objective
- Document ideas that are desired, but may not be practical
Our example feature request will be a landing page creator with special blocks in the left sidebar. We'll use this feature request to outline how to use the above steps.
Identify the Key Feature Objectives
Limit the objectives of this feature to a maximum of three points. This may seem straight forward, but we've all been exposed to scope creep, especially as a feature is being developed. Let's say, during a brainstorming session, these objectives are identified:
- Speed up how content creators create landing pages
- Improve updating left sidebar blocks
- Increase visibility of shared sidebar blocks between landing pages
- Increase editorial control of all landing pages
- Improve placement of blocks on landing pages
- Increase awareness of special content on landing pages to users
- Decrease likelihood of unauthorized publishing of landing page content
Although it'd be awesome for your feature to do all of these things, get used to narrowing it down to three and saying 'no' or 'for phase 2' for the others. Limiting and clarifying the key objectives provide a foundation when dealing with client feedback. If there are a ton of 'why' questions during a demo, you can always ask if their additional request supports the key objectives identified earlier.
For our example, let's choose 1, 4, and 7.
Run Down the UX Attribute Checklist for Each Objective
Everyone loves checklists, so here is a development decision checklist for each key objective of your feature:
- How easy is it to understand how to achieve the object?
- How much does the user need to enjoy their interaction?
- What audience will use the feature?
- How well does it need to perform?
- How easy is it to find an answer if a user gets stuck?
While there are numerous factors a good usability strategist will consider, this minimum set will suffice when making development decisions. The trick is to feel satisfied that these attributes were considered and given your best shot. Sometimes, not all attributes will have an answer. This is ok.
If we look at objective 1, our checklist may look like:
Speed up how content creators create landing pages
- Identify steps to complete a landing page quickly and easily
- Access and identify required fields immediately
- Accessible to frequent keyboard users, content creators, and non-savvy publishers
- Dependent and auto-complete fields optimized and clear
- Short, concise tooltips and field descriptions
In the development world, zero in on the end user using your creation, evaluate your plethora of of implementation options, make a decision to support the goal, and do it.
Document Ideas That are Desirable, but May Not Be Practical
Developers tend to gravitate to the newest, shiny and precious technological innovation; this can cloud the established value proposition affixed to that feature. In other words, our desire to use a new technology detracts from the key objectives identified earlier.
Using Context module for block placement or jQuery tooltips for improved field usability may be left on the cutting room floor. Instead of relinquishing those ideas, add a note to the ticket detailing your train of thought. Bring them up again in weekly recaps so they are reflected in the meeting notes.
Following this process provides a record of thought in case further development proceeds and more budget is allocated to improve the feature. This also provides a feedback point when clients ask why functionality they wanted isn't there. Sometimes the best medicine is reiterating the key objectives, and explaining your train of thought for your implementations.
Extending Your Development Clarity
I've provided a few simple steps in clarifying the value of your development features. If you want to take them further, also consider identifying the current state of some of the attributes listed above and making another checklist of the desired state. This is especially useful in an iterative process where development of a feature lasts through multiple development cycles.
Either way, using the UX strategy of clarifying the value proposition of your feature puts on you on a clear path to more usable Drupal applications.