The agile methodology for designers

The web has evolved into a full-featured medium and, like most things in life, the simpler times are behind us.

In the early years of web development (a time known to elders as the early 2000s), a linear approach to project management worked pretty well. The creative team would design a UI that reflected a single desktop experience and would “throw it over the wall” to the developers. A few weeks or months later the site was brought online, and so long as you could get IE6 to play nice, you were ready for launch.

If you’ve heard of Agile project management and written it off for programmers, you’re not alone — it’s long been reserved for the halls of software development teams. However, just like no one calls them programmers anymore, Agile isn’t just for C++.

In fact, Agile frameworks can be implemented into just about every flavor of business, and it’s finally starting to make its way into the mainstream design world, fittingly bridging the gap between designers and developers.

But before we get too far ahead of ourselves, let’s first wrap our heads around the distinction between Agile and its project management incumbent: Waterfall.

Agile vs. waterfall

The Agile Manifesto was designed to help and empower teams to make quick changes to the software as needed and throughout development. This is in direct opposition to the waterfall method. With a waterfall, the first team would determine the requirements and ship that off to the designers, who would send off their designs to the developers.

Weeks or months later, the first team would finally get to see their designs manifested, request changes and the lengthy process would repeat.

Sound familiar?

In the early days of the web, this method was OK because websites were relatively easy to build. But with a rapidly changing and expanding field of options aligned with the growing expectations of our clients, websites can no longer be classified as “digital brochures.”

The reality of modern UI design is that there is no single standard, so it’s time to stop designing like there is. Even if you’re still designing with a “desktop first” mindset, you can’t ignore that mobile users account for 65 percent of digital interactions, and they’re not all using the same kind of phone and tablet. Your end users have some 45 different devices with 45 different screen resolutions that affect how your content is displayed.

That’s a long way from the nuances of a single, shitty Microsoft browser.

In addition to an unmanageable number of different resolutions your design needs to adapt to, today’s functionality requirements for the SMB look a lot like what enterprises spent small fortunes on less than a decade ago.

It’s long past due for designers to follow the lead of their technical peers who have embraced Agile’s flexibility and aren’t looking back. Ignoring this modern process costs money, time and will leave your projects lacking.

Agile works in small “iterations,” usually a period of a week or so where a small team works through a set of defined objectives before circling back to discuss progress. What sets this apart is the inclusion of developers every step of the way, actively building out and testing the designs (in the browser) with every iteration. This allows for feedback and flexibility — something from which everyone can benefit.

Agile project management and you: The great incorporation

There are some key factors that are inherent to the success of the Agile manifesto, and I’ll run through the most important ones in a minute. First, keep these values in mind as you make the transition:

• Individual contributions and team interactions matter more than processes and tools.
• A product that functions at its best is more important than whatever the original plan was.
• Include your developers throughout the entire process.
• Your company culture must foster open, respectful discussion that includes every stakeholder.

Just like a single user experience won’t work effectively with every screen, not everything in the Agile Manifesto is relevant to web design. Here are some of the most applicable tenets:

1. The chief priority is delivering functionality early and often

It might sound counterintuitive when designing for computers, but pen and paper drawings are a great way to begin. Not only does this help your client visualize your ideas, but you won’t be limited by the digital constraints of some mock-up software. Besides, it can be hard to design for 45 different screens if you begin by limiting yourself to whichever one you happen to be using.

Continuous delivery of designs is critical to maintaining a tight feedback loop. Seek input from everyone you can — customers, designers, developers and people not directly related to the project.

With constant feedback from the client, you create pseudo-approval milestones. As a result, your team can move forward with the confidence that the project is progressing as expected.

Tip: After you’ve created some sketches that seem interesting, start stress testing them in different browser sizes before your creativity kicks it into high gear. Learning the limitations of your ideas is a whole lot more effective before you’ve spent all the time perfecting it. Not to mention, it saves a lot of time and delivers a better product. (Noticing a trend?)

A great tool to test different screen sizes is Chrome’s Device Mode. It’s no substitute for seeing something on an actual device, but it’s far better than resizing your browser window to what “might” be an adequate mobile stress point.

You might be accustomed to static prototype tools like InVision, and while these tools are great, functioning examples of what you’re working on are way more beneficial for your clients. As soon as you can, start integrating your UI with real code into real browsers. Even if it’s clunky at first, you (and your feedback loop) will start to notice any issues long before they fester into the problematic.

Plus, it makes total sense that you would prototype with code that can be reused for the actual development, and static prototypes just can’t offer that.

2. Change is the best thing for you, even late in the game

As you integrate a solid feedback loop into your design process, you’ll have a lot more comments and critiques to consider as you move forward. While it might have been difficult to incorporate change and stay on schedule in the past, with the Agile method, changing something up doesn’t necessarily mean it will take longer.

That’s because Agile stresses attention to excellence in technological design. From the designer standpoint, that means:

• Considering the functionality of their design, not just the appearance.
• Communicating their designs with annotations through well-named layers.
• Keeping developers in mind by using grids to maintain order and efficiency from the start.

From the developer’s point of view, this includes:

• Cleaning up code whenever possible, at a minimum with every iteration.
• Adhering closely to the DRY rule. Don’t Repeat Yourself is the idea is that every input has a unique and authoritative representation in the system. The practicality of this is that tweaking one part of the code will not require changes throughout the entire system. This makes it easy to make changes at any time without throwing the whole process into a QA (Quality Assurance) nightmare.
• Periodic code refactoring that’s scheduled and enforced by the product manager.

So rather than staying the course just to meet a deadline, Agile lets you make changes constantly to deliver a better product.

Sidenote: Having just read this, can you see how problematic it is to just pass along a full design to a developer and ask for “pixel perfection?” First of all, pixel perfection is a zero sum game. Designs need to look good on any number of unknown resolutions and browsers…you simply cannot be pixel perfect on all, and attempting to do so on one, will very likely look quite bad on others. Furthermore, there’s a reality that hits you when you see your design in the browser for the first time: It always requires tweaking. As a result, many projects spend more time refining the design than building the full, initial version. Agile’s feedback loop will help you prevent the cross-departmental frustration if your expectations are iteration and change from the beginning.

But how often are you going to need to make changes? That depends on how closely you follow the next principle.

3. Bring people together, because silos are for corn

Innovation isn’t born from agreement. People who tend to think in similar ways also agree with each other more. While that isn’t the end of the world, it is the end of creative solutions to your roadblocks.

Why?

The reason is simple: people who think differently often do different jobs, and as such have traditionally worked in totally different silos. So your room full of designers just won’t see the things that a room full of developers will, and vice versa.

At a place where a designer is stuck, the solution might be obvious to a developer. In the waterfall method, this roadblock would have remained in the designer’s silo, without any input from a developer. The result is often a less-than-ideal solution, easily avoided by the multi-level collaboration Agile encourages.

Bringing folks together is critical, and not just in a big meeting toward the end of the project. Left-brain and right-brain thinkers should be put in the same room every day. Encourage your developers to spend time in UI design meetings, and give opportunities for your designers to see how their work plays out in code.

4. Communicate face to face, even if that means virtually on Google Hangouts

We’ve grown accustomed to communicating via the written word in almost everything we do. Emails and text messages inevitably lead to misunderstood intentions. No matter how innocuous, the emotion of the conversation is limited to the mood of the reader, and eventually, this works against you.

Brief, daily face-to-face meetings, can help eliminate misunderstanding and encourage a team-building atmosphere. These positive exchanges are encouraged when everyone feels free to speak their ideas, and the input of everyone is respected.

Of course, if you have a distributed or remote team, in-office meetings are not possible. Make it a point to use video chat, and pay extra attention to mannerisms of your team. Often a simple facial expression is all you need to get the feedback you were seeking.

5. What are we doing wrong?

No one can see an inefficiency better than those who have to undergo it. Take the time to create a culture and atmosphere where these inconsistencies are expected and can be brought to light and fixed. If a design iteration that has to undergo four client reviews should really only undergo two, make it a point to discuss how the whole team can improve in the future. If it seems weird to lead with a negative, flip the conversation and ask: “How can we do better?” and make it an expectation of the team to provide at least one tactical solution.

Get set up for success

Agile methodology is as flexible as you want it to be. So while these aren’t strict guidelines that you must follow, incorporating them into your business structure will bring about effective change that you, your team and, most importantly, your clients will notice.