“Can you tell me about your design process?”
I have been a designer at seven different companies over the last 20+ years. Each of those companies differed in size, industry, and design organization maturity. The design budgets and organizational buy-in were also very different. Out of necessity, I have never been able to have the same process at two companies.
If you want to nail me down, sure I have a process I strive for. But at this point, it is still completely theoretical to me. I’ve never worked on a team that has been mature enough to take on the challenge. Some have gotten close, others it’s more like a north star. It can point us in the right direction, but realistically the company would have to go through significant transformation of values and leadership before a commitment could be made.
Despite this, at every company, I have made significant headway in helping to mature the design organization. I have achieved this by meeting them where they are at. I foster design maturity by giving them a process that will push them, but is achievable.
Focusing on principles as opposed to process is a much more beneficial conversation. Principles can be applied regardless of differences between organizations. The trick is finding out which values to focus on and how to best apply them in that circumstance.
The needs of the many outweigh the needs of a few.
I have worked at several companies that had a problem saying no to “that” client. You know the one I am talking about. They are one of your largest accounts and they know it. They hold it over your head in order to get what they want. If they actually are keeping the business afloat, in the short term, it might be necessary to appease those clients. If you are not careful however, it will ruin your chances of long term success. You will end up building a product that only appeals to a single customer as opposed to the whole market.
Ideally, we will never design a feature that applies to only a handful of companies. Unfortunately, sometimes financial motives put us in non-ideal circumstances. In those cases, it is vital to design the feature in a way that it won’t impact the experience of your broader user base. Just adding one more thing to the page ends up building up over time and isn’t sustainable.
Great Ideas can come from anywhere.
I have observed over the last two decades as design has grown and changed. I have paid attention to design patterns. I have watched users interact with software and witnessed first hand things that work well and things that don’t. In short, I have trained myself to come up with solutions. Despite my immersion in design, I contend that it is entirely likely that the best ideas might come from someone else. Each one of us has a unique background, that is processed by a unique cognitive style, that creates a unique perspective on the world. Sometimes it takes the right person, aligning with a specific problem, to spark the best idea.
I welcome ideas from everywhere. Most ideas aren’t great, but every now and then, brilliance shines forth. One of the ways I have found to implement this into a design process is by facilitating Design Studios.
Build a shared understanding and empathy.
The chances of others coming up with a good solution increases dramatically when they have an in-depth understanding of the problem to solve, and the people we are trying to solve it for. There is no better way to gain empathy than having a first hand experience. When they do gain empathy, they are motivated internally to do what they can to help our users. Inviting a developer to observe someone use what they built can be an empowering experience for them. They have ownership over what they built, when they see someone struggling with it, they naturally start thinking about what they can do to help. Their in-depth understanding of the technology places them in a unique position to identify the easy fixes.
Research is a shortcut to success.
Course corrections are times in which we are able to learn something and make positive changes to point us back in the right direction. A natural course correction happens when we launch a new product or major feature. If no one is buying or using it, it’s a clear indication we misjudged something. Rather than waiting for something to fail naturally, what if we force it to fail sooner? The sooner we recognize we aren’t on the right path and make a course correction, the less time we waste going the wrong way. Everytime we gather a piece of data we are forcing a course correction, ensuring we waste less time heading in the wrong direction. It might take a little longer to release code, but that’s not really the goal. Our goal is to solve our customers problems and that will happen much sooner when research is involved. More on this in the next section.
I value outcome over output.
The focus on deadlines and dates often causes people to lose focus on what we are actually trying to accomplish. We start measuring success by how many lines of code we can write or how many features we can release. We make an erroneous assumption that the product and features we release (our output) is directly related to our users getting value from it (the outcome). This is certainly not the case. The definition of done shouldn’t be when we have shipped the code. We are only done after we have validated we are providing the value to our users that we set out to provide.
Let’s get out of the deliverables business.
I know that I am going to be most effective if my efforts are focused around one of these three activities: Building, Measuring, or Learning. If I am spending more time creating documentation, I am not spending my time doing things that will provide the most value.
In my view, deliverables serve three primary functions: planning for the future, communicating to the team, and providing a historical record.
Planning for the Future: We can reduce planning documentation if we aren’t planning too far into the future. We plan on making many small incremental course corrections as we build. That means that we know where we are going, but we don’t know how we are going to get there. We only plan as far ahead as we can see.
Communicating to the Team: I have often had a difficult time getting people to actually do anything more than skim documentation, and even that was a challenge. When we work in small teams, on a specific project, we are able to build a shared understanding on what we are building and a shared empathy for who we are building it for, the need for detailed documentation drops significantly. Additionally, I value conversations over documentation. It seems to be a much more efficient method of transferring knowledge; you can tailor the message to the needs of the individual.
Providing a Historical Record: Information has a half-life. The further into the future we go, the information collected today is of less and less value. Information in the short term doesn’t really necessitate documentation as our collective memories work relatively well in the short term. But as time passes, people move onto new teams and the memories of people that remain with the team become foggy. It’s generally very hard to predict what information today will be useful in the long term. It’s impractical to document everything in the hopes that one day it will be useful, when we know that with every change we make, that information is less relevant. We should only document things when we have a specific reason to believe it will be worth our time in the future, knowing that most things won’t.
See a pattern?
If you haven’t noticed by now, I generally stick to Agile and Lean principles. I believe working on small incremental changes will create more immediate value than one big release with less disruption to users. I like working on small teams with a dedicated mission. I prefer rapid iterative testing and evaluation (R.IT.E), when I see a problem I fix it.
“I am still waiting to see your Process.”
Still stuck on that, huh? Ok, I’ll give you a taste. The process I look to as an ideal is based on “Directed Discovery” developed by Nate Walkingshaw. Here is a diagram I built while evangelizing the UX process at one of the companies I was working for. Reach out, I would love to walk you through it.
