July 28, 2022

A Designer’s Toolkit for Developing the Right Software

Companies often spend money without getting the working software that solves the intended problem. Executives become unhappy, users question the application, and dev teams become disengaged. Learn strategies to alleviate common problems modern development teams experience.

Brian Pope

In today’s tech industry, many development teams have been involved in projects where assumptions are made about customer or user needs. These assumptions might come from an executive, a stakeholder, or even tech and design leaders. Sometimes these assumptions work, but many times they are built without understanding the users’ needs – making the experience ineffective.

One well-known example about not understanding a user need was written by Jared Spool. A company had a $300 million dollar problem without anyone knowing. This company required registration upon checkout of their ecommerce website. Spool talked to users and found out they didn’t want to register with the website to make purchases.

I’m not here to enter into a relationship. I just want to buy something.
–  Tester

Armed with this information, the team removed the registration requirement and made it optional for a user to sign in for purchases. This simple change generated an extra $15 million in sales in just the first month and $300 million annually.

Strategic Impact

In our ever-changing world, validating that you are building software that is desirable, feasible, and viable is an essential part of business.

  • Desirable = What does the user need and why?
  • Feasible = What technology matches the project need and is accessible to the company?  
  • Viable = How will this application help business goals?
Ven Diagram with overlapping Desirable to humans. Viable for business. Feasible for technology.?

Desirability, feasibility, and viability are constantly evolving – rapidly. So, how do modern software teams build quality software effectively? By being aligned and focused on the problem, keeping things simple and iterative, and continuously learning together.

To produce quality applications, development teams must come to an agreement on the problem they are solving and continuously build, test, learn, and iterate together. All while keeping the end user in mind throughout the whole process. Without this foundation, the project is set up for inefficiency and waste. Here are a few strategies to help establish a baseline so your team frequently confirm what is being build does bring business, team, and user value.

Team alignment on scope and focus

Four targets with goals hitting different marks

As a team, one of the first steps of a project is to frame the problem you are solving. The team must know “What” they are building but also “Why” it’s being built in the first place. This step sets up the range of solutions and is needed to make the project effective and sustainable. Breaking the conversation down to its simplest form helps the team understand the real needs.

Consider things like:

  • Our users are saying they need X, why is that?
  • When stakeholders are asking for X, what do they really mean?
  • Is there a reason we’re using technology stack X?

Defining the parameters of the project from the beginning helps refine scope, gives the team focus, and lays the foundation for team communication throughout the project.

Toolbox for Alignment

There are a few tools we can use to efficiently elicit this information. It’s important to understand what the benefit of each tool is:

Kick-off Meeting | 1-8 hrs

The first project team meeting to align on problem statements and desired outcomes for the project.

Used for: Introductions, Understanding Project Requirements, Individual Roles and Responsibilities, Defining Problem Statements, Discussing Security Practices

Empathetic Interviews | 0.5-1 hrs each

Conversations with business leaders, users, and technologists that use open-ended questions to evoke specific experiences to uncover unacknowledged needs. Team can look for patterns on how questions are answered.

Used for: Understanding users perception, not usability.

Personas/Archetypes | 1-2hrs each

Data-driven insights about behaviors, attitudes, goals, and pain points to align the team on user experience priorities.

Used for: Representing your target user(s).

Customer Journey Mapping | 1-6hrs each

A visual representation of the process a person goes through to accomplish a task.

Used for: Understanding the user flow to reduce friction when using the application. There could be different journeys based on user type.


  • Understanding the user intention, refines project scope to what is valuable immediately.
  • Up front discovery as a team leads to a better hypothesis of what is needed.
  • A team understanding user needs leads to better decisions by all team members.
  • Research helps a team understand where to build, not what to build.

Keep it simple – gather feedback and iterate

Examples of iteration and evolving shapes

Once you have defined the parameters, it’s time to start solutioning or the “How” of the project. The Software Development team ideates a hypothesis for the project using knowledge gained from defining scope and focus.

Open-ended questions can help facilitate this collaboration:

  • What ideas fit the user needs, business goals, and technology for this project?
  • What Security-by-Design principles or tools to leverage?
  • What gives our users value from the beginning?
  • What is possible with the technology that we have available?

Once the team has aligned on a hypothesis, they will start building the easiest path from start to finish – often referred to as a Minimum Viable Product (MVP). Thanks to kick-off meetings, empathetic interviews, persona creation, and customer journey mapping, the team should be aligned on the project priorities.

Successful teams add value from the start and quickly deliver quality software by leveraging user workflows. Once a simple path is mapped out, the team can begin an iterative process:

  1. Build something that adds depth to the application.
  2. Test updates with users.
  3. Demo the application with stakeholders.
  4. Make any updates that are needed.
  5. Repeat from 00.  

Building in small steps makes it easier for the team to be flexible when it comes to priorities, testing, gathering feedback and making changes. Gathering feedback and making iterations while you build will lead to less risk when the application is released.

Developer’s Toolbox for Iteration

Story Mapping | 2-8 hrs

A method for arranging user stories to create a more holistic view of how they fit into the overall user experience. Sometimes referred to as a product roadmap.

Used for: Outlining tasks needed to build a new product or a new feature for an existing product and arranging them into functional groups.

Agile | Varies

Iterative development methodology that delivers software to market (and value to clients) faster and with less headaches.

Used for: Delivering secured software in small, consumable, production-ready increments.

User Testing | 30-60 mins per interview

Interface and functions of a website, app, product, or service are tested by real users who perform specific tasks in realistic conditions. Example: Can our users get through the workflow without help? Are there sticking points? Is the language clear?

Used for: Information gathering about user experience to make application adjustments.


  • Quality and security is built-in as the project is developed.
  • Feedback helps reduce risk of usability.
  • Value to the user, business, and the development team.

The team is always learning

Puzzle changes changing color and shifting

Deeper Understanding for Company Leader

Because the team is consistently testing their app, their knowledge about users’ needs will become mature. Teams share this information with company leaders who can strategize, create vision, and make better informed product decisions.


Because the team is constantly thinking about the user, they notice they are making more objective decisions, which benefit the quality of the project. Teams develop a strong trust where ideas for solutions might come from any one of the members. For example a developer might have a great design solution and will feel comfortable discussing with the team. Not only does learning create quality output but it also creates a more fulfilling experience for your team members. Each role might overlap their responsibilities to educate, empathize and help build an effective application.


As the project evolves so will individual team members. Using this collaboration, Individual members learn more about the business, the users and technology making the employee even more valuable for their next project.

Toolbox for Learning

Paired Programming: Pairing up to work on development tasks leads to better code, diffusion of knowledge, transfer of skills and resiliency.

Desire to Learn: Team shares articles, blog posts, podcasts, etc. and are always learning new things.

Simple Discussions: Team is not afraid to ask questions or ask for help. Discussions with the team can clarify issues and bring forth a simple solution.


  • Education provides value to companies, teams, and engineers.
  • Learning create more dynamic team members.
  • Psychological safety leads to better ideas and implementation.

Help beyond the toolkit

Does your company align on scope and focus? Do your team practice quick iterations and make quality changes based on feedback? Do your employees educate each other and learn new things through challenging tasks? Whether we work as a strike team or consult client teams, Trility bakes strategic impact into our work.

If your team needs confirmation they are building the right thing, we can help figure out where you are at, where you want to go, and how to get there both strategically and tactically.