Help your team define design goals
Every startup struggles with communication as the company grows. Different branches work in isolation and while part of your job as a designer is to keep Product, Success and Sales teams on the same page, chances are your Slack #design channel is just you posting screenshots of things already in development.
But how do things get to development? Are features we build even valuable? Aren’t we wasting time building stuff no one cares about? Teach your team to frame design goals correctly. Start with “what’s the problem?” and continue with “how can we solve it?”
“Build me a bridge” vs. “I need to cross the river”
Variables will differ but the biggest mistake your team can make is to build solutions without understanding the essence of the problem. To frame design goals is essentially to define the problem your users have and to avoid wasting time and resources on fixing things that aren’t broken.
Don’t think about what your users want — avoid treating symptoms. At Onfleet, our Success team provides us with weekly updates on most pressing issues from our users. 80% of those include some sort of a user-proposed solution.
“If I had asked people what they wanted, they would have said faster horses.” — Henry Ford, allegedly
How do we improve our product when all we have are faster horses requests? We break those down. How you do that exactly varies based on how much information you have: user’s activities, environment, interactions, objects she interacts with and then the user herself (something we call AEIOU framework). Regardless of the research you do, you should end up with the essential problem the user is experiencing you can frame as follows:
X can’t Y when Z (because W)
Let’s take a look at a couple of examples. Onfleet is a B2B logistics company that provides businesses with a fleet management tool for local deliveries. These are real issues found in our Zendesk support queue.
- Can we get the driver icons to show-up in different colors so we can differentiate them when viewing their status on the dashboard map. I know that the different statuses have different colors but differentiating the drivers would be very helpful. Or perhaps the icons should show their initials.
Dispatcher can’t differentiate drivers when overlooking fleet activity - Is there a way to set automatic nags for tasks that haven’t been started in X mins? Or is there a way to manually nag couriers about not starting a task? This would be amazing to have as we constantly contact couriers about this. Many times they don’t hear the first notification.
Driver doesn’t realize a new task was assigned to him - For our service, it’s really important that our drivers complete their tasks in the order they were received. Unfortunately it’s easy for a driver to accidentally select a task from the middle of the task list or tap the push notification which directs them to the last task sent.
Driver can’t easily figure out which task to start when given multiple tasks
Defining the problem is just the beginning, examples above can be solved a hundred different ways, but breaking it down makes sure you don’t spend time fixing what isn’t broken.
Teaching your team how to properly define design goals not only makes it easier to set goals for the development team but also promotes design thinking and better communication throughout the branches of your company. Your Success team will be able to give your users a more accurate time estimate for new feature releases and your Sales team will be pushing for quick valuable improvements that will bring in new customers.
What do you do to keep all of your team engaged in the development cycle from start to finish? What does your Slack #design channel look like?
