Striking the balance between user needs and efficient development
As a designer in a team working together to deliver improvements to a product or service, there will be many times at which you will have to deal with compromise.
I have previously written about picking your battles in the war for better user experience, but it would be unfair to think of every situation in these terms; a situation where you concede smaller conflicts to put your foot down successfully when something of greater importance to the user experience is in the balance.
Compromising isn’t necessarily about having to make trade-offs that result in a worse user experience. Oftentimes they can be the opportunity to rethink your approach to the design of a particular solution and find a way to incorporate the new constraints to the situation into your work.
The reason I find myself writing about this subject is because of some recent design work around a set of data only required in a particular circumstance. Let me outline a hypothetical that mirrors the functional aspects of this particular piece of work; everyone loves ice cream, right?
Let’s imagine that I’m the owner of an ice cream company, and I control the ice cream vendors and what they are able to sell. For this example, each ice cream vendor will have the ability to sell 3 distinct products;
The ice lollies and ice cream tubs come as they are, but the ice cream cones can come with some tasty extras. Let’s say you can choose from sprinkles, strawberry sauce, and a chocolate flake to go with your ice cream cone. As such, these options are only available to the ice cream vendors who sell ice cream cones.
To bring this back to interface design, we’ll imagine that I have a screen listing out all of the vendors that bear my company name, and we’re able to click into each of them and select which of these items they’ll be able to sell to their customer. Here’s what I would imagine that particular screen to look and work like:
So we have three unchecked checkboxes for our three distinct products. We want this particular vendor to sell all 3 products, so we check all 3 of the boxes. However, when we check the box for ice cream cones, we open up a set of 3 related checkboxes under it for those tasty extras that can come with the ice cream cone.
As a solution to the problem of displaying related options to a choice on a single screen, it feels rather eloquent if I do say so myself.
Consider the development approach
Back to the real world and walking through this design and how it is intended to work with developers brings another perspective to the conversation; how do we build this. In the conversations I had around this particular approach to the design of this interface, we would be making more than one call to different data stores to both display the content of the page and to save the choices made by the user. With the underlying framework of the software, this meant that there would be much more work and a longer time to build from a developer point of view.
Although the developers agreed that the solution was ideal for this scenario and incorporated everything the user needed to do in a simple interface, the amount of work needed to implement this steered us to scrutinise the solution more thoroughly. As I mentioned at the top of this article, there are ways in which we can make trade-offs without compromising the user experience.
Less eloquent, but still usable
For this particular piece of work, designing and building using the guidelines in the GOV.UK Design System provides us with a set of standards we can follow to deliver a consistent user experience. One of these guidelines when designing transactional journeys — journeys which require data input to move forward in a process — is to deal with one question per page.
This is what our solution above did; you could handle the inventory of an ice cream vendor on a single screen. But we now have our additional technical constraints and need to split this interaction out into separate screens, so we removed the second checklist that is revealed, and moved it to its own page that only gets displayed in the user journey if the relevant option is selected.
We are still designing to our principles with this solution as one page deals with the products and the next deals with the associated toppings that can go with one of the products selected.
Although it doesn’t feel as neat and efficient to me, we are still only asking the user to complete the additional information in the situation where it is required. If the user doesn’t select ice cream cones, they won’t see the next screen to select the associated toppings.
The result is that we are delivering a consistent experience to our users and easily understandable interface, and we are also considering the needs of our developers along with the technical constraints they have to deal with.
What can you do to strike the same balance?
Involve your developers early
If we had not had these conversations after our first attempt at designing this particular user journey, we may have gone into user testing, iterated some more, and spent much more time on the design only to find out that technical constraints would have prevented this from working as we had intended.
Having conversations around your work early and often helps to bridge what would otherwise be a large gap in understanding throughout your team. As part of these conversations, the later stages of the process will go more smoothly as there will be fewer surprises to spring on developers as these conversations involve them so they have a good idea of what kind of things they’re going to be building in the near future.
Realise that not all compromise is bad for design
The main thing I have learned while working through this particular problem is that not everything that appears to be a compromise in your design is actually a compromise. Sometimes these discussions and uncovering of new constraints result in delivering a better all-round user experience.
In the real world away from the simplified example ice cream example, our discussion with the developers brought to light a number of additional consequences that would have required their own workaround solutions to handle the fallout from the originally proposed design.
By other team members having the opportunity to share their knowledge of the system, we were able to design a solution that would result in less work for our internal teams, and reduce the cognitive load of our users by keeping our user journeys more streamlined and usable.
Value the input of non-designers
Although I have been specifically referring to developers in this article, the value of input from other members of your team will always help to guide you in a direction that takes all of their concerns into consideration.
You will only be able to gain invaluable insight of others by sharing what you have done.
You have to be open to constructive criticism of your work, and remind yourself that any feedback of this nature is not a criticism of your ability, but a collaborative process with the ultimate aim of providing a better experience to the people that you are designing and building your product for.
Originally published at https://westleyknight.com.
