One of the things I still find amazing about the Internet is this phenomenon of thinking "Hey I have this great idea. I wonder if anyone else has thought of it?" and finding, upon cursory Googling, someone has indeed thought it, and has explored it many, many layers deep.
Or in a more succinct conversation with a friend during idle chit chat:
Me: "I bet some has come up with goggles for dogs and has called them Doggles."
Friend: "What? That's sounds stupid!"
Me (checking the Internet): "Yup. It exists."
Turns out many of our thoughts are not so unique. Realizing that has fostered my interest in metacognition, thinking about thinking.
If you ever want to dive into this topic, I'd recommend checking out, You are Not So Smart (podcast & books), or Thinking, Fast and Slow (book). You are... books are good light reading for primers into this subject. If you prefer a video format, I'd recently stumbled across this great video:
I think the split brain dichotomy explains much of people's irrational behavior; we're not coldly rational economic maximizing creatures, nor are we just a fuzzy ball of feelings; we're a some sort of mix of the two, maximizing our utility on what we value personally. How much, depends on the person (the so called "left-brained" / "right-brained") and their experiences. Each day we're bouncing between our thoughts and feelings.
I'm pretty sure this dichotomy explains pretty much most fundamental conflicts in politics (in whatever form it may take); we each have our manner of how feel & think about a topic. From that experience, we develop conventional patterns of thought that forms into some emotional/rational logic. We each try convince each other to follow along between our thoughts and feelings. Along the way, we find people that disagree/agree and we form relationships that span the gamut from antagonist to ally.
To get away from this digression—and mixing business & politics—I'll just note that metacognition is a useful trait as a web developer; sometimes you need to step outside your thoughts and just think about how your mind reached it's conclusion or descision. Or more often, how some other person (end user, owner, content creator, or other role) arrived to their conclusion or descision.
Someday, in the far off future, we'll unlock the secret of the brain and find out the optimum workflow between the thinking/feeling self (in my sci-fi future we would have machines that could annotate our written words from evoked thoughts/feeling). Until that day, we have to work with the hand we're dealt: the messy business of understanding what's going through people's split minds when working with software.
In our field it gets called UX, or user experience.
Doing great UX is tough, it's an investment that's hard to measure payoff in a broad, objective way and you really need feedback from a broad group of users to narrow in on your own great UX.
For me, I start with the basis of know your audience. Who is interacting with the site? What do they: want, know (on average) & don't know? Why are they interacting with it? Where are they interacting with it? (e.g. through Googling, Social Media) And how are they interacting with it? (e.g. a desktop/mobile device).
Once you've established that foundation, you can start dialing in to what would make a great UX with all your key interactions. I look at these interactions as an enumerated list of what your user does with the site. I like to organize these key interactions through the prism of the 3 different types of web queries: transactional, informational, navigational interactions.
- A user needs some information processed. He enters some data, presses a few buttons, and is presented with a result. A site that has a mortgage calculator would be a good example.
- A user needs to contact a key member of your team.
- A user needs to know some key details about your business and how it operates.
- A user needs some education about some topic related to your business (e.g. a blog post like this one).
- A user needs to provide some key details that help you identify what type of customer they are.
- A user needs to go to a certain of section of a site where a new interaction is going to take place.
With this enumerated list built, we have a framework from which to build everything else. It's here where we bring in all the pertinent roles to work on the details.
We have the designers who primarily work with navigational interactions (and some transactional elements where needed); they engineer the interface and give it a look/feel. We have the content developer who mostly works on the informational interactions; they engineer the information that the site will convey. Lastly, we have the developers who are focused mostly on the transactional side of interactions (e.g. web server request, processing data, various forms and other interactive elements).
That's the overall strategic framework. In terms of tactics to delivery on all items of interaction, there are few things I like to employ.
- Everyone is on the Same Page: When working with Drupal, which has many overloaded terms that can mean different things (e.g. a view vs. Drupal View) it's important to establish a common language. A short, page-long, brief about the project, its goals, and its terms I think goes a long way here. A simple, brief document describing the project helps everyone focus towards a common language that can be directed at the end user in his interactions with the site.
- Less Is More: We're already oversaturated in data these days. Try to refrain from overburdening users with irrelevant/burdensome information when it's not relevant.
- A user can only keep track of 3 to 4 items at one time. If you're interaction has more items than that you should start to consider breaking it up into sub-topics/design-elements.
- Focusing on what the user knows and is trying to do helps them accomplish their needs. One of the great things Drupal provides is categorization of users into groups called Roles. This is useful for hiding things that might not be useful for a particular type of user. For example, content authors are probably only focused on content creation. As such, you should hide other elements from them that are irrelevant to the job of content creation.
- Some information is context dependent and you should only display at particular moments of an interaction. For example, displaying certain requirements of large text form should only be shown when a user is interacting with it and isn't sure what to do.
- Coherent Design: Like with UX, a good design is something that tends to get neglected since there are many subjective elements to it. Whatever your level of investment in your design, the most important thing is that is consistent.
- Simple prose can go a long way. For navigational elements, you should focus on simple words to grab the attention of everyone who might have the same intent, but not the same vocabulary. I like using the most common words (e.g. the most common 10K words based on Google n-gram dataset) to name navigation elements so the intent is clear.
- Keeping information in the same area of the browser window is great for teaching the user where information lies at. It can be jarring and irritating for the navigating side of the brain, when this disappears (notice the rage when Facebook changes its designs), alters, or just behaves in non-consistent way.
Using the above strategy & tactics, I've found that almost any budget can support a excellent UX. The key is to know ahead-of-time about the user's goals, anticipate their needs, and serve them in the simplest way possible. Ultimately that provides a product with a pleasant experience and empowers you (and your customer) to accomplish your goal.