Here you will find ideas and code straight from the Software Development Team at SportsEngine. Our focus is on building great software products for the world of youth and amateur sports. We are fortunate to be able to combine our love of sports with our passion for writing code.
The SportsEngine application originated in 2006 as a single Ruby on Rails 1.2 application. Today the SportsEngine Platform is composed of more than 20 applications built on Rails and Node.js, forming a service oriented architecture that is poised to scale for the future.
From a user experience designer to software developers and engineers: What you do every day is part of designing the experience of products.
You may not be the decision-maker on what font is used, or where the save button goes on the login screen, but you build that save button. You apply classes that switch the text from standard Times to the sans serif from your company’s style guide.
You also have eyes! You’re a human. You use applications every day, and when one doesn’t work right, it bugs you.
I'm guessing Github went down again.
Because you actually build the experience, you are taming the code base with flexible and reliable methods, you are not making phony HTTP calls. You test in the staging environment before it is released to the wild.
You are the last to weigh in on the usability of a product before it gets built. You transform conceptual ideas into real working solutions.
It is impossible to nail down every detail when designing a product, especially a complex application. Feedback from designer and developer alike fills in the cracks. Also, many designers don’t have the programming chops that developers do, or even a basic understanding of HTML and CSS. Clever solutions to complex usability issues sometimes hide in how styles are applied to markup, or how the interactions are scripted. Think searchable dropdowns, advanced tooltips, and client-side error validation — not doable via visual design alone.
This applies to solutions that have already been implemented and released for days, weeks, months, ones that are ridden with usability quirks. Usually this is because it is tougher to sell usability (though it can be done).
When you see the problem, raise a red flag. Fixing that little usability issue now, however small it may seem, reduces friction on other products because your colleagues will not have to fix it later.
I am going to assume you are totally with me here, and you are super excited to make things easier to learn and more enjoyable to use! Right? Okay.
So… how the heck do you do that? And how do you know if something is not “usable” versus “ugly”? When should the concerned developer speak up?
Now is the time. Shoot the designer on the project a message saying that you think a certain part of the design does not work very well. Got an idea to improve the concept? Awesome! Did you already build a working prototype? Best Christmas present ever.
Behold, the login screen — the most under-loved interface.
Let us propose an example: Debbie Developer has tested the application a hundred times, and part of this logging into the application each time. She has always noticed a few things are off. Nothing major, but they’d be quick fixes.
Debbie decides to take action and pings Ted, the designer in charge of application login:
Hey, Ted, I noticed that in our login screens that it asks the user to “Please enter a username/password, but the field label is “User Name” -- I think it should be “Username” to be consistent. Also, I can move the ‘forgot password’ link next to the password field. I could make both of those changes really quickly (in about five minutes). Are these changes OK? Should I proceed?
Good catch, Debbie! Yes, those changes would definitely help this screen. Please put the ‘forgot password’ link immediately below the password input field. Also, capitalize both words (“Forgot Password?”).
Just by speaking up, the developer just fixed a consistency error now and for multiple screens in the future. Just in a single message.
But say you are unable to get a hold of a designer right away, or even at all! Don’t fret. Remember, you are a user experience designer already. Just make spotting and fixing usability issues a part of the code review and testing process.
Perhaps, in this example, it is entirely kosher to go right ahead and submit a change to the application. She could then make some changes and work them into the versioning control process, and request that the design team review the changes and give them the all-clear. In this case, meetings to discuss the change don’t have to happen since a working copy is available to take a peek at.
Hopefully, before implementing something, you and/or someone else is testing the designs out and ensuring they work as intended, the solution is reliable and usable.
But what does “usable” mean? In simple terms, a usable product is one that is easy to learn and enjoyable to use. But those are words. I don't know about you, but I’m a big fan of visuals.
One of my favorites is a common reference for user experience designers: the usability pyramid. It visually depicts how a product must mature through six levels to become a truly memorable product.
No aliens were harmed in the making of this pyramid.
The ‘Functional’ layer is built simply by getting the application working as intended, and it becomes ‘Reliable’ with test-driven development and bug squashing. The final leap is making it usable.
To accomplish such a feat, utilize this checklist when testing something out:
Note that this checklist does not focus on subjective measures such as "it's pretty” or providing feedback that starts with “it would be cool if…”. While aesthetics are very important, and cool features are cool, usability is about helping users do what they need to do more efficiently and quickly.
How an application is built also affects the accessibility of the interface. Screen readers need semantic markup for the implementation to be reliable. Body copy needs to contrast enough with the background to be readable, otherwise, it is not functional for those with poor eyesight. I discovered this sweet tool when testing readability for error messaging. We ended up darkening alert copy text and lightening the background.
Over all, keep focused on making sure it works really well. If you are looking for bonus points, you can also double-check to ensure the designs are following good interface conventions!
As you develop the product, as you build new features, keep an eye on usability. Use the checklist during testing. And remember: it is all about making a product easy and enjoyable to use.
P.S. Get a crash course in usability by reading these articles: