How I work

This is my mental menu of principles and activities that define how I approach Experience Design and Agile work.

Photo of balance by Valentin Salja on Unsplash

Principles of work

Principles are what I use to ground my decisions. I ask myself, “Will this activity support one or more of my principles? Can it do so without detracting from any? If so, is the trade-off worthwhile?”

  • Collaboration
  • Learning
  • Validity
  • Transparency
  • Focus
  • Automation
  • Fun

The best thing I feel about these principles is that there can be a great deal of interplay to enable one another. For instance:

Transparency + Automation = Focus

Transparency ➜ Collaboration ➜ Learning

Using these allow me to optimize the work to be done. That means that I can spend more of my time and capacity on that versus… all the other time consuming things people fill their work days with.

Doing something for the sake of doing it is an empty venture. If your goal is to deliver value, what you do should have a purpose that you personally value. Protocol and process should only exist to benefit a team. If a process isn’t working for people, it should be either improved or dropped.

Where the felt meets the whiteboard

Menu of activities

For design projects, one or more of the following activities might be appropriate. For some of the most ambiguous and high scale projects, all of them might be necessary.

How do I decide what is a good idea for each new project? I usually draw from experience but sometimes I just go out on a limb and try a different approach to see if it has some benefit.

When I encounter similar projects I’ll formalize groups of practices that can form a protocol: if it seems like “Project X” then we should do activities C, G, and H again.

Audience research

  • Data analytics, directional A/B tests
  • Polling, interviewing, focus group
  • Persona creation/alteration

Problem and solution definition

  • Taxonomy and terminology
  • Content and design strategy
  • Feature and journey maps

Idea gathering

  • Trending patterns research
  • Charrettes and Design Studio)
  • “Gut testing” for look and feel

Depiction

  • Wireframing
  • Mockup or prototype creation
  • In-code design

User testing

  • Automated user testing
  • Interview user testing
  • Functional A/B testing

Standardization

  • Design system, style guide, pattern library
  • Coding standards
I explain menu of activities in greater depth within:

Principle details

Principle concepts might mean vastly different things to people. A term can be loaded with baggage, be unclear, or have no practical meaning for an individual—so I think it’s important to define them.

Collaboration

Working as a group is complex and not something that has universal cultural support. It’s not part of popular education and is not celebrated in most of society. It is however, necessary to build most things.

In a basic way I consider collaboration as how much access I have with my:

  • team members
  • community of practice
  • stakeholders
  • customers

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

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

I’ve found the greatest success when communicating in these priority orders for conversation and documentation:

In-person > video > audio > messenger > email
Working code > prototype > mockup > wire > outline
Pairing > sketching > chatting > planning > reviewing

When I’m working on the left side we usually get a lot more done. When I’m over on the right, sometimes nothing really happens. Always remember that working solutions are the only things that deliver business value.

Learning

I consider learning to be central to doing anything new. I even consider it central to being human. Without the spark of discovery, the satisfaction of knowledge, and the pain of identifying failure—I would surely wither and die. So doing things to learn is important on many levels.

Validity

I’m someone who gets a lot of value “seeing for myself” in because it can bring clarity to problems and solutions. For example:

  • When working on mobile I’ve always mirrored my designs to devices (target or minimum) because I know it looks and feels different on device.
  • One time there was a problematic page component detail that I’d been told needed to stay there because of a contractual obligation. After my and other teams had struggled to keep this in our designs I decided to ask the sales team for copies of our actual customer contracts. Low and behold, it was NOT in the contract. This allowed me to streamline the design.
  • Co-workers may say things like “[company x] tried that and it did/didn’t work for them.” or “I think we tested something similar.” and while it’s great to get insight from previous work—it doesn’t mean things will be the same for this time and situation. When I either look at the previous work in detail or run a new test, I’ll often find that my results are different or that the previous test/results are in fact not what I was lead to believe. There’s nothing wrong with that; it’s just how science works.

Transparency

I define transparency in a fundamental way. I do that because honestly I find that it’s easier to work in a transparent fashion than a guarded one. It saves me time and effort I’d otherwise have to put into implicitely sharing things.

I’m not much for showmanship, sales, or The Big Reveal. It’s not that I don’t appreciate them—I’m just terrible at performing them. I’m also not interested in spending much of my time preparing material to describe the work I’m currently doing.

My answer to all this is doing work in ways that are inherently transparent.

  • Calendars, files, tasks, and boards I set so members can see and modify.
  • I’m an early adopter of Figma (think Sketch in the browser meets Google Docs) in which people can literally open design files while I’m working on them and watch my cursor flit about. #Exciting.

Anyone who’s interested in learning about or collaborating on my stream of work is free to do so. We are after all, on the same team. If we can’t trust each other with seeing and editing work in progress then we really have no business working together.

Focus

As time goes on, I think more and more things are possible and too many things are uncertain. We increasingly encounter paradoxes of choice that make us grind to a halt. Not just the answers but very often the wealth of potential problems are difficult to pin down.

Activities that enable digging into or narrowing down on choices are things I like to do. Practices that encourage self-discipline and critical concentration are essential to coming up with clear thoughts and well-crafted solutions.

Focus is also an important part of inclusion. Isolation and overcrowding are not as productive as focused collaboration. I like to at least form what I call the “success triangle” of business, technology, and experience. Beyond I’m careful to keep the group small if the point is to accomplish work.

Focus is essential for delivering towards a goal, no matter what kind of distractions are present.

Automation

Hopefully it doesn’t tarnish your view of my work ethic but I’m fully of the mind of not spending my time doing anything that could be automated. If a computer can do it then it SHOULD do it. It will probably happen faster and without mistakes. It also means that I don’t to spend any more of my time, effort, or attention on the task. It’s magic.

Some ways I’ve manifested this:

  • I maintained my own Sketch plugin for cleaning up PDFs of captured web pages. What manually takes me around 2–3 minutes gets done in just over 1 second with the plugin. Booya.
  • At a company that was using a work tracker that couldn’t really deal with charting, we were plotting burndowns with pen and paper until I set up Trello + addons to display a live-updating burndown chart.
  • When the Anima plugin gained support for its Stacks feature, I started using it for content-heavy designs where the order and size of content blocks continually change. This saved me cumulative hours of time I’d otherwise be spending moving and nudging blocks to regain proper spacing and margins.
My main tool of automation

Fun

Depending on where you work, fun can be the least attainable principle. It’s also important for motivation, participation, and feeling like a team. I look for ways to make things fun while working but I know especially from Agile coaching that setting aside time for fun isn’t a luxury. It’s actually something you need to do regularly to maintain your team. Without doing things like innovation games and off-site activities—my co-workers get less motivated and less attached to their team(s).

Most places I’ve started small with protocols like The Perfection Game and activities like The Anti-Problem to get things moving forward in a positive direction. Fun can loosen up a difficult situation and can also provide a more productive way to get things done. Tasks that benefit from parallel group activity are good candiates for being “games”.


Not sure what I mean by some of the Activities? I define those in my followup story How I work: activities in detail. You can find project stories on my portfolio site.