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.
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.
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.
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:
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.
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:
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
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.
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).
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.
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:
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:
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.
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.
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.
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.
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.
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.
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.
