The Magic of Agile and the Design Process

by

Over the past year, I’ve been working as the solo designer embedded in a team of mostly developers and one project manager designing web experiences and publishing software for one of our clients, Rivals.com. We follow an agile methodology and work hard to effectively and efficiently integrate design. This blog post breaks down the major phases of our process and illustrates, at a high level, the role of design throughout.

THE PLAYERS

To understand the composition of the Rivals.com product development team requires a bit of background on Rivals.com, its stakeholders, and users. Rivals.com is a network of publishers and their websites who report mainly on college football and basketball recruiting and is owned by Yahoo!. Stakeholders include executives from both Yahoo! And Rivals.com. Grio does the design and development of the web and mobile applications for Rivals Publishers and Sports Fans looking for the inside scoop on college sports. Our internal Grio team is composed of a project manager, a designer (me), and a team of about 8 developers. We follow the lead of our point person from Yahoo!. We’ll call him The Wizard, who guides us in our product development adventures.

Rivals product development team

The Wizard is the central point person of product development for Rivals.com. He sets the long term goals and priorities by listening to stakeholders and users while working with Grio to realize these outcomes.

THE PROCESS

Loosely, the stages of product development include strategy, requirements, design, development, and review and production. Once the features we produce hit production, we gather analytics from our Sports Fans and feedback from Rivals Publishers to inform the next round of iterations.

STRATEGY

The strategy phase involves Yahoo! and Rivals.com stakeholders working with The Wizard to define business and user goals and the objectives to achieve these goals. They listen to publishers and analyze user data to inform to their strategy. They follow the principles of design thinking to advance their business goals.

Illustration of Rivals product development team

The Wizard works with stakeholders to define long-term goals and the objective the team must carry out to achieve these goals.

REQUIREMENTS

When developing new features, oftentimes the original story is loosely defined. For example, we recently redesigned the article pages that showcase the stories Rivals Publishers write and Sports Fans read. The original story presented to Grio was “Redesign article pages”. The first step to defining requirements for a story like this is to understand the user and business goals, do some research, and then refine the story. For the article redesign feature, the project manager and myself discussed the overall goals with The Wizard and reviewed competitor sites to learn how they were presenting their articles and understand the why behind their designs. We also read user research to inform our decisions. More complex and interactive features require design methods such as user interviews, scenarios, user flows, and sketches to help the team better understand the problem and write more specific user stories. Sometimes, our project manager applies design thinking without my participation because we all share responsibilities and use the methods and tools that are appropriate to gather sound requirements. Close collaboration between design, project management, and The Wizard is an important factor of this phase. If the three of us are not clear on goals and expectations, confusion sets in and continues through development. At this point, the Dev team helps with technical expertise and feasibility.

Illustration of the Rivals product development team

Requirements are defined using design methods and collaboration between product management and design.

DESIGN

The responsibilities of the design phase mostly falls in my lap but I’m in constant communication with our project manager and The Wizard to stay focused and in scope. Design artifacts such as sketches, wireframes, and high fidelity mockups are created to communicate the requirements established in the previous phase. These artifacts are shared with the Rivals.com stakeholders, Rivals Publishers, and Sports Fans to gather feedback during the design phase instead of waiting until development is completed.

Illustration of the Rivals product development team

The Design Phase produces a visual representation of the Requirements Phase and is also a close collaboration between product management and design.

DEVELOPMENT

Our development team works its magic during this phase. To ensure that the team has what it needs to be most effective and efficient, we review designs during planning sessions to assess and assign technical complexity. Design revisions may occur when the entire team determines that a design will add increased effort that may not deliver a successful outcome. The Wizard is consulted when questions arise that require technical expertise and advanced product knowledge. For larger features, like article redesign, the original ticket turned into many user stories, partly as a result of the Requirement Phase, but also feedback from the development team during planning. Each user story has a design attached to it for reference. Writing user stories that are manageable and specific facilitates the team’s’ velocity and keeps them focused. Once user stories are pointed, the development team gets to work. Before major features are released to the public, work is reviewed on an internal site known as Acceptance.

Illustration of Rivals product development team

The Dev Team works collaborates with The Wizard for technical and product expertise.

REVIEW & PRODUCTION

The Rivals.com acceptance site allows us to find bugs, conduct design reviews both internally and externally with stakeholders and users, and flag anything that needs more attention before going live. The Wizard and Rival.com stakeholders participate in the review heavily as well as myself. Our Project Manager also participates and records bugs and adds user stories as needed. My responsibility during review is to not only review Acceptance but also work alongside development to answer any design related inquiries.

Once features are approved by The Wizard, they are pushed to production and are available to all Rivals Publishers and Sports Fans. We continue to monitor the system, feedback, and analytics to gauge satisfaction and whether or not we reached our goals. The Wizard does much of this monitoring and relays his findings. The Rivals Publishers also have access to analytic tools for their individual sites. This provides them with insight into the behaviors of their Sports Fans and the power to make changes and new feature recommendations.

Illustration of Rivals product development team

The entire team pitches in to review new features and make updates. The Wizard accepts the work and approves it for production where everyone can interact with our work.

Design is a small part of this team but we integrate design thinking, design methods, and user experience awareness into every phase because our team understands its importance. The design role is not solely responsible for all aspects of design; we all make contributions and share design responsibilities. Through communication, collaboration, and iteration we make progress and improve our process. We reflect on our missteps and successes to keep us moving forward in our adventure with efficiency and quality in mind.

1 Comment

  1. Don Donoughe on said:

    Interesting and insightful! Thanks

Leave a Reply to Don Donoughe Cancel reply

Your email address will not be published. Required fields are marked