HobyVision

How I work

I describe myself as a UX generalist specializing in Agile principles. The following is a manifesto for how I approach design work.

  1. Starting projects
  2. Collaboration
  3. Collaboration methods
  4. Minimize work in a vacuum
  5. Appropriate documents
  6. Tests and studies
  7. Fun and games
  8. Inclusion
  9. Activity definitions

Starting projects

Every design project begins with determining my assortment of beneficial activities:

  • Persona creation/alteration
  • Analytics research
  • Polling research
  • Trials research
  • Trending patterns research
  • Charrettes (aka, Design Studio)
  • "Gut testing" for look and feel
  • Taxonomy/Terminology definition
  • Content strategy definition
  • Feature mapping
  • Journey mapping
  • Look and feel outlining
  • Low fidelity wireframing
  • High fidelity wireframing
  • Redline annotation
  • Mockup creation
  • Prototype creation
  • In-code design
  • Style guide creation/alteration
  • Pattern library creation/alteration
  • "code" standards (css, html, etc.)

Which items suit this new project? I pick the ones that do and begin.

Collaboration

For collaboration I consider how much access I have with my:

  • team members
  • community of practice
  • stakeholders
  • customers

I've found the greatest success when communicating in this priority order:

in-person -> video -> phone ->  messenger -> email

From there I try to determine the conversation to documentation ratio:

  • Less contact = high documentation & low conversation
  • More contact = high conversation & low documentation (preferred)

Historically designers and researchers mainly communicated through deliverables of documentation. Now I've found conversations should lead and documents should record decisions, while working solutions are the only things that deliver business value.

Collaboration methods

I'm very much into pairing and working sessions, focusing on doing as much creative work as possible with more sets of eyes on the results than my own. Pairing to me is myself and another person focusing on a task for one or more sessions, usually in short chunks because of their level of intensity. Working sessions are similar but between a good working group size where the object is to end these typically longer sessions with saved results instead of todo lists. Within either session, some kind of actual work should be completed: code checked in, documents created, edits performed.

Why do I do this? Whether these activities are cross-functional or within a community of practice, I've found that closer than comfortable collaboration increases several things at once:

  • Productivity
  • Quality
  • Collective ownership
  • Mutual understanding
  • Predictive teamwork
  • Sustainable pacing
  • Skill sharing

While it can feel awkward and counterintuitive for people who haven't taken part in this style (as I've written in my Cross Functional Pairing article), the benefits can be astonishing. We get a lot more done and we do it better as time goes on. The urge to continually improve is a strong motivator for me and it can happen very quickly when collaborating.

Minimize work in a vacuum

I try to minimize upfront work as much as possible. I favor employing an Agile UX Practice I call "two timeline design", where I create a fuzzy over-arching vision in parallel with a series of sharper, iterative portions of design or research.

As the iterative chunks get solidified, the vision gets progressively detailed. It keeps the designs or studies nimble and sufficient for when they're needed.

Appropriate documents

I favor creating documents that are:

  • Open
  • Light weight
  • Version controlled

Keeping documents light weight, open, and version controlled makes them quick and easy to re-create or change on the fly without worrying about good ideas getting lost through edits. Starting from scratch is no longer a burden. I'm not a bottle-neck because anyone on the project can edit my documents. Rolling back changes and removing mistakes is easy, particularly between multiple team members.

Another practice I like to use is what I call Trailing Documentation. This allows me to create designs during or after my collaboration session with a team member. In doing so, I remove myself as a process bottleneck and often record more accurate designs than could have been done the traditional "design, implement, review" method. My design is correct and product is potentially shippable with no delay.

Tests and studies

If the infrastructure is available, I prefer to test in three different ways:

  • Interpreting always ready and running tracking data
  • Conducting short cycle tests
  • Maintaining a cadence of impromptu testing

A lot of the time decisions need to be vetted against some measure of reality and when analytics aren't being captured to bounce those questions off of, team decisions must be based on assumptions—which can sometimes be disastrous. So I've found it works better to gather basic data in an ongoing basis, limiting new (single instance) tests and studies to find results for questions that fit within a sprint iteration. The impromptu testing is great for testing things that might have otherwise slipped through the cracks and keeps everyone thinking about what can be tested and what aspects we're still curious about.

Fun and games

I've recently taken on the practice of using interactive activities and so-called innovation games to encourage constructive participation. From varying the format of retrospectives to adding something like The Perfection Game or The Anti-Problem to a meeting—using a protocol can work wonders for moving work forward in a positive direction. Some can loosen up a difficult process and some can turn a long serial activity into a parallelized quick activity. Presentations as well can benefit from interactive activities, just for communicating ideas more effectively. Another great aspect I've found is that once a group tries them, everyone involved often learns enough to be able to re-use these games whenever needed.

Inclusion

I like to include people that are often excluded from product creation activities. When important things are being formulated, I try to pull in people from at least all three sides of what I call the "success triangle" of Business, Technology, and Experience. That may be a PM, a developer, and myself. That could be a marketer, a QA tester, and a customer. It could be a wider group with many other roles. The point for me is to get early insight from people with subject matter expertise so we can make effective, collective decisions without wasting a lot of time and money. I like to enable transparency as a way of working that decreases overhead while we bridge divides.

Activity definitions

Going through the first list of activities, I've found that my version of these (sometimes) commonly used activities can be different from how other people approach them.

  • Personas - I make them for product teams, not for marketing, so I focus on motivations and personality quirks—things that make them seem real without spelling everything out for my team members. While I like to inform them with trending data, I often start making them after interviewing people on the project about who they think they're making the product/service for.

  • Analytics, Polling, and Trials - These three kinds of research are good at finding out different things for different purposes, all of which are usually valuable at some point. Analytics I consider "user unaware" information gathering such as click tracking, mouse tracking, and other forms of in-product recording that focuses on natural behavior patterns. Polling to me is anything where the person is aware that they're being studied: focus groups, surveys, and usability tests are all good ways of learning about peoples' self-professed thoughts, emotions, and desires. Trials like A/B tests, navigation tests, and similar are my favored way of letting the user/customer choose between design options. In the presence of too many good ideas, something has to be done to pick a single way forward and trials are often the answer.

  • Charrettes - I like to include a healthy cross-section of people and role hierarchy in these group settings. My first purpose in facilitating these kind of sessions is to gain some measure of collective buy-in and hopefully ownership—so it makes the most sense if I can get people as far up and down the chain as possible to participate actively. The result should be about design but the ingredients are usually about priority versus feasibility. If everyone can work this out as a group, that allows me to maintain my own focus on advocating for the user/customer instead of acting as a pinball between people who should be talking directly.

  • Taxonomy/Terminology/Content strategy - I stress the importance of this early and often. If I'm not able to for whatever reason (and there are many), I find that a lot of overhead is wasted by a history of terminology decisions being baked into different layers of the project's code, documentation, business docs, accounting, branding, and other areas. Cumulative weeks can be spent as people day by day, minute by minute are translating between these project parts in order to create new portions or re-write existing ones.

  • Wireframing - To me wireframes should be low fidelity. The focus should be on the information architecture and avoid anything shiny or pretty that could distract the team from making good decisions about what elements should be promoted and what flows contain the best balance of elements. In times when my team member audience does not process wireframes well, I avoid this tool and opt for something else like conversational sketching or jumping straight to mockups. To some people, production fidelity screen designs arranged in versions or flows still means their wireframes—but I consider those to be sets of mockups.

  • Mockups and Prototypes - Often these are a great tool to communicate a design but not always. It's important that I keep an eye on the point of diminishing returns: Is the work I'm doing to mocking up or prototyping this feature actually saving the team time and money, or is it creating a lot of work with no business value?

  • In-code design - Sometimes it's more efficient or effective to design in whatever the development environment is (html, an SDK, etc.) to communicate the design. In the case of what I call "live design" then that can be the same work that ends up being checked into the code base and shipped.

  • Pattern guides and libraries - In their best form of Live Style Guides, pattern libraries can be more precious than gold for keeping document weight down, team consistency high, and friendly widgets in use. Being able to tell a developer, "I want this widget (pointing to a named widget) with this modification (showing a light weight design sketch) in that screen. Here's the small bit of code and usage notes to start with." can make the difference between hours and months of a new feature getting completely done.

  • "code" standards - Attention to User Experience extends in all directions for me and one of them is the experience of working within the code. By code I mean anything from "actual" code like java to markup and things like CSS and HTML. My favored style of setting up how these different things interact is around "self documentation" and "mix and match flexibility". Names of things should tell you what they are without being too wordy. Page elements shouldn't be too hardened style-wise by their function—but assembled through a balance of style archetypes defined between the CSS, HTML, and JS. I also appreciate the value of using LESS and SASS to reduce working in expanded redundant code.

In a nutshell, that's basically how I work whenever possible.

Google+
LinkedIn
{{ message }}

{{ 'Comments are closed.' | trans }}