The Power of Design Thinking for Technology Projects

Technology loves to pull you into the weeds. It tries hard to distract. If you’re planning a new website or software project, Technology wants to drag you down into specifics where it thrives on creating documents with loads of bullet points that list features and functionality requirements. But do those bullet points actually solve the issues that brought you to the project in the first place? It’s painfully easy to fall into a feature trap that forgets the very users you’re building the project for!

Utilizing a concept called Design Thinking is a great way to flip the script and short circuit (no pun intended) technology from getting in the way of the project goals.

What is Design Thinking?

Design Thinking favors a user-centric design approach that puts people over processes, prioritizing the needs of the people who will be using the project above all else. Though “Design” is in the name, it’s not just about the aesthetics of the project. It’s about bringing design, business and technology teams together to create a cross-functional team that can share ideas and insights on how to make the user’s experience better.

Often on larger projects you will have different teams within your association that have differing mandates, objectives and visions for the project. When used effectively, Design Thinking brings those teams together with all stakeholders collaborating, voting and unifying under a single vision. This framework generates user-focused big ideas and solutions while avoiding the trap of focusing on features that are tactical and more focused on the machine.

Design Thinking: Step by Step

The framework for Design Thinking can be tailored based on the organization and project. For this article, I’ll talk about how my organization uses Design Thinking for most technology projects. As the saying goes, “your mileage may vary!”

The typical workflow for a Design Thinking technology project includes:

  1. Project rundown with stakeholders
  2. Team creates user personas and empathy maps
  3. Teams creates ‘as is’ journey map
  4. Ideation phase: brainstorming, user scenarios, storyboards
  5. Team creates the ‘to be’ journey and experience map
  6. User stories are prioritized and product backlog created

Rundown:

Creating a basic explanation of the project from the team’s perspective. Determining who are your primary users? What are the problems today? What should the user’s ideal experience be? How will the project create value/opportunity for your association?

User personas

Developing an in-depth look at your users. Who are we building this for? Get specific. Categorize them. Create empathy maps to gain a deeper insight into what motivates the users and makes them tick.

The “As Is” Journey

Defining all the steps of the current user process/journey. List the actions, questions and pain points along each of the steps that a user experiences. From the pain points listed, ideate and brainstorm on opportunities where the user’s journey can be more intuitive and engaging. Each stakeholder participates.

What are the big ideas we can think of to solve the pain points? Ideas are collated, voted on to agree on which ideas would be the most impactful and feasible.

User Scenarios and Storyboards

The team imagines the ideal future experience and describes the user’s behavior once the big ideas are implemented. Help align the team by having each member explain what the big idea means to them. If the team has broadly the same understanding of the big idea, then their stories will look similar, but the specific way each member envisions it, or even just the language they use will help find subtle variations.

“To Be” Journey Map

Though this looks similar to the “As-Is” journey map, this time it’s a future statement, breaking down the tasks we want the users to be able to achieve across the board.

Experience map

Based on the “To Be” Journey, product features are cataloged, prioritized and placed into a Product Backlog and from there detailed and accurate time estimates, release schedules and scope of work requirements can be created. Here is where you are allowed to get into the weeds!

We’ve used Design Thinking on a few projects now and the results are powerful. It forces you to think strategically from the user’s point of view and not on the technology. Here are a few lessons we’ve learned along the way that might help:

  • Make sure that ALL the stakeholders are in the room (legal, marketing, operations, engineering, developers, designers).
  • Allow ample time in your schedule, no distractions or meetings, making yourself and your team available for the whole process.
  • Don’t get bogged in details, staying faithful to the process and user-centric approach.
  • Go in prepared: who are your users, personas, what upfront information do you have on your users. What problem are you trying to fix in our user experience.

Design Thinking will give you the plan to produce a product that is focused on the user, is something that the key people in your association have agreed to and have “buy in”, while also reducing the risk in terms of expensive rework later down the road, and also dramatically reducing the risk of building the wrong thing.  Most importantly, it keeps technology where it should be: almost seamlessly invisible to the user’s using it. If you’re interested in finding out more about how i2Integration has used Design Thinking for technology projects, contact Lisa Powers at lpowers@i2integration.com.