Last year, I’d been enrolled in an agile development project, and the most important thing I learned from this experience is that, there needs to be more cross-collaboration between designers and developers. But before explaining why and how (in my humble, and personal opinion), let’s talk about the users, or should I say, people?
As a UI/UX Designer, whenever I think about users=people, one of the immediate things that comes to mind is this quote:
“Having empathy is an important skill as a designer because at the end of the day you’re designing something to make someone’s life better. In order to do this, you have to empathise with the people you’re building for.” — Unknown
As soon as I read this quote, I truly believed in it. It becomes specially important for people who work in IoT. Why? First let’s briefly overlook what is UI and UX.
Then, let’s say that UX is like the backend — only, it might have a bit more depth to it.
Let’s start with the core basics of UX:
Information Architecture
In order to create a user-experience, you need these three basic ingredients:
Content: basic information of or for the product (website, web or mobile application), so text, images, icons, graphics, modules, charts, etc…
Context: understanding or adding functionality in order to provide something for the user, which leads us directly to the next point — users.
Users: what are the user behaviour and needs? And how does the functionality or information that you are providing fit these needs and behaviours?
These are the main ingredients, but if you really want to create a product that is focused on making someone’s life better and empathises with the people you are building it for, then there’s a few other ingredients you must add. Peter Morville’s User-Experience HoneyComb best explains this.
The product needs to be:
Useful: master the functionality/purpose
Usable: easy to use = ease of use is vital/fundamental
Desirable: engage the user = this is the ultimate quest for efficiency —normally achieved through emotional and visual design
Findable: self-explanatory navigational systems that will ensure users easily find what they need
Accessible: for people with disabilities: also take these people into consideration, they’re that 1% no one ever focuses on
Credible: (needless to say) the user must believe what you are “telling” them — see web credibility project
Valuable: must deliver value to the user
Ideally, as designers, this is how engaging, useful, usable, desirable, credible and valuable user-experiences are created. Following this HoneyComb process will close the gap that makes you see users as computer data, rather than as people.
Although, I believe there’s still one more thing missing, and this is where it gets tricky. But I’m gonna go on a hunch and take a leap of faith. As I was saying right at the beginning of this article, I was currently working as a UX designer integrated in an agile software development team, and what I found that was crucial and a total game-changer in my work, was the cross-collaboration between myself and my fellow engineer colleagues.
The developers. Curious, right? But if you think about it, ultimately they are the ones who build these products and that’s why I consider them the most important ingredient.
(In my opinion) UX is the bridge between the visuals and the implementation. It defines both the design and the development.
This is why designers and developers should be working together. Let’s explore this relationship.
The current status? It’s a complicated relationship. To understand why, let’s go through a series of questions I like to ask people that work in IoT.
Question no.1: Do you work in a software development, IT or IoT based company, that doesn’t have designers?
Question no.2: Or do you work in a software development, IT or IoT based company that does have designers?
Question no.3: Are you happy with the current workflow between designers and developers, or the team in general?
Question no.4: Do you think this workflow still needs improvement?
Normally the answers tend to either be that these companies do not hire designers, or that the workflow between the designers and developers or team in general is still lacking in improvement or non-existing.
So what is the most common issue or ”challenge” that occurs when there is a lack of, or no collaboration at all between designers and developers?
Visuals are not understood. Why?
Unavailable resources (in most cases, the lack of designers): Design or visuals are about senses and dimensions which designers understand the best (no offense to developers). This naturally cases a…
Disregard for the UI: companies tend to think it is feasible to have the developers creating the UI — but they’re not programmed or skilled to think about senses, dimensions, colours, like I mentioned above. Thus why there’s still a lot of shitty and outdated UI’s out there…
Separate departments: when a company becomes big enough, they’ll start creating departments for each type of set of skills, so designers get their own department as well as the developers. And what’s being forgotten is that, it is not enough to consider that only the designers understand the designs intent and the developers the technical limitations — yes designers create the visuals of the product, but again, don’t forget it’s the developers who brings the design to life. Avoiding this collaboration results in designs going back and forth between design and development, or faulty user-experiences because there’s a lot that’s not either being thought through or communicated, which leads to my next point:
Poor or non-existing communication during the concept creation — UX. Because there is no communication within the separate teams there is a natural lack of knowledge on the designers part, of the softwares limitations and on the developers of the products intent.
It’s basically a waterfall case, but I’ve witnessed this being solved. How?
Do the opposite. Don’t separate designers and developers. Get them working together. The benefits include:
Better communication avoids time-consuming conflicts: When your team is communicating, it’s less likely that there are misunderstandings, which is what happens when designers and developers are separated by departments.
Teams tend to think ahead and approach problems together: Teams working together are more likely to anticipate future problems and possibly create better solutions, plus, the teams spirit is increased, as both designers and developers stop getting annoyed because one doesn’t understand the software’s limitations and the other doesn’t have a clue about how colours make users feel.
There’s an increase in the understanding of the users: together, the team will better understand the users point of view — and overall this creates a better understanding of the products needs.
From the Developers perspective:
They should see the designs before they are finalised;
They should participate in design discussions;
And they should get involved with the design process.
This will allow the developers to start thinking about how to solve problems at hand from their end, and tell the designers straight-away what can and what can’t be done.
As far as for the Designers, they can:
Make design decisions aim at making code modular, reusable and consistent;
And start understanding the software and technologies limitations.
You’ll make developers lives easier and they will thank you for it 🙂
As Matej Latin put it:
“I believe that tightly-knit, small, cross-functional teams have a much better chance of delivering value and delight to users.” — Matej Latin
What I’m trying to get at is: It’s not about design taking priority over development, or development over design. It’s equally important for both parties to understand the designs visuals and intent, as it is to understand the development process and implementation technologies.
It’s like building a house — engineers put the foundation and plumbing in place, designers work out the house’s layout and interior. This house wouldn’t be much if:
it looked amazing but had no running water, right?
or if it did have water and electricity, but there’s a shower placed in the kitchen (just saying).
In sum, instead of isolating the process, consider that you’re both designing and building something — Try cross-collaboration.
Related posts
There are 3 comments
The comments are closed.
Non numquam magni atque autem doloribus sunt. Veniam distinctio magni neque reprehenderit eos voluptas voluptate.
Maiores fugiat rerum eum voluptas. Sed facere et quia quos. Nobis blanditiis perspiciatis et molestiae quia eaque.
Iure veritatis autem aut at explicabo quod rerum. Cumque commodi repellendus vel rerum odit et. Perferendis molestias ullam minus iure nesciunt. Maiores quia asperiores cupiditate dolorem possimus amet ut et. Nostrum est ut tempore.
Quis aliquid odio et exercitationem. Architecto explicabo cum sint soluta eligendi praesentium nulla. At ipsam quia qui aut delectus. Magnam autem optio voluptatibus quis pariatur perspiciatis.
Delectus cum suscipit ut ipsam est. Repellat eos ipsam voluptatem sed. Omnis tempore harum quia sint. Commodi sunt quia illum impedit autem pariatur voluptatibus accusamus.
Illo placeat tempore assumenda iure magnam et. Omnis et veritatis nisi blanditiis. Rerum velit deleniti ut voluptatum.
Et veritatis harum consequatur nostrum. Voluptatum est aut amet magnam blanditiis veniam recusandae.