In this article, we’re going to talk about UX. For those of you who aren’t acronym fans, it’s user experience and we all know how imperative user experience is when talking about product adoption. Instead of discussing VUI, CUI, we rather go micro and talk about something which affects all of us and all the projects we do.
Let’s understand why big design upfront days are over and wireframes are dead. Lean UX is the future in designing for less and how all these statements relate to the bottom line that UX practices must evolve to accelerate the production cycle.
In one of our marquee projects, we have built a digital product that can license books, customize them, and then sell them online. Some of the wicked problems that we had to face during the project included buyer’s remorse, disillusionment, guilt, abandoned purchases and so many more, along with all the technical issues that we had to go through. What we did include, as any other good design team would do, we went through the entire UX process. We performed business analysis, brainstormed, read user stories, tried task-goal analysis, worked on visual design and of course did the wireframe.
Why are wireframes dying?
The reason why wireframes should die and are dying relates to the overall nature of ‘big upfront design’. The wireframes represent a symptom rather than a cause. This is not to say that we don’t do any other methodologies, but time after time we fall into a pattern where a big hero design team will come in and talk to the user and everybody involved, work their design magic and then begin a handover process where the designers will give the coding team the design specs; and then the AGILE process starts. This leads to the release cycle, the sprint cycle, some more of the same and the process continue. This is a siloed approach, which tends to be blocking and wasteful because the onus of UX and the user experience falls on one team, the development teams and UX teams always end up fighting with each other. The developers may say they weren’t given enough information, the designer may retort that it wasn’t implemented correctly and then the arguments would go on.
When I asked colleagues and close aides, whether wireframes should remain in use, it was quite surprising to know that a lot of people believe that wireframes are an essential part of the entire development process, because they are faster to create and you avoid things that are unimportant such as visual design and you keep to the things that really matter. A lot of this is dogma, but if you look carefully at the highlighted words you will see that many of these statements are quite condescending. If my client is paying me to think about the entire product, it is not right for me to decide that this is the interaction I’ll focus on and wait until I’m done before considering colours, buttons and other, similar matters. Why should this happen? If it is important to my client that the colours should be right, I should be doing that. So, that’s why wireframes should die.
Then again, the shifting methodology of development does not require, or allow for the up-front design to happen; this is ironic as usability and information architecture don’t live in isolation. This is to say, wireframes may reflect interaction per se, but in a lot of cases may be a coding member or visual designer or information architect will want to place a call to action in a particular place; and although doing so may have a better effect, being in a dogmatic state where wireframes decide everything, we simply let it be because wireframes have been already tested. Another reason wireframes should go is they’re rarely effective for stakeholders, and if our stakeholders are interested in the visual design we should be focusing on that.
It is also getting faster and faster to prototype pixel-perfect solutions, with no need for an intermediate stage where one needs to do the wireframing and then give it to the visual designer. We now have products like Figma, which are so pixel perfect that the prototypes can simply be handed over to the development team and they can just use it in the life code. That is another reason why wireframes should die. Wireframes are also not documentation. Documentation is much too important to leave to wireframes.
Is lean UX the future?
So, what do we do next? If wireframes are dying, then lean UX to be the future. Now, this is not a new idea. Lean UX has been in use since 2011 at the least, and we have been using it in our company as well. The problem with lean UX is that it is quite hard to do as compared to wireframes. Lean UX requires you to sit with your development team and UX team together and have them come up with outcome-based solutions. Instead of putting in a list of features, this uses a manner similar to AGILE development, where the entire team sits together, solves problems and decides on outcomes. It doesn’t matter if the right answer comes from a UX designer or the development team. User experience is everybody’s responsibility. We may use lean UX, but lean UX is not something that you’re able to push on all our projects, because it not a simple thing to implement. Just like AGILE, it needs a very different kind of mindset from not just the developers, but the designers, managers, the organization and also our clients. The clients no longer have to wait for fifteen days or two weeks to give us their feedback.
Unfortunately, this is not a sprint but a marathon that we’re trying to run. There is no judgment here, but after the Cambridge Analytica incident a lot of thinking is going on about exactly what we are trying to do these days as designers. A lot of you know that less is more but from my perspective and with a design angle, what we’ve been trying to achieve more and more engagement, trying to collect more data, trying to ping the user more often, and so on and so forth.
But this is maybe having a negative effect too, such as when you see Facebook setting up billboards stating that they are not bad people, or that they’re doing good for the rest of humanity. As it has been said, we should take a hard left, and look not just at what we’re delivering to our clients or each other, but at the larger systems in which our products are going to work and how they are going to affect society at large. We began with a business-centric approach and then we came to a user-centric approach, but we believe now is the time to work with a society centric approach.
.png){kind=icon}