How I work: Activities
Part 2 of how I work, describing the practices I’ve used throughout my career.
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.
Here is my summary, followed by each item in detail:
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
Audience research
Data analytics, directional A/B tests
No matter how much experience I have with a subject or an audience, I’m always hungry for data. Behavior is conditional and whether you’re searching for a problem or a solution—the answer can frequently be found by looking at data on hand. That may be from traffic, click/tap tracking, tests, polls, or otherwise. If it’s there, I want it. If it’s not there then we need to start recording it.
If there is no precedent for a new idea then I like running “directional” tests that are only capable enough to see if it resonates with an audience enough to put more effort into it. Finding out sooner can save a lot of money.
Polling, interviewing, focus group
With some types of questions, just asking people is the best way to get answers. Qualitative info can’t do a lot of things but it is great at getting sentiment, gut reaction, “why”, and “what would you expect to happen if you tap this?” about your product.
It’s also the best place to really understand on an emotional level, how my audience is thinking about it. Nothing is more convincing to even the least-empathetic among a product team than seeing and hearing a real person react to their work.
Persona creation/alteration
I make personas specifically for Experience. Often they’re made either for Marketing or Sales but those don’t contain the info I need for a product team. I focus on motivations and personality quirks — things that make them seem enough like real people that my team can make similar predictions about preference and understanding. I prefer to inform them with trending data but I‘ve also based them on team assumptions.
Problem and solution definition
Taxonomy and terminology
With all new and larger projects, defining this early can save a ton of money down the road in bug fixes and re-writes that never need to happen. Why? Because probably around 80% of what software engineers do all day is name things. If I come to them with loose idea of what everything should be called and files named oddly, they’ll default to writing code in either an overly generic or specific way. When things get better defined or rebranded later on, that usually only gets applied to the new code they write, because #fast-paced-workplace. They then have to mentally translate between the new and old names of things across areas of code. The result in that common case is a giant mess of code that is rife with bugs because it’s such a fertile ground for human error.
Outside of code, not defining this early can lead to metric tons of rework in other areas: documentation, advertising, branding, testing, etc.
I’ve found it’s best to avoid that by getting the names as right as you can as soon as you can; even if that means hounding co-workers for consensus on what the feature or product really is. An extra hour here saves days and weeks of burn rate later on.
Content and design strategy
A lot of the experience of a thing is a product of its tone, look, and feel. Sometimes it’s up to me to define that and other times it’s a collaboration. Either way we need to be running in the same direction with regard to the strategy because otherwise it can easily appear tone deaf to our audience.
I like to think about this as a person: pretend your product is a person that your audience is walking up to for assistance. What attitude do they have? How are they talking with your customers? How is “appropriate” for them to behave with your audience?
That person will either make your audience happy or drive them away. That person is your content strategy and I prefer it to make the audience happy.
Feature and journey maps
Having really gotten into these with my Agile work, I find them to be really great for strategic negotiation and planning on larger efforts. I’ve also added my own secret sauce in the form of MVP ➜ MLP ➜ RVP ➜ RLP. For anyone who hasn’t seen feature and journey maps, they generally look like this:
With my prioritizing scale they can look more like the following and serve as a realistic roadmap of features that a team can build toward.
Idea gathering
Trending patterns research
This can be finding patterns in unrelated realms or “competitive research”. In either case it’s about finding insight out in the wild. I’m a big proponent of cross pollination from seemingly different industries and fields. The more I’m exposed to different information, the more connections I make… kind of like A Beautiful Mind but without the schizophrenia (I hope!).
Charrettes and Design Studio
On projects where I need a lot of buy-in, I find it best to facilitate group activities where stakeholders materially commit to aspects of it. That way, differences of opinion can get ironed out without playing telephone and everyone feels more ownership in the end result. Besides guiding the session, this leaves me free to maintain focus on my design/po concerns.
“Gut testing” for look and feel
What’s more efficient than doing work? Showing other people’s work.
Whenever I’m in a situation where the possibilities are endless (brand new website, logo, etc.) I find a huge time saver in pinning down what resonates with stakeholders (or my audience) is taking a bunch of varied examples of finished work done by other companies, individuals, whoever and conducting a “gut check” session. I take the examples and have stakeholders mark up what they like, what they dislike, and why. If stakeholders disagree, they can work it out amongst themselves. When the dust settles I have a wealth of directionally accurate input that I can apply to the design I create.
Depiction
Describing what to build often comes in the form of a document—either static or interactive. I favor creating documents that are open, light weight, and version controlled for the following reasons:
- Changes are quick, as is starting from scratch.
- I’m not a bottleneck because anyone on the project can add to my documents.
- Good ideas don’t get lost in edits.
- Rolling back changes and removing mistakes is easy.
I also like doing what I call “two timeline design” for long term efforts. 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 us from feeling “lost in iterations” without creating the traditional, monolithic specs that are out of date before they’re even finished.
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 teams or stakeholders do not process wireframes well, I use something else like conversational sketching or jumping straight to mockups.
Mockup or prototype creation
The majority of the time, I find mockups are a great tool to communicate a design since they’re so approachable. It’s important though, 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 this can be the same work that ends up being checked into the code base and shipped.
This relates to another practice I call Trailing Documentation. It allows me to create non-code designs during or after a Live Design session, removing myself as a bottleneck. The product has my input and is shippable without delay, yet it has a design for future reference and iteration.
User testing
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. If the infrastructure is available, I prefer to test in three different ways:
- Short cycle tests
- Comparative cohort tests
- Impromptu testing (great for options that might have otherwise slipped through the cracks)
Automated user testing
People will always behave differently when they know they’re being watched but if you’re testing for the right thing, it can still be quite valuable. I’ve also had a good deal of success with screening questions, so participants can self-select into tests where they really do have some interest in what you’re showing them. It’s also quick. Within an hour I can often run a dozen testers through a concept or page and get results.
Interview user testing
When I need to test in a more open-ended or freeform way, interviews in an individual or focus group setting are appropriate. It’s a lot more coordination to set up and conduct but the insights can be more personal and take the tests in directions I wouldn’t have predicted.
Functional A/B testing
“User unaware” testing of 2 or more options in your product, particularly at scale, is a powerful tool for optimizing design options. It’s also the safest way to deploy changes. The results are as real as you can get and they’re especially valuable when contrasted against qualitative user test findings.
Standardization
Design system, style guide, pattern library
Pattern libraries can save a lot of time and fragmentation. As a centralized specification of how all the components behave, they can also make individual designs quicker to create and document.
While static versions are still useful, they’re really best when “live” and tied to the code base. Being able to ask a developer for “this widget (a named component) with this modification (light-weight design)” is a goldmine of streamline. It means wheels don’t get re-invented by accident, designs are consistent across teams, and the product itself can be consistent across teams.
Coding standards
Collaboration speed gets better when developers agree on structure, flexibility, and how self-documented code the is. This is another aspect of internally-facing experiences that are both important to me and beneficial for my team. I’m able to be more helpful when pairing and they’re able to deploy with less chance of bugs. Keeping people out of silos and able to pick up each other’s work at any time is incredibly valuable for highly capable teams—and those are the teams I most like to be part of.
More stories of how I work are available on my portfolio site.
