Software design and development projects are riddled with holes in communication and prone to errors when transitioning from concept to code. Intuitive’s PlaybookTM is a living, self-generated website that defines the solution – design patterns, fonts, styles, icons, colors, page widgets, functional components, templates, data contracts, and code – to bridge the divide and deliver superior digital solutions.
College Football Hall of Fame Coach Woody Hayes was often quoted as saying:
How about with handoffs? The odds aren’t that much better – either the handoff is successful or the ball fumbles to the ground.
In football, a handoff is an exchange made by directly handing the ball to a teammate. There are hands on the ball at all times. In user experience design and development a handoff is an exchange made when one person or team transfers their work and deliverables to another.
Compared with passes, handoffs are much more successful statistically. However, when fumbles do happen, some end in turnovers giving the other team the chance to go on offense. Every coach actively works at minimizing turnovers, which too often lead to losses, even for the better team. I’d like to talk about handoffs in business, specifically for software projects. Should we solely work to minimize fumbled handoffs in our projects or is there a better way?
We live in a time of high collaboration. Innovation is often a product of this collaboration. And yet many people and companies continue with the traditional approach to software projects – a series of handoffs that progress initiatives from high-level business need through a series of steps until product launch.
- There’s typically a handoff of the business requirements (the beloved and often prose-heavy Business Requirements Document). Maybe this handoff was led by the Business Analysts who hand this document and all its wisdom to the Technology Team (perhaps to the Architect or Development Lead).
- For companies that have embraced the notion that User Experience is a critical element to the success of projects, the next step is to begin the Solution Design phase which includes the User Experience (UX) Design process. This phase may include user-centered research, wireframing, workflows, and visual design focusing on the behaviors of users and perhaps even prototyping at various levels of fidelity. But in this phase, we can observe a lack of handoffs. True, there may be differently-skilled designers involved including Researchers and Human Factors experts (who focus primarily on understanding and discovering insights about the users), Information Architects (who blueprint the interaction and information design), and Visual Designers (who bring color, typography, and style to the project). There’s an innate collaboration that happens by people speaking a common and comfortable language.
Once the design is complete, application-wide or even for a feature, there’s a particularly problematic handoff next between design and development. We can get incredible levels of specification of the design. We’ve seen and been guilty of producing Specification Documents and Standards Guidelines that attempt to explicitly dictate how a solution should be built.
I think the worst example I saw was over 600 pages spelling out every color, font, typography, leading, border, spacing, and wrapping that could ever be used. Who’s even reading that let alone following it perfectly? Worse yet, who’s maintaining this tome? Talk about designing to fail!
Earlier I noted that the specification process tries to dictate how a solution should be built. If only this is what is happening! More accurately, it’s how a designer envisions the solution being built. The problem being that the design specification doesn’t necessarilty describe or fully consider how a solution is actually constructed.
The design is in one language and the solution (as built) in another. The languages share some words, much like how we talk. In the English language we’ve adopted words from other origins like cinema and aviation (French), kanban or kaizen (Japanese), kindergarten and hamburger (German), kibosh (Yiddish or who knows?), and on and on. But this process of adopting others’ words, of learning what they mean and how to interpret them, is in essence another handoff. These words have become part of the common nomenclature because they were guided from one culture to the next, not just dropped in and left for us to figure them out.
In UX design and development, one consequence of this problematic handoff is getting a sub-optimal solution – one that loses the integrity of the design that we so painstakingly tried to specify. We lose both time and money while morale takes a beating; designers, developers, quality assurance, and even clients become frustrated (sometimes even fried) by the process. Product and project managers try to navigate this minefield and executives try to stay in the loop in order to keep a project afloat and moving.
Wouldn’t it be better if we didn’t need the translation? What if there were no handoffs? Perhaps a better analogy is that of a team of people holding something large enough that they weren’t all huddled around something as small as a football. Maybe it’s a long, lightweight and sturdy object that allows people to move with it, come into the mix when needed, help carry it, and leave without notice or anything being dropped. Not unlike crowd surfing or stage diving at a concert. A brave person is caught, never dropped, and passed along throughout an audience that cares enough not to drop them.
The idea is that there’d be no “handoff” – only “hands on!” – with no risk of dropping anything. It would be lightweight enough to allow for a change in direction. It could be easily accessed for people to see, touch, and feel. You’d even be able to interact with it and manipulate, modify, or otherwise improve it.
Intuitive has developed such a lightweight and sturdy collaborative approach and solution to this problem. We call it the PlaybookTM.
The Intuitive PlaybookTM is in production today for dozens of clients across even more projects. We’re applying kaizen to it, ensuring it’s ever-evolving and improving. For example, we’re figuring out how to use the Playbook to capture key reusable user experience patterns, error messages, and design grids that are in use. We won’t consider it ever complete, but it delivers value every day.
Better yet, our clients are able to become the head coach, calling and directing a set of proven and innovative plays to exponentially improve their users’ experience. They call on different players throughout the UX design and development process and they get to be the active key voice and visionary in a dynamic and high-performing team.
This approach has a number of key benefits:
- We’re addressing the most problematic handoff by creating a shared, collaborative language and solution set with all necessary hands on-deck.
- We’re eliminating unnecessary steps of specifying a design in one language and translating into another by enabling both design and development to share a common language.
- We’re creating self-maintaining guides for later design and development efforts by leveraging the code and embedded comments to generate a truly living style guide that goes well beyond fonts, colors, and icons.
- We’re providing a single place to go for documented reusable solution elements, in turn, saving time/money and enabling more hands-on activity. More hands-on means we can increase throughput, decrease time, and eliminate bottlenecks and risks.
Get in touch to see more examples and collaborate on how the Intuitive PlaybookTM can help you avoid and eliminate:
- Delays, communication challenges, and misunderstandings throughout your software development lifecycle, especially between user experience designers and software developers
- Feeling like you are a bystander speaking a different language rather than a head coach calling and directing a clear set of proven and innovative plays
- Shooting at an ever-moving target without up-to-date documentation of your digital brand and user experience guidelines including fonts, colors, icons, buttons, grids, templates, interactions, and behaviors
- No common language bridging design and development or getting code that has precious little to do with your recommended designs
- Struggling to isolate root causes of software bugs due to lack of access or the complications of your front-to-back end solution
- Having to wait too long to be able to demonstrate in-progress designs or front-end solutions while the rest of your software development process finishes integration, QA, User Acceptance Testing, performance testing, and launch activities