Integrating Drupal Development and UX Design
My name is Michael Keara. I’m a freelance Drupal developer based in Toronto. I provide services to organizations and design agencies who require Drupal expertise for their web projects. My partner, Conchita Flores, and I work through our company The User Advocate Group. We also do a lot of Latin dancing.
Although my current passion and professional focus is on Drupal development, my background in UX strategy and design is always present in my approach. So wherever possible I try to incorporate better UX practices into the development work that I do.
I use a 'toolbox' of concepts and ideas to help me integrate development and UX design.
Here's a list of my favourites:
It’s always important to keep in mind the business intent behind any web project. Why does the client want this site? How does it further the interests of their business? Keep in mind ‘their business’ could be almost anything: selling on line, providing a public service, education, showing off a portfolio, news, …
It’s up to the client to determine what their business is. It’s up to us as website creators to help them fully realize their business intent on line.
See video: "Understanding Business Intent"
If a web site is an expression of business intent, then the web pages and any other sub-elements within the site are units of business intent. This is an important concept to keep in mind when planning a new site or feature. What is the business intent that justifies the existence of this element or that page? Knowing this critical information about the client’s intentions infuses the design process with rich insights into the element’s functionality, appearance and relation to the other elements with the site's ecosystem.
See video: "A Web Page is a Unit of Business Intent"
Clients rarely present a web designer/builder with a fully articulated mapping of what they intend to accomplish with their new web site. Different clients have different levels of awareness at different stages in the process. They begin, as they should, with ideas, thoughts, dreams about how they want to change the people they engage with.
By keeping clients focused on their intentions and not on the technical details, we as designers can help them achieve greater clarity about how to make those engagements productive for all parties .
The process is kind of magic: it begins with a seed of an idea and evolves into fully articulated Information Architecture and functional system.
See video: "Clients and Site Builders"
Functionality is meaningless outside of a usage context. Simply carrying out the functional specs for a given project will not guarantee success. Remember: web site design is not a technical problem, it’s a business problem! You have to start at the other end:
- Who is the user?
- What they supposed to do with your application?
If you can answer these 2 (deceptively) simple questions, you’re well on the way to a successful project!
See video: "Understanding Usage Context"
The term ‘user role’ has been used by site builders and developers to refer to sets of permissions for a given user. But in the UX design world the term is much more powerful and is key to understanding how to make really powerful, easy-to-use user interfaces.
User permissions are assigned to a given user account and are fixed throughout each session. But in the world of UX (user experiences) roles change frequently through any given session. Users will assume a new role in order to achieve certain goal. As they achieve one goal they move on to the next. Users constantly change the hats they are wearing.
Role-oriented design recognizes this and seeks to organize the tools required for achieving goals into logical groups that can be presented when the users ‘change their hats’.
The principle design philosophy that I’ve advocated since 2001 is Outside-In UX Strategies. This recognizes that most users are not technical experts and they look at web sites from the 'outside’. They don’t know or care about how it works or what goes on internally. Yet in the Drupal world, many content management tasks, and almost all site builder tasks, require the user to work in the ‘back end’ with abstract user interfaces that have no obvious relation to the web site’s front end.
This can require extensive training to learn how to use these back-end abstractions to make things happen on the front-end. But I always ask: to what extent can we bring the site building and content management controls into the front end usage contexts? Wherever we can do this, the user benefits with greater ease of use.
See video: "Inside-Out Site Building"