How I work: Principles
This is my mental menu of principles that define how I approach Experience Design and Agile work.
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.
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.
Another aspect I think is critical, is digging below the surface to uncover what I call ‘core goals’ and ‘after effects’. For anything that isn’t a simple fix or test, I like to find out what’s beyond the immediate effect or known goal for the audience—investigating the reasons behind why they want something and what happens further down the road. What audience behavior might this design do as a secondary side effect? Is it a positive or negative behavior?
I always try to address the core goals and nurture positive after effects.
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.
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. You can find project stories on my portfolio site.
