For at least four years of my career, I was in the waterfall process — creating mockups from requirement documents. These were static mockups that would be uploaded to an internal folder or directory to then be shared with the developers. We had to produce the assets, but that was minimal and was fairly easy because the web was the only medium we worked on. My primary tool was Illustrator, and not Photoshop, as many other designers use to design interfaces. It was the tool used by the team, a fairly small team: one design director and one design manager, with me as the junior designer. What I liked from this process was that we focused on a single tool: Illustrator, which was very easy and comprehensive. It exports things seamlessly and symbols were helpful in many cases. Passing around .ai files is a breeze. Also, we focused on the user experience and the visual design, not the front-end or prototyping. This allowed us to experiment with colors, shapes and text within a specific timeframe in the waterfall process and not worry about going back and forth with the developers. Also, by the time the requirement documents arrived to us in the design team, there were hardly any changes. We were free from worry that it’s going to be changed on the fly.
When I finally moved out of the corporate design life with the waterfall method, I was quickly (and abruptly) introduced to agile method. This was totally new and a strange creature to me that time. Not only visual design and user experience, I was asked to prototype my design in HTML and CSS. This was not that easy. My HTML and CSS skills are basic-to-intermediate, and they are not production quality. Also, I had to do small fraction of things, often simultaneously, and sometimes with minimal requirement definition. Things would quickly change after I’ve done something, and I was asked to move to a different direction. There was no comprehensive requirement document, just a simple meeting and sketching on the white board. I had to formulate everything by myself. Often, I don’t have the time with the details, the visual details, as I have to move fast to delivering. Also, I had to learn HTML prototyping. It was frustrating. Everything moves so fast and I had to move away from all the design details to catching up with delivery.
I understand that, from business perspective, agile method is potentially better. It minimizes risk, as we try to shape a working product from the beginning, even if it’s just a simple version of the whole vision. So, if you take an example of creating your own bike, you don’t deliver only the wheels in the first iteration. You deliver the simplest, working, ride-able version of it: probably a monocycle or a skateboard, even. Then, you iterate it to be a simple two-wheeled bike, probably with a hard seat. You continue to perfect that to be the high-end bike that you can sell for $5,000. With waterfall method, you don’t ship from the beginning. You probably ship by the end of the year, because the product is still in development today, and you cannot ship until it has all the 50 features that are planned for version 1.0. With agile, you only have to ship 2 features within 2 weeks, but you can start selling it and make money, even only for $1 per user per month.
Probably the biggest difference is how waterfall and agile handle changes and user needs. By the time we release a version on waterfall, user’s needs have shifted. They might not need that camera feature after all. Then, you need to plan it out in the next 6 months or 1 year before you figure out things don’t match the current needs again. With agile, you know faster. Within 2 weeks, you know the users don’t need the camera feature after all — and adapt very quickly.
However, how agile and waterfall works can often frustrate designers. Designers are used to experimenting with details — and we surely want to talk about different roles of designers. UI/UX designers we know today are fairly demanded to do HTML/CSS prototyping after they designed the mockups, for the reason of efficiency and that “mockups aren’t real”. Sometimes they are demanded to just mock in HTML/CSS (and jQuery) and iterate from there. There are other job description of UX designers or product designers that focus solely on the user experience and visual design, like what I did in my first career years. This way, they are able to perform user research (a phase away and earlier even before visual design), experiment with layouts, colors, branding, iconography and other visual design application before actually coding this stuff. And by the time product designers come to the need to code the stuff, they’re probably burnt out and/or the requirement has changed to start from the research.
The question is, if UX or product designers are required to code, who would do the research phase and how would they experiment and discuss? You might argue that, that’s why we need to prototype in HTML or CSS — we can iterate things on the fly and not lose time. But then, we should differentiate between production-quality codes and prototype-quality codes. Prototyping requires a fast, birds-eye view perspective, while production requires semantically- and well, “politically”-correct codes. In my opinion, front-end or production code is more to engineering and efficiency, while prototyping is more about exploratory activity. Requiring UX or product designers to do both production and prototyping quality codes is a tough challenge. I know, there are some rock star product designers out there that can do stacks like this but how many out there, really?
So, with that in mind, when I enter a new company, I always ask beforehand if the company truly differentiates between production and prototyping quality work, and if they separate design exploration and design implementation. If they do, I believe they do support good quality design, with good quality research and a focus on experience.
One thing to also ask is how they integrate design within their agile methods.
Do they provide a separate design sprint? How much do the whole team think a good visual design and user experience can bring a positive relevance to the end product?
As a designer myself, I am often confronted with coping up with the quick deliveries of agile methods. I always have issues with the production quality codes done by other developers who implemented my design. But, I have this dilemma: if I code, the alignment, fonts, sizes and shapes could be perfect, but the quality of the code wouldn’t be. If I trust the code into someone else, especially those who don’t focus on front-end development, I risk him or her jeopardizing my details. What I do is to take things a little bit lightly, and request for separate design polishing sprint or story when I could talk with the developers to fix the small details. But still, it wouldn’t be perfect — just at least a consensus. That is, after all, what agile is, a consensus for each sprint, and to battle for it in the next. The perfectionism within as a designer can really turn you to a wildly impatient person, but agile method can sometimes calm you down.