Solve Problems with Design

The panel “Driving Customers towards Modern Design Excellence”, with Alexis Allen, Henry Wang, Jake Johnson, and Ronnie Rios from Claris guiding the ship, dove right in and delivered. After a few quick trips down the “What is design?” rabbit hole, and then circling around the subject of how to convince customers to pay for design, the conversation posed an important key question for custom software development:

“As a designer, how can I help an
organization manage change?”

The question doesn’t have a neat and tidy answer. Since this was a panel discussion and not a formal presentation, we got to hear a shotgun of opinions from Alexis, Henry, and Jake, and while they each had their own take on the process, they agreed on a few key bullet points:

1. Empathize with your customer.
2. Get to the why.
3. Involve your customer in a well-defined process.

Empathy

If a customer with an existing software app comes to you for help, they have an awareness that their solution has a problem (or perhaps many!), and a desire to fix it. By definition, they are looking for change — they just may not be able to articulate it. The problems can seem large, never ending, and overwhelming. As a consultant, and a designer, part of our job is to help identify the key pain points so we can unlock solutions.

To be able to develop creative solutions to problems, we need to empathize with our customer, and that means we need to truly understand their emotions. It may seem weird to think about emotions when talking about software design, but the individuals, teams, and organizations that get this aspect of design right, have historically achieved great things.

User stories help bring empathy into tangible, actionable form. They often follow a specific pattern: “As a <persona>, I want to <do something>, so that <reason>.” We don’t necessarily need to use this language with our customers, but this is an easy and effective way of using empathy and good listening skills to get to the why of the problem.

Why, not What

I think Alexis said it best when she mentioned that at this phase of a project, it’s important to adjust your thinking. From her perspective (and I have seen this myself), a customer will often just demonstrate their use of the existing system and narrate what they’re doing. Alexis said, “I don’t want to know what you’re doing, I want to know why.” If we can get to the why, we can solve the true friction; if not, we can easily get stuck in the mechanics of the legacy process.

Process and Customer Involvement

Though there was never a moment where any of the panelists said, “This is the process” and then proceeded to list off the bullet points, I was able to piece together the key points that they agreed upon.

1. Identify the key User Experience (UX) issues.
2. Demonstrate an understanding of those issues.
3. Share a prototype or sketch of a proposed solution.
4. Iterate if necessary, then build.

All three panelists advocated for an iterative approach to solving problems where the most troublesome issues are dealt with first. If you can identify the areas of a solution where there is the most friction, or a process that takes far too long, focus your attention on that one area or process and seek a solution.

Demonstrating an understanding with user stories, sketches, and/or prototypes doesn’t have to be hard. These prototypes don’t have to be high fidelity, and in fact, it might even be better if they’re low fidelity paper sketches. Jake is a fan of Apple Pencil and iPad and also Sketch for more high-fidelity prototypes. I have used Sketch and InVision to build interactive prototypes to great success, but I’m also a huge proponent of paper prototypes because they’re “throwaway”. As a designer, you’ve got very little invested in them, and consequently your stakeholders will have no problems raising concerns. Engage with your customers and iterate towards solutions.

Summary

My big takeaway for this session was Jake’s comment about empathy. You can’t solve problems if you don’t truly understand them. Designing quality software solutions isn’t a solo operation, it’s a collaboration. Utilize user stories, seek the why, use paper prototypes, seek feedback frequently, involve your customer in the process, and:

“Don’t design alone.”