It’s Users All The Way Down

Sometimes in the process of defining your users, you’ll discover that, much like turtles, there are layers upon layers of them just waiting for their stories to be told.

Background

Joining a company late in 2014 as their new UX professional (and founding member of a growing team) has been an eye opening experience. Not only have I been able to finally practice what I’ve been preaching and learning the last few years, but I’ve been exposed to the healthcare industry – which is entirely new to me. Tons to learn = tons of fun.

Anyone in experience design must carefully consider their users’ goals, circumstances, capabilities and habits. This is one way for us to get out of our own heads and as far into our users’ heads as possible – avoiding the trap of designing for the users we’re most familiar with: ourselves.

Identify the users we’re serving is a great place to start. This sounds simple and it can be – but it can also be a complex puzzle (with all the edge pieces hiding and the corner pieces eaten by your dog.)

What my company does

At a high level, we provide a secure and efficient communication platform for the healthcare industry. The platform helps patients, practice staff and hospital staff efficiently contact physicians.

The problems we solve:

  1. handling the bazillion ways that physicians within a hospital or practice setting need to be contacted depending on situational context.
  2. sending information to a physician in a way that is secure and does not violate laws around the privacy of protected healthcare information (PHI).
  3. maintaining a fine balance between the needs for privacy and accessibility on the part of the physician.

Who are our users?

User (Turtle) #1: Our external users

This group includes doctors, nurses, acute care staff and hospital / practice management. They’re the obvious answer to the ‘who is our user’ question – the system was designed to meet their needs and everything revolves around maintaining and enhancing the capabilities that our platform extends to them.

If we push out a buggy feature or misjudge the utility of an enhancement and sacrifice something more vital, these are the people who feel it the most. We should be in close contact with representative members of this group, testing things out and gathering feedback constantly. This group will (and should!) receive the highest prioritization when it comes to evaluating features, to doing user research and to planning and executing usability testing. That said, don’t stop here!

User (Turtle) #2: Patients

Our healthcare professionals are themselves serving another group of users: their patients at member hospitals and practices across the country. These are the folks that our external users are under oath to care for, and who they went to school for a dozen years to serve.

This is the group who pays the price for inefficient communication practices. It’s the folks who have seen their premiums and deductibles climb year after year and who in too many cases don’t have insurance at all. They pay dearly for any healthcare they receive. This is you and me, when we visit our family doctor or when we land in the emergency room after falling off the roof in an ill-advised attempt to save money on chimney repair.

While we can’t prioritize designing for this group over the others, we should always consider the impact of our decisions on these people.

User (Turtle)#3: Internal Users

We have another group of users not immediately obvious to the naked eye: our internal users. These are the folks that use a suite of applications to onboard new external users and that support their needs on a 24/7 basis, 365 days a year.

They don’t use the exact same set of tools as our external customers, but they’re touching the same data and hitting the same systems. Their needs are also much more diverse since they service every type of external user and must become experts in the task flows for those users. This is no small feat, as the training required for these folks to become proficient runs from a full week to a staggering 3 months.

When considering the needs of this user group, striving to avoid introducing further complexity is a big priority. Beyond that, a large part of your backlog might revolve around taking steps to reduce that complexity even further (and therefore lighten the cognitive load of using the system).

If you’re in this situation, your company’s bottom line could be affected nearly as much by internal facing changes as it is by changes that affect your external users.

User (Turtle) #4: Executive Team

You’d think we had all the bases covered, but there’s actually one more group of users to touch on. Let’s call it the owner/executive team, made up of company ownership and senior leadership in both your external users’ companies and your own organization.

The goals and tasks of this group tend to be pretty straightforward, and sometimes seem pretty far removed from what the other three groups of users are concerned with. That said, while I don’t recommend placing too much weight on designing for this group, I do believe it’s a mistake not to consider their needs. Pulling off a win-win effort that enables this group to hit their goals tends to be a self-reinforcing success for a company.

Wrap Up

If you only take one thing from this article, know that accommodating anything less than every group of users in your designs is a Bad Thing.

Imagine that your executive team has seen the effect that your team’s UX design and development work has had on the bottom line – and so they foster a culture that values and encourages such efforts on an ongoing basis. This belief is folded into the company’s core values, and soon the sales, support and product development teams are all on the same page.

Your external users consistently see improvements, enjoy using your product and feel that their feedback is valued and acted upon. Inevitably these happy professionals pass those benefits on to their own customers . For our patients user group that manifested through cost savings, less time in the waiting room or waiting on a surgery date, and better quality of care.

Your internal users don’t have to jump through hoops to support the customers since the support tools they have been given are performant, intuitive and easy to use.

Wouldn’t that be a beautiful place to work? Are you ready to make it happen?

Thoughts On Proprioceptive Feedback

The literature:
Spatial Updating Of Self-Position And Orientation During Real, Imagined, And Virtual Locomotion (1998)

For efficient navigational search humans require full physical movement but not a rich visual scene.

The research done by Klatzky, Loomis, et al. as well as that of Ruddle and Lessels both indicate that proprioceptive feedback is a crucial factor in our ability to accurately gauge distance, size, heading and rate of movement. While my own experience echoes their findings, the reading left me with a couple questions.

First, what are the differentiating factors that separate those of us with what appears to be a more developed innate sense of direction (or perhaps a more advanced and accurate sense of place) from those who have difficulty with even the most rudimentary way finding operations when removed from familiar environments? Are there biological factors at play, or are the differences primarily acquired through life experience? Can we train to be more receptive to proprioceptive feedback, learn to interpret it more accurately, or are we consigned to our genetically disposed navigational fates, as it were?

Second, what are the implications of this kind of research on purely digital mediums, in which physical feedback is minimal or nonexistent? Are there natural corollaries between physical locomotion or visual perception and our navigation of pages on the web or through various states of an application? Could connections between these modes of ‘navigation’ be yoked more efficiently, enhancing a user’s innate ability to find their way about within a complex application?

What do you think?

Design Constraints Are Awesome

While reading some material recently I was particularly struck by a correlation between the sentiment of “designing for monochrome first” (for color deficient users) and the design movement termed “Mobile First”.

In both cases, the designer aims to build their interface elements such that the largest % possible of users will have accessibility to the data, based on the real and perceived limitations of the environmental factors imposed. After baseline accessibility and usability you can worry about nuances and aesthetics.

Monochromatic vision strips the designer of color-based tools and techniques, forcing you to fallback to the use of shape, contour, contrast and pattern. The Mobile First design sensibility forces the designer to carefully prioritize what elements of the design are truly needed to accomplish the goal(s) of the product, framed within the limits imposed by a smaller display. You also have to consider the contextual differences in usage between a mobile device and a desktop computer, and within the vastly different feature sets of modern devices.

I often hear about project constraints in terms of drawbacks, of obstacles to building the perfect widget. It’s much more helpful to think of constraints as helpful wayfinding elements on the road to successful project definition. If you know what they are, you won’t waste time in rabbit holes and you’ll be able to focus your time and attention on crafting the best product possible – one that will meet the unique needs of your users, whether or not they can see colors and regardless of what they’re using to access your offerings.

Thoughts On Medical Decision Making

Original article by Jerome Groopman

We all fall victim to habitual behaviors, and more so when we are unable to focus sufficient attention on tasks at hand, believing (consciously or unconsciously) that we can accomplish some process or task without conscious thought, instead thinking about ‘more pressing’ matters.

What is more difficult to detect are those biases not based on habit, but instead on other factors. Groopman’s article on medical decision making explored this issue in the light of decisions made every day by physicians in practices and hospitals across the world.

Several types of errors were explored, including Representativeness error (thinking that is overly influenced by what is typically true), Availability error (the tendency to judge likelihood of an event by how easy relevant examples come to mind), confirmation bias error (cognitive cherry picking – confirming what you expect to find by selectively accepting or ignoring information) and affective error (making decisions based on what you wish to be true).

The stories he shared demonstrate how a very skilled and educated doctor can make incredibly dangerous mistakes, due in some cases to the fast-paced world of medicine but in other in reaction to common human urges such as the desire to be merciful and spare a patient embarrassment or further fatiguing tests.

At my workplace we are tasked with making medical industry communication more secure and much more efficient – resulting in better patient care and increased physician and clinician satisfaction. After reading this article and having learned a great deal about how complex the communication needs of a hospital or practice have become, I have to wonder how many mistakes are made due to the very real problems of workflow dissolution and workplace communication breakdowns. How many errors of the classes described by Groopman could be avoided or reduced in severity through more frequent and higher quality peer-to-peer interactions in the medical industry?

GapMinder Data Analysis

In my HCI cognitive science class we’ve been studying visualization and how a given interface can enhance our mental processing power, bringing more of our wits to bear on a challenge. Here’s a look at comparing a few layers of data as reported by two very different nations.

Denmark vs. USA – Charitable giving related to income & life expectancy

I chose to compare the nations of Denmark and the United States, examining their respective records of charitable giving and comparing that to each nations’ income per person and their life expectancy. The data available ran from 1960 to 2008, and so it’s worth noting that the period studied spanned several wars with worldwide impact, numerous financial recessions and a gradual but accelerating trend of climate change.

The United States
The United States in 1960 was quite a charitable one, donating 0.54% of the gross national income (GNI) while only reporting $18,175 in income per person. We had a change of heart it would seem, as the % of GNI given to charity fell steadily for 37 years before finally ending at 0.18% of GNI in 2008.

During this period, while our incomes rose by $24k and our life expectancy by 8 years we gave 0.54% less to charities.

Denmark
Denmark in 1960 was a hard place, donating only 0.09% of their GNI while reporting only $11,569 in income per person. They seem to have buckled down and gotten industrious, as the % of GNI given to charity rose for 21 years to 1.03%, with a high of 1.06% before finally ending at 0.82% of GNI in 2008.

During this period, their incomes rose by $20k and their life expectancy by 6 years. In the end Danes increased their charitable giving by a staggering 0.97% over the period.

Reflections
An interesting measure to add to this comparison would be an index of reported happiness & contentment – does charity or income have a greater effect on happiness?

I would also have enjoyed seeing an overlay of world events across political, economic and climate scopes, relating those factors into the changes in life expectancy, income and charitable giving.

The animation was quite helpful, and illustrated the rate of change between compared parameters over the lengthy collection of data ranging over 48 years, clearly calling out the rapid rise of Denmark’s charity while the USA gave away less and less each year.

It’s purely correlative, but it appears that given the much larger percentage they gave to charity (from their noticeably lower income) the Danish were not overly burdened and lived to nearly the same age. Many factors could have been at play, but I’m given to lean towards the old adage that money CAN bring happiness as long as you spend it on others.

Using Vision To Think (a nod to Stuart Card)

In an HCI class I’m taking currently, we’re studying the cognitive science behind the long human history of visual-spatial displays. We’re talking caveman drawings up to the latest in Minority Report-style virtual interactive displays – fun stuff!!

Here’s an article to soak up if you’re interested in this kind of stuff: The Cognitive Science of Visual-Spatial Displays: Implications for Design

And here’s some thoughts of my own about that article:

More than anything else, this week’s reading of Mary Hegarty’s paper on the science of visual displays made me realize why it’s much easier for visually-minded folks like myself to understand something best when we’re able to interact with a subject on a visual level.

“Representations that are informationally equivalent (contain the same information) are not necessarily computationally equivalent”…
“task performance can be dramatically different with different visual displays of the same information”…

These are dead on. Whenever I’ve encountered a complex problem, whether facing it alone or in a small group (or mentorship, etc.) I often kick off the process or discussion with something along the lines of “Are there other ways I/we can look at the issue?” This is helpful in many cases because in representing the object or process with an iconic, relational or complex display allows us to augment our thinking, to enhance our understanding and to bring additional inferences or insights to bear.

Displays allow us to externalize both the storage and the organization of a massive amount of data, freeing up our fragile and limited minds to process that data in different ways. It also lets us explore the relationships between groupings of related elements, i.e. chunking – freeing us to a degree from the limitations of short term memory by compressing these complex associations or concepts into a fewer number comprehensible objects.

I understand the world through my visualizations of it, both in reality and in my internalized efforts to understand the world around me, so my favorite blurb by far was the author’s reference to Stuart Card’s sentiment “Using vision to think”.

Notes from GiantConf 2014′s “Building a Whole Team UX Design Team” presentation by Phillip Hunter

In his presentation on day two of GiantConf 2014, Phillip Hunter talked to us about “Building a Whole Team UX Design Team”. Here are my notes from his talk.

Phillip Hunter – Building a Whole Team UX Design Team
@designoutloud
http://www.minotaurdesign.com/blog/wp-login.php

His belief is that in the UX community, team building is much like early days in baseball scouting.

The focus on stereotypes:
on rock Stars in the industry…….
(is that a person w/ diseases and who trashes hotel rooms? lol)

On Ninja’s….
(is that the person who kills people in the night? lol)
Focus on design mishmash – (beanie/knit cap and glasses, lol)

– Stereotypes don’t help us build better UX teams. Avoid them.

(slide of the major pieces of most companies) – All these people are ENABLING the user experience.
– most of us are in Product development team.
– so it’s silly to think of one small piece of the org as wholly responsible for the UX of a company

4 primary capabilities (as a grid):
– engineering leading technology
– maintaining strong teams
– running a successful business
– enabling great experiences

The practice of creating experience is a SERVICE – look to service design for cues

Strategy means defining and inspiring before hiring

Hiring a dev, designer, tester because you need to developer, design and test is premature.

Context + capability to help you know the best way to create that holistic UX mindset.

OAQH- Orient, Assess, Question, Hypothesize

Setting the team-building CONTEXT:
– what are our goals, values, constraints and principles as a corp?
– what do we need to get done?
– why?
– how much/how fast?

Setting capability requirements:
– What do we need to be god at?
– How good? How will we know?
– What are our priorities?
– Not who…. (yet)

Liz Bacon’s infographic on her definition of user experience design
– pie chart of sorts
– ranked herself within each facet

Building effective structures within the company:
– Complementary strengths vs homogeneous development
– Breadth and depth of skill across people
– Increase participation

Beyond hiring and skills:
Shape align and inform with biz goals
Aim for impact, scope, scale, diversity, resilience, sustainability

Crazy list of necessary skills (all of which mapped back to the grid of 4 above)

Atomic elements of necessary high level skills

Have the right project members been identified?
In what areas will augmentation be the best thing?
What kind and from where?

Building Your list of necessary Skills
Skill name
-skill 1, 2, etc becomes `> color, line, shape 2. Latent need identification, ebrand integration, prototyping, etc.

Gathering list items:
Ask your UX leaders and ICs, your UX enthusiasts, your Product owners, your Execs and sponsors.

(ranking 1-5 etc)
Skill name – Current Level – Desired Level – Priority
– – – –
– – – –

Perceived skill gap
– gap value on its own wasn’t that compelling/illuminating
– Gap value multiplied by Priority – this really surfaced the true GAP in context

Conversations that can come out of the above types of analysis?
Who does that already?
How can you get them involved?
What do your colleagues want to be good at?
X is how we need to craft our job description for HR!!!

sixboxes.com
framework for aligning people’s desires with their roles, and ultimately their ideal internal path that also benefits the company

– issue challenge to add UX to everyone’s job
– Let people find their point of contribution

HIRING (since sometimes you just have to…..)
– understanding and implementing the strategic framework from above
– involve the team to determine fit and talent
– Hire the inspired

Phillip’s slides (Thanks, Phillip!) – http://www.slideshare.net/philliphunter/building-a-whole-company-ux-team

Notes from GiantConf 2014’s RWD workshop with Brad Frost

In his RWD workshop this last weekend at GiantConf 2014 Brad Frost plowed through the history, current state, best practices and possible futures of the RWD philosophy/approach. Here are my notes from his talk.

June 14, 2014

His experience: web on mobile for 4+

  • Responsive Design Patterns
  • ThisIsResponsive.com website and github (http://bradfrostweb.com/blog/web/this-is-responsive/ & http://bradfrost.github.io/this-is-responsive/index.html)
  • (older site) – Mobile web best practices
  • WTF Mobile Web (what not to do)
  • Cosigner of Future Friendly Manifesto
  • Worked for R/GA at one point…showed the company logo slide to illustrate that no one knows what they’re doing.

General Landscape

  • i6bb mobile subscriptions
  • in america, 91% of americans have a mobile… 56% of those are smart phones.
  • 1.5 mm android activations a day
  • 1/3 americans have an ereader/tablet
  • 20% of ALL internet traffic is mobile
  • 68% of americans access the web via phone
  • 33% of those ONLY use the mobile web
  • Mobile web pictogram –
  • 157mm users ONLY use FB from their mobile
  • What are we sharing from mobile on social? (text photos videos and LINKS)
  • 51% of referral traffic to media sites came from FB mobile
  • blog.cloudfour.com – good status on mobile – a comprehensive guide

Approach – Options

  • Do nothing. (rant: cultivating a nation of slide swiping screen surfing zombies)
  • Make an APP!
    • App glut
  • Links don’t open apps
  • pros and cons of course
  • Separate Design Experiences (Nielsen’s advice, to build two sites and cross-linking to make it work.)
    • more dedicated, optimized, catered experience
    • no need to adapt
    • potential to be more performant
    • url redirection (getting a mobile version of a site on your desktop due to a link given to you)
    • content parity
    • content governance
    • device database
    • SEO issues (better to keep your links under the same single site)
    • Continuity issues
    • The Space Between (kindle fire, etc.)

Strategy

  • Build a barebones mobile responsive site, and grow it over time.
    • eventually kill the old clunky desktop site
  • Responsive retrofitting a site
    • j spool’s ‘escalator of acquired knowledge’ (people hate when you completely tear down and rebuilt their beloved sites)
  • Mobile First (progressively enhanced, future friendly, awesome)
  • Piecemeal approach: “our responsive header is almost done”
    • seen on really huge sites in recent times. footer, header, module by module
    • acclimatizes the user
    • he’s only seen it in large companies, but he thinks it could work very well for small
    • companies/sites/teams, perhaps more so.

Foundations

  • Ethan Marcotte @2010 in ALA
  • Fluid Grids, Media Queries, Flexible images
  • the Fluid grid should do most of the heavy lifting! (don’t go crazy with media queries!)
  • Context is needed
    • Adaptive is a bigger container than responsive, and itself contains responsive
  • There are other parts, but RWD is what stuck.
    • Feature Detection
    • Server side components*
    • interdevice communication
    • performance, etc.

Principles of Adaptive design

  • ubiquity (this is for everyone, for anyone, for us all
    • diversity is not a bug, it’s an opportunity) – step reiger
    • mobile users will do everything desktop users do, if it’s accessible.
    • Content parity
    • Context
      • Quantitative
      • Qualitative
  • flexibility
    • embrace the squishiness
  • performance
    • 71% of mobile users expect mobile sites to load as fast or faster than desktop sites
    • you have 5 seconds of someones time…
  • Future friendly – Invest in your content. -> Make APIs, not war

Frameworks

  • Bootstrap, Foundation by Zurb, etc.
  • Jetstrap/Bootkit
    • these are all well and good, but lead to look alike issues
    • One-size-fits-all
    • Potential for bloat/unneeded stuff
    • might not do what you need
    • integration issues
    • have to subscribe to someone else’s decisions
  • Tiny Bootstraps, for every client. – Dave Rupert
  • Front end style guides
  • promotes consistency cohesion
  • easier to test
  • better workflow*
  • creates a shared vocabulary
  • useful reference
  • Lots of front end style guides coming out (started with starbucks. starbucks.com/static/reference/styleguide)
  • problems with these:
    • Time consuming to create
    • treated as an auxiliary project
    • often too abstract
    • often seen only as a designer/development tool
    • created after a project launches
    • often incomplete, only serving present use cases
    • often lack a clear methodology

Atomic Design

  • josh duck’s periodic table of html elements
  • @dmolsen
  • Abstract ————————-> Concrete
  • Creators ————————-> Clients
  • Atoms, Molecules, Organisms, Templates, Pages
  • Reference, Build, Build, Build, Reference

the pattern

  1. ATOMS (input field)
  2. Molecules (search module)
  3. Organism (site header)
  4. Templates (site header bundled into a whole page template) -focus on content structure (reference to mark boulton.co.uk – content strucure first, not required to have content first)
  5. Pages (the pouring in of real & true representative content to see if it all works)
  • validate or invalidate the atomic design thus far
  • you test variations of the template at this point (still the same template though!)
  • does it scale? (content length, list item length, etc.)

pattern lab

  • @dmolsen Dave Oldsen and Brad created it
  • Open source project
  • What is it?
    • It’s a design system BUILDER
    • designed to help you execute a design system
    • a custom component library
    • a pattern starter kit
    • a practical viewport resizer
    • an annotation tool

It’s NOT:

  • a UI framework
  • Language, library, or style dependent
  • Incredibly rigid
  • “just” a pattern library, but also not a prod ready static site generator
  • ..like Jekyl

moving parts

  • builder
      mustache for templating the guts

      JSON for piping in real content

  • viewer
    • ish (gives you a different value every time (small button gives you a smallISH value)
    • Lets you rapidly preview random and different layout scenarios
    • displays the size of the display currently in view.. as px and ems. Annotations
    • his issues with wireframes in general… long assed annotations, iXds are working in a layer of abstraction
    • The annotation tool couples numbers with an overlaid layer of annotated description
    • Annotations with JSON
    • Lineage
    • Shows off what components make up a particular component, and where its applied.
      • ‘X pattern contains the following patterns’
      • ‘x pattern is included in the following patterns’

Other stuff

  • code view
  • pattern status
  • auto refresh
  • page follow
  • Future: plugins
  • idea of checking your performance budget whilst developing with Pattern Lab

What’s the hardest aspect of responsive web design?

  • design/dev or people/process (overwhelmingly process/people)
  • Entertainment Weekly
  • you have to sell people that RWD is the right thing
    • using data (showing conversions, improvement metrics – hockey sticks)
    • SHOWING not TELLING is a lot easier to sell through to clients
    • talk about the simplicity of the 3 pillars (flex grid, resp images, media queries)
    • why RWD matters, selling to Tiffany in his R/GA days:
      • He took a representative page from their site… (their desktop site), and demoed how it COULD be if set up properly
        • It took him half a day…
        • they then took a crapload of devices and spread them out on a long table… two tabs open on each device one for now vs possible Set Expectations
      • Don’t sell websites like a painting. Instead, sell easy and sexy access to content, agnostic of device, screen etc.
      • Kill the waterfall! IA->VISUAL->DEV = no good Interface Inventory
  • Much like a content inventory, but more specific
  • pick out, cluster, and inventory the buttons, inputs etc. – this illustrates the differences, similarities, the scope of the current interface situation
  • This helps you gauge LOE on a redesign!
  • Document your interface
  • Promote consistency
  • Establish which elements will be challenging to translate into RWD
  • lays groundwork for future style guide/pattern library
  • Evernote for Interface Inventories – Aaron Gustafson

Establish Direction

  • before too long, you can design for the content structure you KNOW will exist
  • use of style tiles for visual direction – more specific than a mood board, but not getting too far down into the weeds
  • use of Typecast for brainstorming and playing with potential typographic treatments

Rolling up your sleeves

  • build out basic patterns based on design sketches
  • moving into element collages (still not full comps)
  • often start with header and footer
  • often end up with odd states.. ie a finished header and footer but very rough main content well – this requires frequent communication with client so they know how the process is flowing
  • A traditional comp might not happen until nearly the end of design process …and might be a coded comp vs a photoshop comp

Responsive Patterns

  • he collected design patterns, in b&w & very barebones. (thisisresponsive.com)
    created to avoid re-explaining patterns again and again Layout

Grids

  • Which grid system should i use? (he doesn’t care 😉
  • Css tricks.com don’t overthink it grids
  • Future of CSS Layout
  • Grid Layout
  • Flexbox (see solvedbyflexbox.com)

Media Queries

  • avoid desktop-first styles (don’t set defaults only to have to overwrite them!)
  • mobile first styles start from the perspective of small (using min-width vs max-width)
  • the absence of support for media queries is in fact the first media query. – Bryan Rieger
  • Let CONTENT, not screen size, determine breakpoints
  • Start with the small screen first, then expand until it looks like shit. Time for a breakpoint! – stephen hay
  • HAY mode in Ish (in hay’s honor)
  • use of EMs in media queries – no longer a strict best practice, but a matter of preference
  • Still recommend using relative units (he has no pixel values in his styles)
  • Use major AND minor breakpoints (minor being a component level breakpoint or page level breakpoint)
  • don’t overdo it
  • ??? about localization and media query usage (german text is longer….)
  • option 1: use the longest localization by default (his recommendation)
  • option 2: apply a differentiator (addl class on the body tag etc.) and add/modify german specific styles Multi-Device Layout Patterns

Mostly Fluid patterns

  • The Column Drop
  • be careful that the stuff in the sidebars isn’t necessarily related to the main content (due to content hierarchy concerns)
  • The Layout Shifter (brad voids these if possible, preferring simplicity)
  • ie a complex, unique layout that really changes across breakpoints
  • Tiny Tweaks – ie very little changes..
  • minor font size or margin changes
  • The Off Canvas (jason weaver – jasonweaver.name/lab/offcampus)
  • stuff hangs out off screen until needed
  • Content Choreography
  • content folding (ie folding ads in between articles)
  • could use flexbox (jordanm.co.uk/lab/content)
  • could use AppendAround: a responsive Markup Pattern
  • from Filament Group
  • Don’t use this all the time, but it could help solve certain issues

Layout considerations

  • When users scroll on mobile we are moving backward through time
  • moving through a list
  • deep dive into content
  • All these instances are scrolling through a singular content type
  • don’t mix up your content types when you put stuff into a single column with RWD.

Conditional loading:

  • given the % of sites that push the same heavy content to mobile as desktop…
  • Aggressive enhancement (nice term)
  • The Thing (a) beside and above NOT The Thing
  • Instead, include links to the “not the thing”s by fragmenting out that content
  • put these fragments behind a lazy load and a user opt-in (via accordion for example)
  • old browsers treat as links to different pages
  • newer stuff fetches via ajax and drops it into the expanded module
  • Larger format views display the whole thing by default
  • (24ways.org/2011/conditional loading for responsive designs)
  • Boston Globe does this with their weather widget
  • either drives to a different page OR
  • displays inline via async call How to do this?
  • Matchmedia.js (has polyfills too)
  • enquire.js
  • Conditional CSS (adactio)
  • Progressive disclosure as a term http://en.wikipedia.org/wiki/Progressive_disclosure
  • Scanability vs capability is a balance
  • It’s ok for different users to get a different experience as long as functionality remains accessible
  • Screen size is just ONE variable.. (touch capability, etc. are others)
  • Large screens do not always mean fast connection !!
  • you can generalize somewhat
  • you can TRY to detect bandwidth but it’s complex
  • things like Boomerang test bandwidth by pinging all the time (hard on batteries ouch)
  • Just design a fast experience!
  • be mindful of the # of http requests
  • look into server-side optimization

RESS ala Responsive Design + Server Side Components

  • lukew.com ‘s article
  • described as a scalpel
  • if on a mobile device, don’t load (this annoying thing)
  • if on desktop, DO load (this crazy thing)

Touch (ala accommodate for meat sticks)

  • hybrid devices make things complex (windows tablets, Chrome Pixel, etc.)
  • assumptions around touch targets, margins must be questioned
  • keep everything touch friendly by default
  • same issues on phablets (save for tests for touch etc.) Touch considerations
  • don’t rely on hover states (don’t put important stuff there)
  • if the info isn’t important, defer it (ie to a product detail page)
  • or have it toggle display via touch.. BUT
  • touch implies intent, so you can run into trouble here
  • touch to toggle content is anticlimactic if users were trying to DO or GET something vs just exposing content
  • Patrick Lauky – good source for touch related experimentation
  • Look for opportunities to provide enhancements for touch devices, such as swipe gestures
  • but be careful. careless touch input can result in unwanted effects or false positives.

Navigation

  • Navigation should be like a good friend… there when you need them, but cool enough to give you your space.
  • don’t make users scroll through lots of nav to get to content Tactics
  • Do nothing (leave nav as is)
  • doesn’t scale for larger navigations
  • Footer Anchor
  • nav clicks drive user to footer via named anchor (no js used)
  • somewhat disorienting (might be a good baseline pattern to be enhanced further)
  • The Select Menu (ie. the drop down menu)
  • good for non-primary navigation
  • The Toggle (the current go to best practice)
  • Content slides down and exposes navigation
  • elegant
  • keeps users in place
  • relies on javascript
  • The overlay (variation on the Toggle)
  • does not drop content down
  • unwanted link navigation on older devices (ie click goes to lower stacked element anchors)
  • unwieldy (he tries to keep things on one plane)
  • The nav flyout
  • pro & con: Able to display LOTS of nav items
  • the go to for content-heavy sites
  • consider content inventory/strategy if you’re having to deal with a super long flyout menu
  • The Priority + considerations approach
  • Partial exposure of nav based on priority, with ‘…more’ link to expose the entire nav
  • not a fan, but considers it worth exploring
  • The HIDE and CRY
  • no nav on mobile (ack) that comes close to desktop experience
  • muy mal “mobile users don’t do/need that…” Complex Navigation
  • The Multi-Toggle
  • ie. nested accordions ad infinitum
  • behavior variations with touch devices.. (primary nav no longer can drive to a page, but must expand the subnav as only choice)
  • Solution: add another item “all x products” effectively acts as the click through for touch that desktop had.
  • Right to Left (nav panes slide left or right based on clicking nav arrows in nav)
  • follows nav convention of drilling in/out
  • right = deeper, left = shallower
  • sony did this, but is no longer using it
  • Skip the Subnav
  • on small screens, just drive to the nav item’s landing page and then expose the sub navigation
  • the main downside (but not a huge one) is you are forcing a full page refresh to get to desired destination

Navigation considerations

  • Find the balance between nav access and obtrusiveness
  • Test!
  • Be explicit about the nav icon (as much as you can)

IMAGES

  • avg 1.78mb page load —- 1.12mb of that are images. Images are a huge issue.
  • various screen sizes
  • growth of high res screens
  • varying bandwidth
  • need for art direction ie diff crops, etc.

background images

  • these work as advertised, ie they behave properly in media queries
  • ie multiple backgrounds aren’t downloaded
  • use mobile first background images
  • don’t include large by default, introduce them in a media query block
  • Icons
  • many times they don’t look good on hi-res screens
  • use of ICON fonts is growing, and becoming a best practice
  • IcoMoon – quickly choose or build your own libraries and generate your own iconFont
  • Web Fonts (including Icon fonts) are NOT supported in a couple key browsers
  • Opera MINI – a proxy browser preloaded on many feature phones and smart phones
  • (proxy browsers end up taking very little bandwidth)
  • Older Windows Phone devices don’t support them.
  • Grumpicon converts images or svgs as data
  • can also use png image fallbacks
  • Grunticon output
  • important stuff -> All icons inline in the css as vector svg data urls (better support)
  • all icons inline in the css as PNG data urls
  • All of the icons referenced externally as png images, which are automatically generated from the source SVG and placed in a directory alongside the CSS files

Image Considerations

  • Vectorize all you can
  • use HTML special chars
  • use icon fonts, but with fallbacks (SVG)
  • If you use sprites, consider making a hi res sprite sheet
  • Semantically important images
  • preserve aspect ratio (brucelawson.co.uk preserving aspect ratio)
  • Avoid text as images!!! (duh)
  • Responsive image considerations
  • Ensure content is legible on small screens
  • Larger dimensions, higher compression rate (blog.netvlies.n/design-interactive/retina-revolution/)
  • Looks great on hi res screens and regular screens
  • repainting the canvas is expensive performance wise (affects any fluid image)
  • still doesn’t’ provide art direction (example: obama at car factory – crop needed for mobile view)
  • only make 1 image request per asset
  • load the small image asset by default
  • consider server-side detection
  • WHATEVER you do, make sure it’s easy to swap out. It WILL be deprecated 🙂
  • Art Direction
  • Focal point cropping: – designshack.net/articles/css….
  • HTML5 Picture element is solidifying (finally)
  • uses Jehl’s picture fill as a fallback?:
  • accessible text
  • SizerSoze.org (what is the cost of your non-responsive images?)
  • calculates the savings if you were to use the above solution in your site
  • SRC SET:

    <.img src="small.jpg" srcset="large.jpg 1024w, medium.jpg 640w, small.jpg 320w" sizes="(min-width: 36em) 33.3vw", 100vw" alt="a rad wolf" />

  • One beef was that it wasn’t using media queries (at one time)
  • but it’s a nice quick easy way to explain multiple sizes of an image
  • check out Coyier’s article on SrcSet vs Picture element

Video

  • Srcset
  • fitvidsjs.com (by coyier)
  • some sites have good examples how..
  • vimeo, etc
  • embedresposively.com

Maps

  • brad’s adaptive-maps badfrostweb.com/blog/post/adaptive-maps
  • apps hijacking the user’s attempt to browse for a navigation (not a bad thing, actually)
  • using Google’s maps API via a link from the page’s representation of the map
  • if screen scan accommodate the EMBEDDED map, instead just load the embedded map (example, min-width: 700px )

Lightboxes

  • example of a non-scaling pattern on Mashable
  • not all desktop patterns scale to the small screen
  • example of FB’s ‘create event’ dialogue on mobile/vs desktop
  • Conditional Lightbox
  • link to the raw image or chunk of content
  • detect screen size
  • ensure content is legible on small screens
  • if screen is big, inject the lightbox functionality
  • Magnific Popup – free responsive jquery lightbox plugin (also works with Zepto)

Data Tables

  • Table to name/value pairs
  • Table to List
  • Priority Columns (the important data persists, others get pushed into a ‘display more’ collapsed state)
  • Horizontal overflow (locked column approach)
  • Test lots! (some android devices don’t support this)
  • Consider using combinations of these to meet needs
  • Considerations for tables
  • What the data is like matters
  • how closely linked is the data’s display format to its semantic value?

“Modules”
Carousels

  • make sure you actually need one
  • runyon found that the % of folks that make it to panel #2 (of interactive carousels) is less than 5%
  • shouldiuseacarousel.com (rounds up the numbers on usage and effectiveness)
  • cycle through items that are similar (vs disparate item types)
  • only load what you actually need
  • be CLEAR about your carousel’s functionality ( “…” is not enough)
  • suggest more content to users
  • provide gestural hints (content overhang off screen)
  • opera mini; doesn’t support touch events
  • by default, provide fallback navigation (and replace it if touch is supported)
  • Types of Carousels
  • The Reveal (as screen space goes up, they expose more products in the carousel)
  • takes great advantage of larger screens, avoids the ‘stark & empty’ effect

Accordions

  • Tabs to Accordian: codepen.io/sturobson/full/xgfel (converts tabs to an accordian)
  • Accordion to Full: each section/subsection becomes an accordion section (ie collapses)
  • when there’s enough room, it displays in full

Forms

  • Label alignment shifts (top labels for small screens, left for full screen)
  • he prefers keeping them in the same place
  • Float Label – animated floated label that kicks in when default text is overwritten by user input
  • Float Label Form Interaction on Dribble
  • Internal labels: pros and cons
  • the field itself becomes a button/field.
  • saves lots of vert real estate
  • not so good accessibility
  • you lose field context when you enter text (since you’re overwriting)

Form Considerations

  • subtract as much as possible
  • use proper input types
  • chunk stuff up (multiple input phases allowing users to save progress (ie 1/4… 2 of 4, etc.))
  • use input types (number, email, url, tel) – this is the lowest hanging fruit here
  • they all fall back to text if not supported
  • Provide hinting
  • be careful with inline labels
  • validation but not too aggressive
  • Opting out of RWD
  • css-tricks.com/user-opt-out-responsive design
  • don’t use fixed positioning
  • very buggy on older browsers
  • just really goofy
  • burns up valuable real estate
  • Position: Fixed considerations
  • If it must be used, fixed headers are more reliable as they degrade more gracefully
  • avoid JS solutions
  • be mindful of orientation change. use media queries to disable fixed for landscape orientation
  • conditionally introduce fixed positioning when screen space becomes available

Development

  • Viewport metatag – tells browser to ignore its zoomed out state
  • viewport in CSS
  • @0webkit0-viewport {width: device-width} — etc.
  • don’t disable the user’s ability to pinch and zoom
  • only introduce the viewport meta tag when you’re sure the content is mobile-optimized
  • CSS
  • Border:
  • SASS
  • plain css is inefficient
  • nesting is awesome in SASS
  • variables are amazing
  • putting media queries into SASS vars is a fav of his
  • Nesting media queries
  • changed his life forever
  • .module { margin: 0 0 1em; padding: 1em; @media all and (min-width: 50em) { float: left; width: 50%; }
  • Getting Sass to help with legacy IE -> nicolasgallagher.com
  • respond.js by Scott Jehl

Device Support

  • what should i support?
  • iOS
  • Android
  • repulsive yet relevant
  • ie mobile, blackberry, silk, nokia etc.
  • There is a difference between SUPPORT and OPTIMIZATION – focus on accessibility
  • Redux: Ubiquity
  • our responsibility to make content accessible across the world, across economic and social spectrum

Testing

  • remote testing tools (browserstack)
  • viewport resizing tools
  • Test on actual devices
  • truly test a design’s performance
  • Device capabilities
  • Form factor
  • Pixel Density
  • Impact of the network
  • Device Criteria
  • your traffic, form factors etc. budget
  • test w/o breaking the bank – brad’s post from bradfrostweb.com
  • OpenDeviceLab.com

Midwest UX 2013 – Recap

I’m back in Tennessee after spending four days in Grand Rapids, Michigan where the MidwestUX 2013 conference was being held. I was turned on to the conference by an old friend whose advice I’ve sought out as I work towards moving back to design roles. I’m grateful Christian steered me to MidwestUX, and glad my family and my job were able to facilitate the time I needed to attend.

Despite having gone to Columbus College of Art in Ohio (and being born in Iowa), I don’t have a lot of ties to the Midwest any more. After witnessing the degree to which the brains behind the conference had their acts together, and having met so many clever, kind folks from all walks of life who joined me there – I have to say I was really impressed (and consider MidwestUX a new connection to the Midwest!)

Impressed with the city

Grand Rapids, huh? For those folks NOT from the region, this may conjure up vague associations with cold weather, lake effects, and proximity to our Canadian neighbors in the north. I was surprised to find instead a city whose downtown was quite a bit more developed than Knoxville, at least 25% more populous, and FULL OF DESIGN.

larger than life fortune cookie message

There’s an art school there: Kendall College of Art and Design. It’s pretty big, pretty modern, and housed in some pretty swanky digs.

There’s a lot of really good beer here, too. Also some whisky, burgers and arcade games. I can vouch for the first two bits there.

beer?

There’s also some really good coffee here. The first day, we hit Biggby’s Coffee. It wasn’t bad – better than average coffee, but nothing life changing. The second day I went to Madcap Coffee. If I could, I would teleport there and back every morning from now on. I would marry their machiatto, but polygamy isn’t legal in Michigan or Tennessee. I wasn’t the only one either – fellow drinkers would note the cups held by other attendees and simply raise them up and wordlessly acknowledge the religious experience we shared.

madcap mmm

Also a great art museum. More on that in a moment.

Impressed with the pre-conference work

Every point of contact I had with the conference was well designed, well managed and question-free. Seriously. I had no questions after reading the website. Signing up for the conference triggered confirmations, friendly advice about the city and venues, and timely reminders and new info via email and the website as it became available.

Impressed with the conference logistics

Again, no questions. No drama. No issues with instructions, with missing presenters, with spotty Wi-Fi, or unclear directions. There were volunteers stationed for maximum effect to direct foot traffic between buildings and events, signage up everywhere you could need it to be, and things ran on time across the board. It was almost spooky.

The food and beverages provided at certain points were fresh, plentiful, tasty, and served with 100% recyclable or compostable materials. There was next to no waste produced by this event.

The sessions and workshops themselves comprised a nice mix of disciplines and interests, though I had a couple hard decisions to make.

Session notes

Thursday
I missed a great workshop on drawing communication practices by MJ Broadbent, but enjoyed a workshop on design practice led by Matt Nish-Lipidus. Given the simple task of coming up with a clock that describes one’s relationship to time, there was a surprising variety in what our breakout teams came up with.

Since I covered all costs myself versus having the conference/travel paid for by my company, I opted to only do one workshop. After lunch I headed to the GRAM, or Grand Rapids Art Museum. There I enjoyed the permanent collections as well as a few remnants from the ArtPrize event they apparently have each year in Grand Rapids. There’s a very well put together art library within the museum as well.

GRAM reflecting poolGRAM stairway

Friday
Abby Covert’s keynote on “Making Sense of Place” did not disappoint. I’d heard a bit about her, and I can see how she’s got the reputation of being a smart, kind, and energetic designer and presenter. Her talk focused on relating IA (information architecture) specifically and UX as a whole to the theme of ‘place’, and place making. Aside from her amusingly caffeinated story, she presented a hierarchy of terms to make sense of a given design challenge, and how to zoom in and out of that hierarchical framework to gain insights. Ecosystem to Object – from a simple object like a button up to a complex collection of systems like a large pharmaceutical company.

Hierarchy - making sense of place

Dude, Who Stole My Community
Charles Erdman led an interesting session that focused on how our developing technology and our dependence/addiction to it has effected our sense of community. From I Forgot My Phone to stories of how technology helped keep communities in touch during the recent Colorado flooding, he made some good points for designers to consider carefully when using and building future products and systems.

After orientation: making room for a novice UX designer
Megan Schwartz had a lot of really sensible things to say about how organizations can better support (and learn from) novice designers. Some of it was common sense (though not necessarily practiced in the workplace very often) but her insights into the ways novices can turn the tables and really help a company out were interesting. As a manager myself I took away some notes I intend to put into practice. Good job, Megan!

Excursion
I joined a gaggle of folks and we soon arrived at GRID70, a coworking space shared by a number of non-competitive companies with roots in Grand Rapids. Here’s the description:

GRid70 is currently the world’s largest experiment in coworking which brings innovation and strategy teams from Steelcase, Amway, Wolverine Worldwide, and Meijer together in shared spaces. This Excursion focuses on ways space can be designed to create the “happy accidents” of collaboration essential to fostering new work structures and inter-industry collaboration. The participants will engage in a conversation about Grid70 – what it is, how it works, and the challenges it addresses. The Excursion will culminate with an exercise to expand the concepts discussed and deconstruct a proposed experience solution.

First we talked about the space itself, the groups working there, and the mindset that brought it all together. Then we toured the building, poked around the collaborative workspaces, and generally grew quite jealous of their marvelous workspace. Finally we got back together and tossed around ideas on how to achieve a sense of community in Amway’s international physical storefronts – designed to be a coworking space, a distribution point for merchandise and a support structure for the independent business owners. It was a fun outing to be sure.

a walkway - brought to you by Dr. Whostickies as far as the eye can see

Keynote #2 by Christina Wodtke
Another well-known figure in the UX community, Christina had some nifty insights to share about Place. For one, stop thinking purely in terms of how you as a builder are creating spaces. Stop and think about how places make you. Places, communities, heartlands.

Another insight was to consider carefully how a user’s speed of browsing should be consciously designed for… on a social site’s homepage when NOT logged in, you might design for high speed ingestion – users will likely only see the page for a brief moment and can scan a well designed page quickly to find what they need. Contrast this with a comments feed from friends – this highly dense information must be put together so that one’s low speed browsing experience is optimized. If the internet is our new third space (since bowling alleys are nearly extinct and not everyone likes Starbucks), what is the internet’s heartland?

Saturday

In the morning, Christina chaired a panel (you’ll see what I did there in a sec) with design leads from Steelcase, Herman Miller and Haworth. Each had brought a chair with them (and sat on it for the duration) that exemplified the design philosophy their company was known for. It was rather cool seeing three competitors on the stage at once, sharing some challenges and some lessons learned that they found they had in common. Everyone in the crowd wanted those chairs… badly.

Lunch was served, and some of us chose to take in some quick lightning sessions in a format called Pecha Kucha. I caught three of them, and resolved to take part the next time we have a Pecha Kucha night in Knoxville.

Pecha Kucha

After lunch, I took in a thought provoking session about the Essence of Experience (Design can be dangerous), and another on how “The Place You’re In Is More Than The Place You’re At” by Phillip Hunter.

A takeaway for me was Phillip’s comprehensive list of different continuums – a sliding scale indicating ‘more’ or ‘less’, ‘hot’ or ‘cold’ as related to user experience evaluations. This isn’t a list of good and bad, just a way to think about a product or service to ensure you’re designing with the right factors in mind. Stay tuned for tweaks to this – I think he said it was still in beta 🙂

photo 3

Finally, the closing keynote began, featuring Karl Fast. I had the pleasure of sharing lunch with Karl and two other gentleman before the excursion to Grid70, and his insights into the state of UX education, MOOCs, and technology trends had me wishing we could have a longer lunch.

Karl’s talk led from physics to astronomy to electronics to biofeedback to data. BIG DATA is all well and good, but Karl exposed us to the idea that SMALL DATA is where we as designers can build experiences and leverage the growing sea of data to improve the lives of individuals, at a local scope, in real and measurable ways. He’s a great speaker and a very sharp fella.

The conference closed out with credit to volunteers, sponsors, organizers, and attendees. Lots of genuine applause and positive feedback – (I wasn’t the only one to feel like the logistics for MidwestUX were flawless.)

I had a blast. It felt so good to talk design and experience again with folks from all over engaged in all sorts of roles. Invigorating, exciting… like a Zest commercial with empathy and a sense of place.

On the way out of the city, I dropped by to say a sad goodbye to my new sweetheart: goodbye, MadCap. And goodbye, Grand Rapids! I hope to see you in Indy next year, MWUX!

Madcap latte

Getting back in the saddle

It’s been some time since I redesigned Minotaurdesign.com. (2006, to be precise.) It’s been my business site since I had a business (1999) and it has gone through intense periods of work with much love/attention being paid to it – alternating with periods of inactivity.

I’m now coming off several years of letting the website sit untouched. If it mattered, I could point the finger at a number of things: parenthood, juggling the duties of a part-time landlord with a full time job, and feeling a lack of creativity fueled by having roles that put increasingly less emphasis on DESIGNING vs MANAGING, to name a few. Regardless, regret at having let the site sit idle does no good – so onward and upward!

As I gear up for a substantial redesign and some strategic shifts in focus, I have to credit a number of factors when looking at what has moved me to action:

  1. Recruiters

    I know what you’re thinking… recruiters? aren’t they the underbelly of our working world, constantly pinging you when you have no interest and making statements and promises that simply demonstrate their lack of any real knowledge about your chosen field…? Well, that can be the case, certainly.

    In my case, being contacted by one of the most influential companies for me on both a personal and professional level was an eye opening experience. When Apple first pinged me (via a well known business social media platform) I thought it was spam. After a bit of research I found the inquiry to be legit, which led to a number of conversations with recruiters and hiring managers on the west coast. The long and short of it was that our discussions led to one recurring observation:

    They felt I wasn’t solely dedicated to the discipline of front end development, and that I (still) seemed to harbor interest in the design side of the web.

    After much reflection, I realized they were right. With a background in illustration & advertising design, with a large side of fine art – I had to admit to myself that despite a full time job with an incredible company, serving terrific family-friendly brands, and working with amazing people – in the end i could not say I was fulfilled by the roles I’d held in recent years.

  2. Old friends

    In the first few years of my professional career I was part of a rapidly growing company that built multimedia sales platforms for auto dealers and which eventually turned into doing websites for automotive OEMs and dealer groups. Our team was home to a group of truly talented, passionate folks – many of whom are still in contact today. 2013 brought some significant career changes to three of those very influential friends from the early days:

    • One fellow had been out of the loop so long he no longer felt able to get back up to speed and took a retail job to pay the bills. He despaired of every returning to the web industry. This was a gentleman to whom myself and other young folks had looked up as an early adopter, a pioneer – with many different skill sets and a daunting intellect.
    • Another close friend was a renowned expert in his field, and a published author several times over. He was a trusted source for guidance in many forums over a number of years, a born teacher, and a truly remarkable human being as well. This friend had been a full time freelance developer for more close to 10 years, but his chosen area of expertise began to lose relevancy and his work dried up. He had to take a corporate job, and he too felt the pinch of having let his skills in many areas fall out of practice – easy to do in a world where innovation and major shifts in accepted practices happen all the time. In conversations over the course of the year, I had to admit I was very much in danger of falling prey to the same kind of threat.
    • A third friend, who some would have voted ‘most likely to remain a no-good punk for life‘, instead went on to consistently make wise choices in the roles he took on and the contacts he made in the industry. He adopted an attitude of humility and eagerness to learn, and was rewarded by the well-earned regard of his employees, employers and peers. His path remained aligned with his core values, with the things he’d grown to value: open, clear communication, advocacy for the users of the products he touched, and the courage to call BS when necessary. This year brought an amazing opportunity for him and his family, and hearing the joy he found in continuing to pursue his chosen path was encouraging to say the least.

  3. Family

    My family has been supportive over the years – grateful for the extra income my work has brought in under the Minotaur Design banner and happy that I was content in my work. It’s been obvious in recent years that I was left somewhat incomplete by the roles I’ve held by day, and my family has urged me to indulge in creative outlets while remaining understanding when I didn’t feel I had the energy or will to do so. My wife and daughter are the subject in many portraits done over past years, and so too are they supportive of my desire to steer back towards more creative professional roles.

  4. Twitter

    I admit it…

    I didn’t really GET Twitter when it launched. In fact, I didn’t really get it for years. It didn’t help to have set my privacy settings to “Ostrich with head in sand” when I initially signed up.

    Not until somewhat recently did I awaken to the second-by-second stream-of-consciousness zeitgeist that Twitter had become. Taking part in active conversations with other designers, developers and assorted experts has been at once humbling and exhilarating. Keeping up to date via blog entries and published articles has gotten harder year by year, and I’m starting to see how much more accessible it is to use tools like Twitter to stay abreast of the always changing world of the wide, wide web.

There are so many more choices available today than when I last redesigned the site. It used to be you simply coded out your design from scratch, did some testing with friends, peers and prospective clients, and breathed a sigh of relief when it was done and you could get back to paying work.

These days there are a lot of factors to juggle:

  1. Goals: Are you building the site to get new business? To show off your chops in hopes of scoring a plumb day job? To demonstrate hard-won expertise and hawk your latest book, seminar or conference tour?
  2. Platforms: Are you building from scratch or Using a publishing platform like WordPress or Drupal and/or relying on a framework like Bootstrap or Foundation?
  3. Deployment methodologies: Are you pushing everything up to your server manually via FTP, or are you using advanced IDE software, employing enhanced workflows, and jumping through the hoops of Node.js, NPM and Gruntc?
  4. Stylesheets: Still writing your CSS the old fashioned way? Pull up a stool and skill up on dynamic stylesheets: LESS, SASS, mixins and varying levels of automation wired any which way.
  5. Speed: Do you have site performance in mind? Think it’s still enough to just watch the filesize of your jpeg files? Are you loading all your script and style assets for every page, or building things in a modular fashion and only loading what’s needed, ala Require.js, Yepnope, or LabJS?
  6. SEO: It’s not enough to have a nice website these days. You’ve got to have it set up so it’s searchable, relevant, semantic and well-liked (well-linked). You may even have to pay for some exposure – SEO isn’t enough, SEM to the rescue.
  7. Research: Operating on hunches about what your users are doing? No bueno. You’ve got to wire up your site to some analytics – get some real insight into traffic patterns, user behavior, and the effectiveness of your marketing efforts.
  8. Marketing: What, you’re not doing much marketing? Too bad, you just lost the first round. Many FREE and PAID options abound, from Facebook and Twitter to LinkedIn, Tumblr, Quora, Pinterest and more. Seperating the signal from the noise is part of the challenge, as is learning to employ your research in focusing your marketing efforts.
  9. User Experience: Great, you’ve got users on the site. Now, CAN THEY USE IT? Usability was a concern back in the day, but now it’s become an increasingly important discipline to practice, and one that relies on many of the prior factors – research primary among them. Is your content organized well? Does the visual design enhance or obstruct your message? Can your users follow the desired courses of action you’ve laid out for them? Are your objectives served by each and every choice you’ve made along the way?

All of this is enough to induce a case of decision paralysis – but I’m powering on.

I’ve finally rediscovered the passion I felt in the early days of designing for the web, and I can’t wait to find out what comes next.