reneherse

Besides any conscious philosophy of the producers & writers, perhaps making the show more character driven as opposed to procedural has an impact on the stories. Maybe it's easier to understand when a suspect's rights are being violated (and to not be banal about it) when you're writing a deeper portrayal of the person who wields the power.

Remote: Yes

Relocate: No

Technologies in my design stack: HTML, CSS, RoR, JS, various UX and UI design tools

Website: https://designerwho.codes

Email: scott [at] designerwho [dot] codes

--

Hey! I'm Scott, a "designer who codes." Principal/staff level product designer & builder working remotely from Atlanta, GA, USA (previously San Francisco & Berkeley, CA).

I'm equally at home in a text editor or Figma file, a stakeholder meeting or collaborative workshop, and I love complex problems. If you're solving something interesting, let's have a chat!

I'm seeking employment or contract. Currently, I consult with engineering teams and dev shops, leading UX and product design for B2B and B2C SaaS products.

→ As a design generalist with 10+ years of experience, I get to wear several hats as we go from idea to launch. Here's a summary of the skills & benefits I bring to the table:

• Product design for SaaS products, focusing on user retention and product led-growth.

-- Exploring opportunities for AI integration is a passion of mine. I love building MVPs or enhancing existing products with features that users demand and stick around for.

• UX & UI design that inspires user adoption & retention. Great UI is based on UX systems thinking that prevents the problems that cause churn.

-- I utilize methodologies like Object Oriented UX, Jobs to be Done, and Design Build Use to unravel complexity and understand what really motivates users and helps them be awesome.

• Designing in the browser using markup & CSS. This workflow allows us to rapidly iterate prototypes for user testing.

-- Handing off clean, shippable frontend code (instead of just Figma files) streamlines the frontend development process. Pesky cross-platform visual bugs never have a chance.

→ If you've read this far, let's connect and see if we'd be a good fit!

Cheers!

Hey! I'm Scott, a "designer who codes." Product designer/builder, consultant and SaaS founder working remotely from Atlanta, GA, USA (previously San Francisco & Berkeley, CA).

I'm equally at home in a text editor or Figma file, a stakeholder meeting or collaborative workshop, and I love complex problems. If you're solving something interesting, let's have a chat!

I consult as a designer for engineering teams and dev shops, leading UX and product design for B2B and B2C SaaS products. As a generalist with over 10 years of experience, I get to wear several hats as we go from idea to launch.

→ Here's a summary of the services & benefits I bring to the table:

• On demand "Design Counseling": Short, live sessions to help teams & execs with unexpected design, product and process issues.

-- Once I'm familiar with your company and product, you can book a session any time you need advice from a staff level designer. (Let's connect now so that I'm GTG when you need me!) :)

-

• Product design for SaaS products, with a focus on user retention and product led-growth.

-- Exploring opportunities for AI integration is a passion of mine, and the optimal AIX will be different between B2B and B2C products.

-- I love building MVPs for early-stage companies as well as enhancing existing products with features that users demand and stick around for.

-

• UX & UI design that inspires user adoption & retention. Great UI is based on UX systems thinking that prevents the problems that cause churn.

-- I utilize methodologies like Object Oriented UX, Jobs to be Done, and Design Build Use to unravel complexity and understand what really motivates users and helps them get shit done.

-

• Designing in the browser using markup & CSS. This workflow allows us to rapidly iterate prototypes for user testing.

-- When I hand off clean, shippable frontend code that's customized to your stack (instead of just Figma files), your devs are free from getting bogged down in visual style and CSS. And pesky cross-platform visual bugs never have a chance.

-

→ If you've read this far, let's connect and see if we'd be a good fit!

I'd love to learn about your product vision and the challenges you're facing. And once I'm in your rolodex (or on your speed dial?) you'll have a design partner at the ready for quick consults or more extensive work.

Cheers!

Email me: scott [at] designerwho [dot] codes

Portfolio: https://designerwho.codes

If we're traveling overnight we'll unplug things before leaving, but otherwise, no rushing home out of concern for the TV :)

Two of my family members have had devices fried by lightning strikes over the years, and not even in regions known for the worst electrical storms.

I keep some portable battery packs handy in case I need to charge a phone, and if I'm working will switch to my laptop and tablet screens.

Of course, one can't conveniently unplug everything (HVAC, big kitchen appliances, etc.) but it's easy enough to safeguard work and lifestyle electronics.

Turning the TV off and listening to the storm is usually a nice change of pace, too.

Also check out the Friday night races at Berkeley Yacht Club. Skippers always need crew so it's pretty easy to get a ride. Just hang out at the gate between 5 and 6pm with your gear and say hi!

https://www.berkeleyyc.org/racing

It was designed with narrow streets and off street parking so that trees could more effectively shade the pavement. Also, the paved streets alternate with bike and walking paths between rows of houses.

One result of the shaded streets and increased greenery is ambient summer temperature that is noticably cooler compared to other nearby neighborhoods.

The original planners worked with the local FD to make sure their trucks could turn around in the cul de sacs.

https://maps.apple.com/?address=Village%20Homes,%20Davis,%20...

As a frontend designer, not a developer, I'm intrigued by the techniques presented by the author, though most devs commenting here seem to be objecting to the code quality. (Way above my pay grade, but hopefully a solvable problem.)

As someone who loves to nerd out on creative processes, it's interesting indeed to contemplate whether AI assisted dev would favor waterfall vs incremental project structure.

If indeed what works is waterfall dev similar to the method described in TFA, we'll want to figure out how to use iterative process elsewhere, for the sake of the many benefits when it comes to usability and utility.

To me that suggests the main area of iteration would be A) on the human factors side: UX and UI design, and B) in the initial phases of the project.

If we're using an AI-assisted "neo waterfall" approach to implementation, we'll want to be highly confident in the specifications we're basing it all on. On regular waterfall projects it's critical to reduce the need for post-launch changes due to their impact on project cost and timeline.[1] So for now it's best to assume we need to do the same for an AI-assisted implementation.

To have confidence in our specs document we'll need a fully fledged design. A "fully humane", user approved, feature complete UX and UI. It will need to be aligned with users' mental models, goals, and preferences as much as possible. It will need to work within whatever the technical constraints are and meet the business goals of the project.

Now all that is what designers should be doing anyway, but to me the stakes seem higher on a waterfall style build, even if it's AI-assisted.

So to shoulder that greater responsibility, I think design teams are going to need a slightly different playbook and a more rigorous process than what's typical nowadays. The makeup of the design team may need to change as well.

Just thinking about it now, here's a first take on what that process might be. It's an adaptation of the design tecniques I currently use on non-waterfall projects.

----------

::Hypothesis for a UX and UI Design Method for AI-assisted, "Neo-Waterfall" Projects::

Main premise: Designers will need to lead a structured, iterative, comprehensive rapid prototyping phase at the beginning of a project.

| Overview: |

• In my experience, the DESIGN->BUILD->USE/LEARN model is an excellent guide for wrangling the iterative cycles of a rapid prototyping phase. With each "DBU/L" cycle we define problems to be solved, create solutions, then test them with users, etc.

• We document every segment of the DBU/L cycle, including inputs and outputs, for future reference.

• The USE/LEARN phase of the DBU/L cycle gives us feedback and insight that informs what we explore in the next iteration.

• Through multiple such iterations we gain confidence in the tradeoffs and assumptions baked into our prototypes.

• We incrementally evolve the scope of the prototypes and further organize the UX object model with every iteration. (Object Oriented UX, aka OOUX, is the key to finding our way to both beautiful data models and user experiences).

• Eventually our prototyping yields an iteration that fulfills user needs, business goals, and heeds technical constraints. That's when we can "freeze" the UX and UI models, firm up the data model and start writing the specifications for the neo-waterfall implementation.

• An additional point of technique: Extrapolating from the techniques described in TFA, it seems designers will need to do their prototyping in a medium that can later function as a keyframe constraint for the AI. (We don't want our AI agent changing the UI in the implementation phase of the waterfall project, so UI files are a necessary reference to bound its actions.)

• Therefore, we'll need to determine which mediums of UI design the AI agents can perceive and work with. Will we need a full frontend design structured in directories containing shippable markup and CSS? Or can the AI agent work with Figma files? Or is the solution somewhere in between, say with a combination of drawings, design tokens, and a generic component library?

• Finally, we'll need a method for testing the implemented UX and UI against the USE criteria we arrived at during prototyping. We should be able to synthesize these criteria from the prototyping documentation, data modeling and specification documents. We need a reasonable set of tests for both human and technical factors.

• Post launch, we should continue gathering feedback. No matter how good our original 1.0 is, software learns, wants to evolve. (Metaphorically, that is. But maybe some day soon--actually?) Designing and making changes to brownfield software originally built with AI-assistance might be a topic worthy of consideration on its own.

----------

So as a designer, that's how I would approach the general problem. Preliminary thoughts anyway. These techniques aren't novel; I use variations of them in my consulting work. But so far I've only built alongside devs made from meat :-)

I'll probably expand/refine this topic in a blog post. If anyone is interested in reading and discussing more, I can send you the link.

Email me at: scott [AT] designerwho [DOT] codes

----------

[1] For those who are new to waterfall project structure, know that unmaking and remaking the "final sausage" can be extremely complex and costly. It's easy to find huge projects that have failed completely due to the insurmountable complexity. One question for the future will be whether AI agents can be useful in such cases (no sausage pun intended).

I craft UX and frontend design in the browser using a method that's likely a bit different from what you're used to. Your dev team will receive clean, shippable markup & CSS that's ready to be wired up. (Handing off pretty pictures for others to build is not my style.)

This frontend efficiency is only the final piece of a specialized, high-value process of product creation.

The full process can be reduced to these three keys:

1. Object Oriented UX analysis & mapping

2. Rapid prototyping: Multiple iterations of the design-build-use cycle

3. Designing in-the-browser, culminating in shippable code

It's a three part combination that lands the knock out punch every time.

• The process begins with object and data modeling (OOUX) to untangle complexity and find trouble spots. It's a fantastic way to increase your team's awareness of the true scope of your product and tease out unspoken wisdom trapped in mental or organizational silos.

• Next, we'll agree on a design brief, and the rapid prototyping phase begins. I'll then proceed quickly from sketchbook to code to browser. (I usually skip Figma unless there's a need for establishing brand & identity.)

• The work on your project will proceed iteratively, in the original (not "Agile") sense of the word. We'll iterate through multiple design-build-use cycles of delimited, self-contained user experience (not just a random fragment or slice).

• The feedback & lessons we gain from each iteration will inform our goals for the next cycle. Each iteration is a step forward in "how it works" as well as appearance and code. The final iteration represents an optimal user experience written in code that's ready to ship.

Sound fun? I've been doing this for over ten years and it works.

I'm currently available to work on a fractional basis with technology and SAAS teams. Let's schedule a brief call, see if there's chemistry, and get down to it!

email me:

scott [@] designerwho [DOT] codes

https://designerwho.codes

Hey! I'm Scott, a "designer who codes."

I'm a lead product designer/builder, consultant and SAAS founder working remotely from ATL, GA, USA (previously San Francisco & Berkeley, CA).

IF YOU...

• have a dev team that needs design support

• have been frustrated by UX strategists who leave you hanging when it comes time for implementation

• see inefficiencies in the gap between design & engineering

• want to learn a better way to design, build & test your product

• are not afraid to shake things up if it means your team can ship something awesome every time...

...we should talk.

email me:

scott [@] designerwho [DOT] codes

It seems there would also be an opportunity for enriching procedurally generated worlds with these concepts of landscape (and shelter) patterning.

And not only Olmsted's ideas. Though I'm not up on the state of the art, a couple other useful landscape and architectural theories come to mind:

-Jay Appleton's "Prospect and Refuge" theory of landscape painting analysis (and its extension into architecture by Grant Hildebrand) [1]

-Chris Alexander's "A Pattern Language" and other books.

I wonder how one would go about training a model using data from existing environments, paintings and photography that exhibit these patterns?

[1] https://www.researchgate.net/publication/286123657_Prospect_...

I've heard of grape vines being used in place of wisteria, which might be better in places where the latter is considered an invasive species. There may be other "friendly creepers" with similar deciduous qualities as well.

Highly capitalized, expensive leasehold improvements plus obscure pricing and surprise charges seem to be the typical playbook of that business model.

Reliable doctor-owned dental practices seem to be increasingly hard to find, at least here in the urban Southeastern US

Can any medical professionals chime in on how it's usually done for tall folks?

"Long torso body type" is, in general, an under-appreciated factor in ergonomics and product design, IMO.

A couple of off-the-cuff examples:

-The longer your torso, the worse a laptop computer affects your neck and posture. For long folks, upright posture requires keyboard and monitor to be vertically separated even more than most off-the-shelf monitor/desk/keyboard trays will allow. So a monitor hinged directly to a keyboard is the worst of all possible configurations.

-Most recent automotive seats seem to force the head forward, excessively curving the spine, and the longer the torso the worse the effect.

On the opposite side of the bell curve, a safe driving position is hard to achieve for drivers around 5ft tall and under. Correct/safe distance from airbags and pedals seems to be overlooked for those of shorter stature.

I wish solving problems experienced by body proportion outliers was a higher priority for product companies.

The level of secrecy at the facility was so rigorous and taken so much to heart that even years after various NRO programs were declassified (decades after program conclusion), the retired civilian personnel I've had the privilege to know were reluctant to speak openly.

I will see if I can persuade one retired engineer I know to join this discussion!

Besides the ocean and elements, there's also a certain beauty in using the latest technology to operate a SAAS company from almost anywhere on the planet.

Very curious to see how tolerable the UX is in an environment that's almost always experiencing some degree of motion independent of the user.

The article only discusses employee injuries; A full accounting would also include data from on-site contractors such as those involved in the heavy construction of the launch towers and other facilities.