Where will/does Subform sit in a designers workflow?

#1

First off, I'm stoked to see the community growing for this product, its definitely sparking off some interesting ways of working. After playing around and looking at how others are doing things, it instantly raised a few questions in my head that I feel could be good for discussion purposes.

Being a designer that's fluent in front-end coding languages I have no problem using code to aid in my design process. With that being said I'm seeing a large emphasis being put on using HTML and CSS within Subform to produce more complex design solutions.

My first impressions are that this would be a great addition for those that lack design based front-end coding skill and would prefer a GUI in order to help get the same result, a good analogy I have is that its almost a hybrid of Sketch and a front-end styling GUI.

On the surface, I'm struggling to see how this offers any benefit over taking a more in-browser design approach. It almost feels as if this is adding another layer of abstraction in the design->production process.

I'd be interested to hear how this stacks up against products used in a traditional design process to help get a better understanding of its future needs and benefits for an UI/UX designer/team.

I'd love to hear some valid arguments for and against on this, along with some possible use cases. I'm not trying to diss the product, but more trying to understand the place it would have in a designers workflow.

Cheers

#2

You might be hoping for an answer from Kevin or Ryan but I'll throw in my 2 cents in the meantime.

I definitely fall into the category you mention - designer with no front-end coding skills. I specialize in user experience design so I am working mostly on wireframes. In the projects I work on, I used to build out hundreds of screens per screen size (usually I work with just a desktop and mobile size). I do high-fidelity wireframes so type size, element spacing, real data, and more are all very important to make sure what I'm designing is realistic. In my projects, I've often done upwards of a dozen rounds of feedback. Every time that feedback comes back, I spend a lot of time shuffling things around, copy & pasting, etc. Having a computer do most of that for me would save me hours every week.
I'm still going to be exporting elements and screens for prototyping in other tools. I'm still going to be exporting PNGs for presentations that are usually built in InDesign. And that's fine with me.

Plus, I'm hopeful that Subforms constraints, being somewhat based on Flexbox, will help me transition into actually using front-end coding.

The CSS escape hatch has so far been helpful because I can change the type. I can manage to look up the attribute I need to change and plug it in to this box.

All of this raises questions about whether my overall workflow should change, not just my tool. Should there be a dozen rounds of feedback? Should this much time even be spend in a design tool or should I be learning front-end coding or working with a front-end designer?

I should also caveat this all by saying that I work on projects that involve a lot of interactive complexity - states and data. And a lot of my experience is on projects in agencies with a lot of resources, dozens of team members, and 6 months to a year of design work.

I'm curious what you mean by "products used in a traditional design process". Are you referring to Sketch, Photoshop, Indesign, Illustrator, and many more?

Hopefully others will chime in. I'm curious to hear about others' workflows, as well.

#3

@dannykeane i am also a designer that works with front-end coding.

one of the things that excited me the most about this project was the layout engine. but as i am playing with subform i don't know how this would fit into my workflow just yet because i can write code. which is also one of the reasons i stopped using axure which is what i think this product directly competes with.

so far i feel like there is a lot of work being done in order to build a layout or a concept that i could simply do in html and css. so while i do agree with what you are saying in regards to this fitting into a designers workflow who cannot code. i feel like the learning curve for those types of designers may be higher with this app.

take the layout engine and merge it with sketch ... life is good ... maybe?

#4

Hi @dannykeane, I am a product designer (meaning I do a bit of everything when it comes to UI design and front-end coding).

What has me excited the most about Subform, where it's going and how I see it fitting in the "traditional" way of designing UI are the following:

  1. You can design in "Freeform" mode by dragging elements on the artboard (just like in Sketch) - which helps in the creative thinking/discovery phase of designing interfaces

  2. Once you are happy with the creative direction and structure of your layout you can switch to the "Computed" mode which not only helps you group your UI into functional components that can behave more like the intended end-product but it also helps communicate your intent to developers and other team members at a deeper level than is currently possible with any "Freeform" design tool like Sketch, Illustrator or Photoshop (i.e. how UI components should react/change to different conditions without using any code) - although HTML/CSS is heavily used currently in Subform I think they are trying to have designers use more of the apps UI to set the behavior of UI components in the final product.

  3. The design process becomes: 1) Build your UI in freeform to quickly plan your layout ideas; 2) Share your ideas with team members/stakeholders; 3) Once you are set on the direction, build the high-fidelity UI and attach behavioral rules to it using the layout engine; 4) Choose a target device/screen size and export UI components to build a prototype in a prototyping tool (i.e. InVision, Principle, Framer...) 5) Present/test your prototype; 6) Provide deliverables to your developer(s) for production (this is the part I believe is unclear right now with Subform, what those usable deliverables are); 7) You now have a detailed UI system made of dynamic and flexible components that can easily be updated, expanded on and reused in the future

Regards

#5

I agree with your description Benzo. In order for Subform to really take on other design tools the default mode should be freeform. After the design has stabilised then Subform should help the designer take the next step into computed mode and create reusable components. The default is now computed mode, which I think is fine if you already know what the design will look like. But for many design situation freeform as default makes more sense.

#6

I have a slightly different opinion on this.

I believe when you're 'roughing out' a design and still making decisions on basic layouts etc, it's probably worth doing that in some other tool. When you get to the point of wanting to create a higher-fidelity prototype, that's where I see Subform really coming in.

Right now, creating 'high fidelity' prototypes requires a designer to make one of two trade-offs, neither of which is very appealing:
1) Create endless variations of static mockups at different sizes. Export. String them together in a 'prototyping' (not really) tool like InVision.
2) Learn to code HTML/CSS (or similar) and actually build it.

For me, Subform's goal is to acknowledge the fact that real UI's are invariably built our out of components, are based on relationships and constraints, and need to scale/respond to various screen sizes. Very few design tools today address this, so that's where Subform can really excel, IMO.

#7

I'm a designer with a code background, so I can create prototypes in code. However, from what I've seen thus far, it's quicker and easier to do that in Subform.

I'm unlikely to start the UI design process in Subform. I'll hand sketch or start with some other low-fi form. The more components I create in Subform that are branded for the products I work on, the sooner I'm likely to move designs there.

While the layout tool is great - much less painful than traditional graphics tools - I would like to see Subform extended to creating testable prototypes. I've been using JustInMind for that the last year or so, and find it very effective. My hope is for Subform to replace that. The layout and component features are much better, but I'd really like to have the interactive component.

All that said, in researching designs, I often need to emulate drag & drop, map navigation, and other interactions that require creating mock-ups in code to test. I expect I will be doing more of that, not less, as apps become less form based.

#8

Personally I would like to be able to start from the very beginning in Subform. Doing nice looking sitemaps is a pain in other tools as when I add a new page etc it doesn't automatically adjust for the spacing. I do my wireframes in sketch simply without using colour or any form of fidelity. Sometimes I sketch them on paper but most of the time I find jumping in quickly helps me explore quicker. Other tools can be used to create style tiles and style collages etc as that is much more free form and is without any constraints. Then once these are done return back to Subform to begin increasing fidelity.

I know how to code so I'm unsure whether many prototyping tools actually increase productivity as low fidelity code sketching can achieve a lot of what prototyping offers. This can even be started at the wireframe stage of the design.

ATM I begin a design and roughly work out a phone and desktop ui. My design files look like a mish mash of half baked wireframes and higher fidelity. I usually use it as you would a sketch to refine or explore a portion of the design. Most of my designing is being done in the browser because of the lack of layout exploration that can be achieved in static design tools.

This is a very ineffective way to design as it inhibits creativity. The mantra in the design community seems to be that we should be deciding in the browser instead of designing in the browser. I definitely resonate with this but current tools don't allow me to design for the browser (responsive layouts in general).

Where would I like Subform to fit.

Asset Creation: Affinity Designer / Affinity Photo etc
Sitemap: --> Subform
Wireframe: --> Subform
High Fidelity Design:--> Subform
Prototype: Marvel / Origami / Browser

#9

I am expecting Subform to sit at the high fidelity prototype end of the spectrum. Sitemap creation is a well-solved problem. Asset creation is done. Layout-aware UI design and prototyping is, as yet, not. Antetype tried it, works OK, but development seems to have slowed to a halt. Sketch is a traditional drawing tool that is trying to bolt-on some level of layout constraint. MS Expression Blend did an OK job a few years ago but was only targeted at Windows/Silverlight development, and was way too complex. I want Subform to solve for layout-aware UI design and prototyping. I hope the guys focus on that and that alone, and absolutely nail it.

#10

Could I ask what tools you use for sitemapping?