Design Implementation
From vision to developed reality. A look into design implementation, what it is, examples and maturity
Introduction
From my experience working in small startups, and larger organisations, one of the most important (but sometimes a little overlooked) part of the design process can be the implementation. Between design and the final developed product, the implementation stage is critical to a well-functioning, usable and good-looking interface.
A familiar scenario?
“The developed design functions and looks nothing like the designed version — Designer A”
Why does this happen? The design implementation has not been considered very well, at all, or it was left to developers to figure it out.
What do we mean by implementation?
Implementation is the crucial step between the designed vision and the developed end-product. If you’ve found yourself doing some of the below points, you’re already doing it!
- What assumptions do you have on how it currently functions and how this will impact something else?
- How does the interface function?
- What native keyboard types are used for inputs?
- How is the design accessible and what needs to be explicitly stated (ARIA:Accessible Rich Internet Applications)?
- What happens when getting data from a server? Loading states
- What happens if data can’t be loaded from the server? Fallbacks and empty states
- What happens when data is being processed? Loading states
- How are specific errors handled? With helpful options on how to resolve the issue?
- How do components and images scale responsively?
- What are the fallbacks if content doesn’t load? Meta descriptions?
- Has the design been stress-tested across different viewports sizes?
- Consideration of usability + feasibility (native UI vs custom components)
- Are assets optimised for file size and SVGs (Scalable Vector Graphics) optimised with meta information?
Examples of poor design implementation
1) Dumb inline-validation
Example: Validating only when an input is filled in, but not validating against the actual data in the input. Tick showing only when input is filled, but does not validate the actual data.
Why is this poor? Misleading users into thinking inputted data is correct (when it’s not).
Better implementation: Only use live inline-validation where data can be properly validated. If some data needs the server to validate, only use positive live inline-validation when its been validated from the server
2) The difficult promo code input
Example: A native text-keyboard and no auto-spacing (input masking) means the number is harder to type and double check. This is prone to errors by mistyping.
Why is this poor? It’s difficult to check if a code is entered correctly if it doesnt follow the same format (ie. 1748 1294 1023 5781). It’s also harder to type a number code on the native text keyboard.
Better implementation: Use input masking for auto-spacing to make it easier for users to double check entered data. Explicitly state in the markup-code the ‘number’ keyboard for the input-type, so the native number keyboard is used instead of text.
3) Data format not matching the reference
Example: For the payment form, displaying the card expiry format as “Month” (ie. December), whilst on the physical card, the expiry date is in the number format (ie. 12).
Why is this poor? Users need to think and convert the format on their card to the format the form is asking for. Prone to accidents and error.
Better implementation: Always follow the same data format of the source you’re referring to. If on the physical card the month is numeric like “12”, the month input options should be numbers, not text.
4) Undefined SVG icons
Example: SVG icons that have no meta title and role=img explicitly stated in the code markup
Why is this poor? Screenreaders wont recognise SVGs as images or titles
Better implementation: Optimise SVG code by stating the SVG role=img, and giving it a title to describe the icon for screenreader users.
Design implementation maturity
To understand better the maturity of design implantation you or an organisation have, I created a scale with explicit real-world examples:
Low DI maturity
- Giving only screenshots / static images to developers at the very end with no discussion.
- Developers must decipher and make assumptions on how it should behave and work. Something is developed that functions and behaves wildly different to expectations.
Medium DI maturity
- Giving developers previews with code inspect, so styles and sizes can be accurately followed.
- However, developers are often out the loop until the very end. Minimal functionality and details are provided.
High DI maturity
- Presenting through with developers early on to check for edge cases and scenarios not designed for — with developer involvement making iterations, if and where needed.
- Giving developers previews with code inspect, detailed assumptions and acceptance criteria on how it should work. Also explicitly stating markup-code such as input-types and ARIA considerations. If analytics are going to be used, state which component should be tagged (ie. event, category). Optimise images to reduce file size (so they are loaded quicker), optimise SVGs with titles (so screen readers can read them).
- After being developed, designers are invited to preview the developed design on a testing environment for manually testing + double checking everything is working as expected before going into production.
In summary
Never leave anything to assumption
Developers are not there to decipher and try to figure out what they need to develop.
Be explicit
State exactly what it is, how it should function and what is expected. Detail everything even if it may seem obvious. Have very clear assumptions and acceptance criteria.
Involve developers early on
This is crucial to making sure the design is responsive, doesn’t break and edge case scenarios are considered. Developers also like to be a part of the process and not only invited at the very end. Their input and technical knowledge is invaluable.
Preview and test the developed design before production
Essential for checking everything is functioning, behaving and looking as expected, before going into production.
Thanks for reading and hope it helps improve your workflow!
Be the force of change you want to see.
