2

Instead of a waterfall style of software development where the development follows the design process, I wonder if anyone has experience with what I am dubbing the 'fountain well' style of product development where the developers rapidly prototype the product to lock in the functionality and then the UX/UI designers refine the look and feel, but in a way that does not impact on the function or business logic of the product/service.

I have seen this process applied where Agile teams are able to decouple the business logic from the implementation framework/platform, and where the visual and interaction design logic is also abstracted away from the implementation details. I am wondering if any developers or designers have applied this approach to product/service design, and whether the project outcome has been successful in terms of meeting project schedule and resources/budget.

I think it is important to make some distinction of this process compared to waterfall and Agile methodologies, in the sense that even though the design and development processes can occur in parallel, the development proceeds the design and after the design implementation there is a minimal amount of effort incurred in refactoring the design to developed product/service.

The question I would like to ask is whether the decoupling of the business process design from the solution architecture design and the user experience design is a different way of product/service development compared to LEAN and AGILE development processes, and therefore should be referred to as a different style of product/service design and development.

I have found a paper on a 'fountain' model of software development, but have read through it because it seems to describe something different even though the terminology is similar.

Improve this question
7
  • I don't quite know that I follow you, but I think you're talking about an MVP framework: en.wikipedia.org/wiki/Model%E2%80%93view%E2%80%93presenter In general, this is something developers and designers often lobby for...having distinct decoupling of UI from business logic. There are many ways to handle it technically. All that said, at the end of the day, there's still things that have to make sense logically between the UI and business logic, so it's not a magic bullet.
    – DA01
    May 14, 2015 at 3:50
  • Perhaps, but in a MVP framework, does the development come before the design? What I am suggesting here is that the developers create a prototype based on any development framework then the designer comes in and apply the UX/UI polish. Assuming that the team is agile enough and the decoupling of the UI and business logic is there, then it would seem possible to build before designing without affecting the ability to make interface and interaction design changes and not incur substantial costs to refactor the implementation details.
    – Michael Lai ♦
    May 14, 2015 at 4:00
  • It depends on what you mean by 'design'. In my book, development is design as much as UX is. You can't really develop something without also designing it--whether that's the developer or UX person or business lead or whoever. Ultimately, a prototype is a design. So, based on your last comment, I think you're actually referring to Agile. Get something built first then make it prettier as you go. (Also known as MVP: Minimal Viable Product)
    – DA01
    May 14, 2015 at 4:01
  • 1
    Finally (maybe this should all be re-written as an answer!) you aren't totally off the mark, though. What you can do--even if you don't change the entire process--is to encourage a decoupled MVP framework. Have data not be directly coupled to UI output. That will give you the most flexibility.
    – DA01
    May 14, 2015 at 4:06
  • 1
    I'm voting to reopen this. The question of whether it's useful to attempt a decoupling of UX from business logic for product development is a pretty important one in UX, and has deep history behind it which is quite helpful for the community I think. @MichaelLai I'd invite to to narrow the question perhaps?
    – tohster
    May 14, 2015 at 19:15

1 Answer 1

Reset to default
1

Based on your comments, I think I understand what you are envisioning.

This comment helped:

The developers can 'design' a system that caters for changes to the interface and its interactions, and the designers can 'design' an interface that caters for changes to the underlying implementation platform/framework.

I think that's a great idea. However, I don't know that it exists in reality.

I think you can get part of the way there by looking at using an MVP (Model-View-Presenter) software pattern

The MVP concept has evolved and expanded and there are now several different MV* types of patterns. More recently, frameworks such as Angular.js have adopted the term MVW (model-view-whatever).

Regardless, no matter the type of MV*, the goal is typically the same: separate the presentation logic from the business logic.

This can be done with all sorts of technologies. Services and APIs being common where your UI layer 'requests' the data directly, receives it, then formats it to fit the UI.

Does this mean you can build one end prior to the other? Well, no. Not really. No matter how much we decouple the two, there's still dependencies on both that, if you want to be efficient with development, need to be figured out and addressed sooner than later.

Which leads us to Agile. Agile comes in many flavors of course, but the underlying principle (IMO, of course) is that you don't try and develop one aspect of the solution independent of the other. Instead, you do them in tandem. Together. So that each aspect can react to needs of the other. And you do this feature-by-feature in quick sprints vs. the old "design for 6 months, then develop for a year, then realize you need to change something" Waterfall process.

I'm trying to think of a good analogy and this is the best I could come up with. Let's say your project is to design mass transit. The UX team is in charge of the vehicle, development is in charge of the infrastructure.

For both teams to work independently of each other, they have to either make assumptions, or accommodate a wide range of variables. If the UX team hasn't designed the vehicle yet, what does the dev team do? Do they build train tracks? A highway? Dig a tunnel? Well, to be most flexible, they should do all 3 so that they can accommodate whatever the UX team comes up with. Of course, this isn't efficient as you're not building a lot of stuff that may not actually ever be used. Even if not fully built, we're talking about buying multiple rights of way, stockpiling materials, etc.

So the other option is to make an assumption. Let's assume it will be a train and we start building 100 miles of railroad tracks.

6 months later, UX discovers that what people really want was a bike path. Well, not all is lost, as we've already developed the right of way, but look at all the money that was spent on rails...and these have to be yanked out now to make room for the bikes.

In an agile world, maybe the teams would have worked together and built 2 miles of railroad tracks first. Then maybe 2 miles of roads. And then 2 miles of bike paths. Upon building the bike paths, they would have figured out exactly what was needed. And while they may have wasted 4 miles of other routes, they didn't waste 98 more miles of railroad tracks to figure it out. :)

Improve this answer
8
  • Based on one of the projects that I have been involved in, I would say that this is the approach we had to take to produce a MVP. The reason is because the business process is changing as we are building the product, and therefore the implementation and the interface design also need to evolve independently of each other. In one instance the developers build the scaffolding for the interface before it was implemented, then the business logic was applied to the interface!
    – Michael Lai ♦
    May 14, 2015 at 4:22
  • @MichaelLai to me, that sounds like typical 'enterprise process'. I work in an org that does the same thing. Often business requirements are written AFTER the UI is halfway built. I don't have a solution for that other than to say "Lot's of big companies simply have really bad processes and there is no magic bullet to fix it." :/
    – DA01
    May 14, 2015 at 4:27
  • I am not actually saying that this 'fountain' process is a bad thing. In fact, in the same way that 'Agile' was designed to cope with changing requirements between the design and development process, I think that this is the way forward for projects that have to cope with changing business, technical and user requirements (plus I get to coin a fancy term in the same process).
    – Michael Lai ♦
    May 14, 2015 at 4:37
  • Keep in mind that Agile is meant to handle exactly that...changes in business, technical and user requirements. You may not need to reinvent the wheel (though that's fun to do too).
    – DA01
    May 14, 2015 at 4:39
  • But in Agile the 'UX person' seems to always be the bottleneck in the sprints... I am hoping that this will convince some people that it is the process/methodology that is causing the issue, not the fact that the UX person is trying to hold everyone else up with crazy talk of doing research and testing on the actual users :D
    – Michael Lai ♦
    May 14, 2015 at 4:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.