Designing interactions and states is a hard job to get right the first time. What looks good in a static comp often needs adjustments when implemented. There is a tendency to overcompensate to express a change that is easily recognizable sans-interaction. Also, once you start using the app you might find that what you originally designed is just plain wrong.
Adding to the mix is how your components will react in different scenarios, like when data changes. Something that was initially enabled could easily become disabled, error out, or indicate success. Elements come and go on the page, and just showing these states statically on an artboard leaves too many unanswered questions.
Is this going to disrupt the user? Is this an appropriate time/place to show this message? What happens when a user dismisses this? Is 70% opacity too much? Not enough? How should error messages transition in and should they displace content?
So, how do you get from A to B?
Some engineers appreciate freedom and can run with the ideas, while others will need some more guidance. It’s extremely important to have an open dialog with your team. You all need to be on the same page and be ready and willing to make a lot of changes on the fly. It’s really helpful if you are comfortable getting in there and making these changes yourself, or just in the browser, or outside of the project in a CodePen to cross-check your ideas.
Not being able to see how two things are different is a big problem.
If you work through a design implementation iteratively, circling back should be a breeze. Work in broad strokes, increasing precision along the way.
All the little things overlooked or forgotten altogether have a greater impact than you may think. They separate a good app from a bad one and keep users coming back. They’re part of the user experience and directly reflect on your brand. They should be carefully thought out to help support users in completing their goals.
Subtle differences that matter
Communicate.
Chances are, what you came up with is going to need adjustments for one reason or another. Documentation can help, but it can quickly become obsolete once you start actually using the product, and all you’re left with is a well-documented recipe for the wrong solution. You need to get your hands dirty, testing ideas and thinking about these micro-interactions to truly call something done.
You can always go back and update your source files with the tweaks you made in code. Creating a living styleguide based on actual markup and styles is another great asset to have and reference. Being able to abstract out real components from layouts is extremely handy for clients and team members to get a global view at what actually makes up the app.
Above all, don’t design in a hole for too long before you come up for air.
Let's discuss...
Let us know if there are any other guidelines you follow when designing interactions and states, in the comments below. Or drop us a line. We're hiring people with strong ideas about good design.