Recap from Pittsburgh TechFest 2018
In June, I had the pleasure of presenting to professional software engineers as part of Pittsburgh TechFest 2018. It gave me an opportunity to open minds around some long-held beliefs that are keeping our digital product development processes back from creating the best, most desirable software quickly.
For over 20 years, I consulted as a software engineer and system architect. I decided to change my area of focus from system architecture to human-centered design (HCD) when I realized why my projects were failing:
- Requirements changed drastically during the course of development because the stakeholders were not aligned from the beginning of the project, and
- Our applications underwent significant rework after being fielded because our tools were not meeting the end user’s needs.
The statistics bear this out. Seventy-five percent of large enterprise software projects fail completely*, and those that are “successful” average 45 percent OVER budget and 56 percent UNDER the promised functionality*. The user interface (UI) makes up 47-66 percent of a project’s total code, but UI accounts for 80 percent of unforeseen fixes (the other 20 percent are bugs). *
Here, I will share SDLC’s product development model that encompasses HCD principles, coupled with Agile UX design practices to create a software development life cycle that empowers developers to focus on their strengths and infuses design leadership.
Why the Current Model Falls Short:
There are several reasons why the actions that software teams are taking now, under the good intentions of Agile and in Scrum, aren’t adequate:
- Requirements (e.g. the Product Backlog), created by a Product Owner, are too far away from the end software customer (who is not a designer).
- Fuzzy business objectives and out-of-sync stakeholders are not aligned with the future-state vision because so much focus is placed on getting started with actual development work.
- Often, scrum teams time-box the initial Requirements, Design and Architecture process into a two-week phase (Sprint 0), so the developers can get to work ASAP.
- User needs are only evaluated at the beginning (Sprint 0) and ending phases (User Acceptance Testing).
Our model addresses these shortcomings by explicitly defining a human-centered process for developing the Product Backlog and keeping all the stakeholders aligned with the product vision. The designer stays active throughout the development process, evolving the design to address gaps and new requirements just-in-time for the developers.
SDLC’s Product Development Process addresses these issues:
SDLC’s Product Development Process integrates a modified, Double Diamond Design process with a customized Scrum development process.
We explicitly define an Initiate phase where an interdisciplinary team invents and specifies the requirements, visual design, and system architecture before development begins.
The Initiate phase begins with a kick-off meeting, facilitated by the designer, where all of the corporate stakeholders align with the goals of the project. The project team embarks on research to broadly challenge assumptions and explore the domain. Then, we collaboratively interpret our research and find insights about end-users’ goals, processes, and pain points. Before we begin designing the new product, we align the stakeholders around our findings with another meeting where we present our design brief.
The second diamond begins “open-minded ideation.” Here, we collaboratively generate many alternatives to solve the problems we discovered in the first diamond. We evaluate these ideas and select our favorites before specifying our proposed solution. We align the stakeholders, again, when we present our proposed solution in enough detail to form the foundation for development.
During development, the designer works as a consultant. Generally, the designer works one sprint ahead of development, building the high-fidelity specification for the upcoming sprint. Working in this just-in-time manner allows for the inevitable changes in requirements to be accounted for while maintaining the conceptual integrity of the product. The practice also ensures that the designer’s intent is fulfilled by the development team.
The stakeholders are invited to observe the product throughout development at the sprint demo meeting. And, they are invited to suggest changes to the development team’s priorities so the team is always working on tasks that provide the highest business value.
Keeping the designer and the stakeholders involved throughout the development process reduces rework at the end of the project and ensures that the end product is adopted, used, and liked by the users. Here’s how a real-world software development lifecycle could look different if design leadership was embedded at more key points in the process.
- Give the integrated team time to perform and interpret research before designing the solution will increase the likelihood that they will design a system that is adopted by the end users.
- Have a representative from the development team actively involved during the Double Diamond Design process to ensure that developers are clear on the intent of the design.
- Keep the designer involved throughout the development process helps developers utilize the designer when they find gaps in the design or new requirements emerge.
- Keep the stakeholders involved throughout the design and development process to keep everyone aligned and to confirm that the application will contain the most business value at any point in its development.
Steps to Get Started:
It comes down to these five mantras:
- Avoid dogmatic agile UX principles
- Make the designer the Product Owner
- Maintain conceptual integrity
- Allow design to sprint ahead
- Trust the design process
As I’ve seen with our clients, using the Double Diamond Design process reduces code rework, ensures that client’s requirements are met, and that a more usable, enjoyable product is delivered to market more quickly.
If you’d like to discuss our HCD process further, contact our team to schedule an initial discussion.