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.Explained One 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.
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?
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
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: 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: 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: 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: 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
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 can add value from the start and quickly deliver quality software by leveraging the user workflow exercise to plan what parts of the application. Once the simple path is mapped out, the team can begin an iterative process:
00) Build something that adds depth to the application.
01) Test updates with users.
02) Demo the application with stakeholders.
03) Make any updates that are needed.
04) 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: 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: 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.
(30-60mins per interview)
User Testing: 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
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.
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.