A magical combination of Engineering + UXD + Designers

If you have never worked on a team as multi disciplinary as DockYard, I thought I would let you in on a little secret. It’s magical. If there was a greater impact on the speed and effectiveness of an engineering team, it is the Designers and UXD folks who make the magic happen. I have been developing applications with Ember.js for about 4 years and nothing has brought more productivity to my development workflow than this ecosystem. The community of people and quality of tools is bar none some of the best I have worked with on the frontend. However, there is much more that enables a team to be productive. And it is not solely hiring another software engineer when you already have 5.

If you are unfamiliar with what Designers and UXD do, you are not alone. It’s only this decade that companies have formally adopted definitions for these roles. In short, Designers come up with the UX, language, and branding for the apps we build. Through conducting user interviews, researching the market, and deeply understanding the business problem, they can then formalize user painpoints and needs to develop user workflows, wireframes, and high fidelity visual design assets. UX Developers then take those assets and gives them life by codifying them into semantic, accessible, and responsive pages. Although it can vary amongst organizations, here at DockYard, UX Developers specialize in HTML and CSS. Software Engineers, like myself, do the rest. That feeling you get when Spring arrives or the smell of fresh coffee - that is the impact Designers + UXD have on your software.

A Software Engineer’s Perspective

As engineers, we are constantly tinkering to figure out the best path from A to B. We adopt or invent new methodologies to refine our processes, we integrate our software with CI suites to ensure our software is stable, and are always looking to automate tedious processes. The niceties of Agile vs Waterfall then start to seep into our conversations. Ugh!

In my past work, being a part of an all engineering team, it’s possible to get stuck in a mindset that prioritizes speed and efficiency. Software development best practices are useful as a part of an overall cohesive strategy to ship quality software. However, one of the most overlooked strategies is one that is as effective as Wayne Gretzky and Mark Messier, Tom and Jerry, macaroni and cheese, Han Solo and Chewbaca, or Michael Jordan and Scottie Pippen. That is Engineering paired with Designers and UXD.

No matter what industry you may be a part of, we all have deadlines. We finish one thing and desire to jump onto the next. When it comes to feature development, not involving Design early to really think through the user experience can lead to an unpolished product. Overlooking how a feature can impact visually impaired users or not thinking about how integrating localization can improve the experience for your users will lead to costly problems down the road. Moreover, not taking into account a11y concerns could result in some of your users being frustrated with their experience.

Consider this - Have you ever opened an app, only to have it be slightly buggy and subsequently switched over to a competitor’s product? There are so many touch points in our applications that can ruin the experience for even a small minority of your users. I haven’t even talked about the impact this has on maintenance costs during the lifecycle of your product. But I think we can safely assume not involving Designers and UXD upfront in our processes is strikingly expensive for any organization. By prioritizing and ensuring the usability of your application upfront, you may prevent re-work of features after the work is technically done.

As much as software engineering seems to happen behind the facade of a screen passing data back and forth, the main impact of our work is through the visual subtleties and user interactions of our work. In short, even though a software engineer knows the data the user needs, Designers and UXD know the user.

Let us see the difference

Have you ever worked on a project where your backend team built an endpoint for your application and the url, say for a user is - example.com/directory/?uid=scott? Ok, but what introduction to a story does that tell the user? Not a good start. So, let’s see something that we can feel out. I designed a component from the point of a software engineer who is in a hurry and then outlined the important improvements that can happen with a dedicated Designer and UXD team member.

An Engineer’s version

Done. Boom. It opens and closes. I gotta go onto the next feature. Maybe I’ll come back to add animations and improve the colors.

A Designer + UXD + Engineer’s version

Although Designers and UXD would normally spearhead this work upfront, let’s look at some simple improvements they would make posthoc.

Designers

• Icons can be used to make it easier and faster for a user to scan the list of action items instead of just plain text.
• Text could be added next to each icon if in a vertical (instead of horizontal) view for added clarity.
• We need to ensure that the colors used are vibrant and meet accessibility guidelines for color contrast.
• The animation needs to be smooth and give feedback to the user at each step of their interaction with the buttons. Let’s animate each action button to appear on the page sequentially. Also, the user not only needs feedback when they hover over the open/close button, but also clicking button to open and close the menu. Let’s rotate the icon to look like a close button, indicating to the user their next action will close the share menu.

UXD

• The code imports font icons from a CDN for use on only the trigger button. It was easy to spec something out. But let’s just add an svg for better style control and an improved user experience. These will be created by the Design team.
• What if a user wants to tab through the icons? The previous solution removes the outline to indicate an action like Enter could be performed on the button. Let’s add back the outline.
• The markup is a mess and unorganized. Let’s organize it, starting with wrapping everything in a nav element, which is semantically correct. Also, the list of buttons is actually an unordered list. Instead of divs, let’s use a ul block.
• Organization of the CSS seems to be quite nested. What if we could reduce specificity problems in the future? Un-nest em!
• What about users who are visually impaired? Let’s add ARIA markup for accessibility, including aria-label for each button and aria-hidden for the ul section.
• Also we can add role="presentation" to the svgs to tell the screen readers not to read them.
• Adding title attributes to the svg will help when a user hovers over each individual button.

This list is a good start to improving on the original menu, which I admit was an extreme example. Further, this component becomes much more complex when you add actions and routing to each button, support for multiple browsers, responsive viewports, and the list goes on and on. However, even if you made the original example look better asthetically, there were 10 other things that, for your end users, could mean the +-10% difference in their satisfaction with your site.

In conclusion

Pound for pound, pairing Software Engineering with Designers and UXD expertise can have a huge impact on the quality of not only your software, but the well being and quality of the humans that make the magic happen. The ROI is so far reaching and impactful to your users and bottom line, it is one of the best investments a software engineering team can make.