Micro Focus is now part of OpenText. Learn more >

You are here

You are here

A visual designer's guide to working effectively with agile teams

public://pictures/Yevgeniy-Belov-UX-Engineer-HP-Software.jpg
Yevgeniy Belov UX Engineer, HP Software
 

In an agile development team, all members must assume collective responsibility for quality, including how the final product looks. As such, it's important for a visual designer to function as an integral part of an agile team, and everyone on the team needs to understand the visual designer's role.

Visual design, a specialization within the UX domain also known as graphic design, comprises all visual aspects of a product. In an agile development environment, the UX designer usually makes the initial visual design decisions, such as the location of the navigation bar. The visual designer then steps in to work out the details of color and style.

As a visual designer, I work with developers, and I regularly participate in the exchange of ideas that occurs in agile team meetings. But I do my design work differently. While most visual designers work with graphic tools, I write code. If you can pick up this approach, it will greatly increase your productivity and enable even closer collaboration. That's just one of the techniques I use to collaborate more effectively with my agile team. Here are four things you can do to work more collaboratively with your team.

1. Write code instead of drawing images

Traditional visual designers present developers with images they create using graphics software that represents what the user of the software will see. The problem with this approach is that the capabilities of the code usually can't match the level of graphics you can create with the likes of Photoshop, and there's no point in creating beautiful designs that you can't reproduce in the final product. Conversely, these same graphics tools can't accurately depict animations that are part of the UX design. This can result in cycles of bug fixes to tweak the user interface (UI). In the end, the visual designer eventually compromises on the design to meet what the system can build.

All my design work is done using HTML and CSS files, so essentially I'm a developer—I'm just not working in JavaScript. This close collaboration creates a bridge between the developers and me, unifying us as a team. We understand each other's challenges, capabilities, and limitations, so I can deliver the best possible designs with complete confidence that I can implement them right down to the last pixel. Using code effectively gives you "what you design is what you get" (WYDIWYG) designs. These designs don't need to be translated from one domain to another. The team uses them as they are within the code, so there are no surprises. Moreover, since these designs are always "alive," I have a good feel for performance and responsiveness, and I can use real application content, such as text and images, to make sure everything fits. Consider that the next time you're working on localization.

2. Engage in continuous design

Traditional visual designers try to complete their designs before development begins, because they're not sure they'll get the chance to modify them later on. It's a one-shot deal—an agreement between designers and developers early on in a development project. This doesn't sit well with agile development teams, in which requirements are constantly changing. As an integral part of the development team, I'm constantly in touch with the application, and I see how my designs emerge as the software engineers develop more features and content. During this continuous design process, I'm constantly tweaking the designs to get them just right.

I also deliver designs in parallel to development cycles. This gives developers, product managers, and quality assurance (QA) professionals the opportunity to provide feedback, such as suggestions for modifying a layout, improving an icon, or changing the color or spacing of a screen element, which I can act upon for the following cycle.

3. Integrate with version control systems

Traditional designs that use graphic files don't lend themselves to version control. Most version control systems are optimized for text files, not graphics, and the visual designer typically creates a proprietary method for managing versions of graphic files. Designing with code circumvents this problem. My designs are lightweight text files that can be stored in Git along with the rest of the application code. They're an integral part of the application codebase: I check in any changes I make so they become immediately available to the developers for their local builds and to our continuous integration (CI) system for the daily builds tested by QA. There are many benefits to this approach:

  • Disaster recovery: All the graphics are stored, maintained, and backed up on Git, just like any other source file. A disk crash on my machine or any other person's machine in our team won't compromise the project.

  • Change history: I retain a full history of design changes, so it's easy to check out a file from several months ago to see what the design looked like at that time. I can even run a "diff" between versions to see what changes were introduced to create a specific design version.

  • Rollback: If there's any regression (and yes, developers do sometimes run up to me yelling, "What happened to my button?") it's easy for me to do a rollback to a previous version.

  • Version change information: When I check out a version, I can see all the changes that went into it and how that might affect my design. Conversely, the other developers using my designs see my comments and know what to expect, what changes I introduced, which bugs were fixed, and so on.

  • Searchable designs: My design files stored and managed on Git are indexed and searchable. If I'm careful to include meaningful comments whenever I check in design files, I can run a search on Git to find a particular version based on specific comments. For example, to find the version with rounded buttons, I can search for a tag that includes "rounded buttons" in the comment.

4. Implement a systematic design system

The visual design of a software system must be consistent throughout all of its screens, but designing an application by screens is an error-prone approach. It makes it nearly impossible to maintain consistency—every time a button changes, you need to update all the screens. In order to maintain consistency, you need a design system, a set of reusable components that you apply to all the screens of an application. This might include, for example, a set of buttons, primary and secondary tables, tab controls, and so on. Those are the obvious UI elements that need to be systematic, but there are less obvious ones, too. Don't forget things like line widths, spacing between controls, padding, and others that are also part of the system.

To maintain a coherent and consistent look, each UI element comes in a range of discrete sizes, and the ratio of sequential sizes is the same for every element. For example, M is always 1.5 times larger than S. This enables a uniformity of the UI across all the screens to create a much more consistent looking application. Here's an example:

Components.jpg

Using a design system has several benefits:

  • Flexibility: It's easy to make changes in UI elements throughout the application to accommodate changes in UX.

  • Design discussions: Design discussions and conflicts are easier to resolve when there are only a fixed number of options for each UI element. This behaves somewhat like design patterns in that a common language simplifies the discussion. People can't envision a 50-pixel button, but once they have a "small" button, they have a clear image in their minds.

  • Continuous design: Both these points facilitate the continuous design process to support changing requirements in an agile development environment.

  • Maintenance: It's simple to maintain a project built on a design system.

The real value of systematic design shone through recently when my organization went through a complete corporate rebranding process that affected all applications across the board. What would normally take weeks to do we completed in one day. That's all the time it took me to update my design system to correspond to the new branding guidelines—the rest was automatic. As soon as developers and continuous integration systems checked out my code, the applications were completely rebranded.

Playing a central role

The visual aspect of an application is a crucial component of the user experience. That's why the visual designer's role is so central to the success of an application. By adapting these design methodologies, you can keep your designs flexible, reduce the risk of costly changes, and improve the design process to support an agile development environment.

Keep learning

Read more articles about: App Dev & TestingAgile