A Design Practice

Over the course of my career, a framework has started to come into view for a establishing or augmenting a design practice.* The framework has three key ingredients:

  • Methods: What do you do?
  • Infrastructure: What do you use to do it?
  • Personal Growth: What are you getting out of it?

Attention to these three areas provides a foundation that is both flexible enough to work in organizations of different sizes and workflows, but clear enough to stay relevant under different methodologies.

Methods

“What do you do exactly?”

This is the collection of executional tools we have at our disposal. This includes typical UX activities like card sorts, personas, prototypes, and critique, among others.

  • Specific executional methods: typically the work that goes into design deliverables;¬†personas, prototypes, card sorts, sketches, etc. There are dozens of options, appropriate at different stages in of a given design project.
  • Participatory methods:¬†tactically-focused exercises such as kickoff meetings, research interviews, sketching sessions, etc.
  • Processes: Executional activities and their resulting output is bundled into a process such as a Design Sprints or Lean UX sprint schedules, which provide a linear path for interactive discovery, design, and validation.

Infrastructure

“What do you use to do it?”

This is typically what we would refer to as design tools; the software, team structure. But this concept goes further to include conceptual infrastructure like design principles that provide thematic support to all the aforementioned methods.

  • Organizational infrastructure: team organization through clearly-defined team structure and roles–there’s a lot more to this, of course.
  • Technical infrastructure: software such as design and prototyping tools, file sharing, communication platforms, all of which facilitate the delivery of good work; also, reusable technical assets associated with style guides, templates, patterns.
  • Facilitation infrastructure: provided through the use of meeting agendas and other materials that are re-used in workshops or other sessions–key for healthy engagement with stakeholders
  • Thematic infrastructure: tenets such as principles, values, and methodology; tools that guide the team through tough decisions and elevate the team’s thinking around solving challenges. Principles are the outcomes we seek in the work we create. Values are describe how we want to work. Methodology is the school of thought that ties together the methods at use on a project.

Personal growth

Everyone on the team is advised to approach every project as an opportunity for personal growth. I have found, historically, that not very many people look at their work this way, as an opportunity for growth. But those who do benefit both personally and professionally.

“What are you getting out of it?”

  • Preferably, this starts with an introspective self-assessment to understand an individual’s strengths and weaknesses and understand the need for addressing these opportunities
  • Each project should be evaluated as a growth opportunity
  • What opportunity do you have to improve your “on-screen” skills, the nuts and bolts of the design process?
  • What opportunity can you find to improve your “off-screen” skills, your ability to work with stakeholders through facilitation, active listening, salesmanship, critique?
  • Not every project has to be a growth opportunity, but we keep revisiting this as a means of maintaining that trajectory

Putting it in motion

High-quality design methodology, both in process and execution will always be critical to any high-functioning team. An efficient infrastructure liberates the team members from the burden of re-building and wrangling repeatable assets, cuts down on variability and error within the product experience, and removes the cognitive burden associated with smaller design decisions from the team while the work is in flight. But none of this is worth doing if it is not a vehicle for one’s personal growth. We spend more of our waking day working than anything else and it should ultimately be a nourishing and rewarding experience.

So I’ll leave you with a hypothetical example of how a team would carry this through when starting a project.

Let’s say you start a project with a kickoff meeting (method). In this practice, the team would have a pre-set agenda for a kickoff meeting (infrastructure). The agenda had been tuned over time to assure that three criteria were met:

  • Define the problem space and objectives
  • Select design methods
  • Make a commitment to complete the work

In the kickoff, the team works together to get a sense of what they need to do for the project. They refine and agree on a problem statement (method) and an objective that they aim to meet (method).

Next, the team assesses what methods they want to use to reach that objective. Is field research the best way to get the qualitative data we need? Is there existing data from our analytics platform? Is Should we do a sketching session with the team to develop a direction for a prototype? Should we use the Design Sprint methodology for this problem?

Finally, there is some assessment of the path forward, an estimation of how long it will take and, based on the needs of the project and the strengths and weaknesses of the people on the team (personal growth), a determination of who should do the work. So, if it’s a mobile app project and a associate designer is looking to expand their repertoire with mobile, they could take the project on with a commitment from a senior designer to advise and mentor along the way, helping them ensure that the aligns with the team’s values and the work is in line with the team’s design principles (infrastructure).

Naturally, once the team adopted this perspective, all their dreams were fulfilled!

*Sometimes this is called DesignOps, and that’s cool with me, too.

Leave a Reply

Your email address will not be published. Required fields are marked *