Since its advent in the early 1960s, the software development life cycle, or SDLC, has withstood the test of time to establish itself as a fixture of software engineering. Yet despite its permanence in the development landscape, it remains a malleable process, sprouting different permutations over the years.
This flexibility is both a blessing and a curse. On one hand, its versatility means it can adapt to a diverse range of projects, accounting for scope, complexity, and other crucial project factors. On the other, it would be ideal for a development agency to rely on a repeatable, definitive workflow—a one-size-fits-all process that can tackle any task that might fall on their plate.
Related: How to move from imitation to innovation
A handy illustration of general SDLC, from Bhumi Shah.
The best SDLCs marry both ends of the spectrum: a rigid framework that leaves room for customization. This is easier said than done—alterations made to the SDLC must not disrupt the cycle’s workflow.
The development agency I work for, Codal, recently introduced a new design exercise called innovation days, or iDays, into our SDLC. In this article, I’ll describe what iDays are, how to run one, and how it can seamlessly mesh with the rest of the software development life cycle.
What’s an iDay?
Short for innovation day, an iDay is a specialized, hyper-collaborative ideation session that takes places in the discovery phase of the SDLC (or “requirements analysis,” “project definition,” or whatever name you may give it).
An iDay distinguishes itself from typical brainstorming sessions by connecting different project teams, stakeholders, users, and any other involved parties. A standard iDay may consist of designers, researchers, developers, members of the client team, and even their own end-users.
“iDays give a rare opportunity for *all* stakeholders to contribute.”
The result is a forging of connections that would normally be sequestered in a typical design cycle. The ideas generated in these blue-sky brainstorming sessions often spring from a collision of perspectives—it’s a stark difference in approaches between the developer, the client, and the end-user.
Running an iDay
An oft-forgotten step of the ideation process, even in a standard brainstorming format, is recognizing and assembling the ideal group of participants. For starters, at least 1 member of each team touching the project should be present in the iDay session.
Once you establish the core, reach out to the client’s teams that may be involved in the project, and potentially their end-users as well. The inclusion of end-users in the brainstorming stage usually depends on the accessibility and type of users.
Related: The lifecycle approach to UX design
After you’ve assembled all participants, it’s time to begin the iDay. Typically led a member of the UX team, the session consists of a series of prompts, or questions posed to the group about the platform.
These prompts are usually general, open-ended inquiries. Instead of asking “What do you think of the site’s navigation bar?”, a more appropriate question might be “How could the site’s navigability be improved?”.
The UX team generates these prompts, and they’re based on their own observations and analysis of the platform, or on data collected from the project’s previous research endeavors. For example, if an end-user survey revealed a poor customer support feature, one prompt may ask what a better help and support feature might look like.
After the iDay leader poses the prompt, participants jot down as many ideas as they can in roughly 2-3 minutes. It’s important to emphasize to the session that these are blue-sky ideas—they can be as unrealistic or seemingly unfeasible as possible. Participants should write each idea on a Post-it note.
“iDays foster an environment for dynamic and fruitful ideation.”
Once time expires, each participant takes a turn to present their ideas to the group, no matter how unformed they may be. After each idea is shared, the iDay leader collects the Post-it note and sticks it to a wall or whiteboard.
As Post-its accumulate, the leader can begin to group the notes by topic, feature, or idea—whatever organization method will help them map and mine the notes for data later.
The group sharing usually sparks meaningful conversation about the presented ideas and how they could be implemented or executed. It’s important for the iDay proctor to facilitate and promote this discussion—it usually produces even more ideas or insights.
After everyone in the group has shared their ideas, and Post-its have been collected and placed, the iDay leader poses another prompt. Then the cycle begins again.
Collecting data from iDays
At the end of an iDay, the UX team usually finds themselves in a room covered in Post-its, not unlike the photo shown below.
While it looks like an intimidating amount, the iDay leader’s organization of these notes has actually resulted in an early affinity map, a common artifact of the SDLC. From this map, the UX team can extract key takeaways, draw conclusions, validate assumptions, and even re-define requirements (with client approval, of course).
The iDay notes are great sources of information because they result in both quantitative and qualitative data. While the quantitative data is similar to that garnered from a focus group (e.g. “50% of participants felt an improved search bar was the best method for finding products”), it’s often the iDay’s qualitative data that offers the most insight.
Related: 6 ways to speed up and improve your product design process
Say you’ve decided to administer blue Post-its to a certain user type present in the session. If the affinity map has a section called “checkout process” that’s full of blue notes, you confirm this is a major issue for this user group.
These early affinity maps generated during an iDay session also help the UX team recognize themes and patterns in the research, and identify what issues seem to be the most prevalent. The restickable nature of the Post-its allow the designers to easily re-visualize the data in new ways, framing it with different design lenses or perspectives.
The UX team also frequently references these affinity maps when crafting the platform’s architecture. They can even use them as a tool for scope definition, prioritizing features and determining which ones should be in the initial platform version, and which should be tabled for later releases.
Embracing the iDay
So far, Codal’s iDays have been a success with both our clients and our internal teams. While primarily for the UX designers, all parties involved within the project enjoy contributing their unique ideas, and appreciate how the exercise drives alignment between teams.
It’s easy for SDLCs to fall into compartmentalization, to forgo collaboration in favor of passing off the product from one isolated team to the other in discrete steps, like an assembly line. iDays give a rare opportunity for all stakeholders to get involved and contribute.
iDays foster an environment for dynamic and fruitful ideation
—and they provide invaluable data and research artifacts that UX designers can reference later in the SDLC. iDays have become a key component in Codal’s software development life cycle, and we’re looking forward to next way we can fine-tune our SDLC even more.
You’ll love these posts on team collaboration, too
by Sean McGowan
Sean is a technical researcher & writer at Codal, authoring blog posts on topics ranging from UX design to the Internet of Things. Working alongside developers, designers, and marketers, Sean helps support the writing team to ensure Codal produces engaging web content of the highest quality. When not writing about the latest innovations in app design, Sean can be found cooking, watching old movies, or complaining about the shortcomings of his favorite Philadelphia sports teams.
