User Interface Driven Development: Uniting Business, Design and Development
There’s a concept that seems to stand out and is more of a practical and professional practice that’s not necessarily taught: User Interface Driven Development. There are articles out there that use the term, although I may be referring to it differently with what I’m thinking. It’s a concept I’m associating with software development, in particular.
Previously, I’ve heard others say that Software Development isn’t exactly all about programming. There are a number of facets involved, which falls very much in line with the designer’s (or creative) process. I’ve been exposed to something similar, but not from a development standpoint. In Hearken’s case, software development is a full-fledged team effort spanning business, client, and those involved in both design and development. The term stakeholder has also been described to be an active participant in this process, but can vary in definition. I see them as kind of like clients you need to impress.
Without having clear communication lines and seeing eye-to-eye, it’s difficult to envision this process working well. With our smaller team, I’m observing great interaction and the ability to work pretty cohesively from one person to the next using tools such as Slack, Trello and Github. In bigger organizations, I can only imagine that without this in place, it creates all sorts of problems in product or service. Not to mention, with the actual business itself and the unfortunate bottom line; another separate discussion for another time.
In thinking about User Interface Driven Development, the interface, user experience and layout, rough aesthetic, different business requests, and a variation of test-driven development all factor into the requirements. It’s a process that is practical and may just be common sense to some. Design the interface, then code. Hearken architects their designs with maintainability and scalability in mind extending itself into front-end development; the bridge between user interface and back end development. We have our own styling system (shout out to Duncan), which drastically changes my old practices for the better in naming conventions and file organization. It ties nicely into the use of Sass and takes advantage of pre-processing that makes perfect sense.
“UIDD” seems pretty straightforward, but everything lies in the details from structure, consistency, specificity and deliberate decision making. There’s no skimping on this, either. Again, it’s more about maintenance and scaling. But it also irons out many of the wrinkles on all sides of the equation. Business gets their input, designers are given room, and developers can handle and add code to the technology stack accordingly. There are significantly less issues with things like:
“I forget to mention (feature x) needs to be included. We need a more prominent button (or something else that can alter layout pretty good).” -business to designer
“It’s not a good idea for the interface to include (feature y) because that's not going to work with our page setup." -developer to business
“I have to scratch the design I was thinking because (person) said (random reason)” -designer to either business or developer
It really cuts into production time, and in the startup world, is crucial. Without having an efficient process, all unnecessary hiccups can add to a setback in progress, and can delay releases. Something that should be kept to a minimum.
Designer Thoughts
One of my design mentors told me knowing web design would be advantageous in software development; that made sense on more of a conceptual level. I think what he was referring to was designing in the browser, which is somewhat different from creating high-fidelity prototypes in your software of choice (i.e. Photoshop). With relatively good mastery of this, I’d encourage getting involved with technology companies if you haven’t just yet.
