Sam Pierce Lolla

Sam Pierce Lolla

Ann Arbor, MI Helping startups w/ product design @ Directed Works Joined about 10 years ago via an invitation from Jason A. Sam has invited Hung Truong

  • 15 stories
  • 193 comments
  • 170 upvotes
  • Posted to StackOverflow Navigation Redesign, Feb 15, 2017

    Instead of quickly judging the bar, take a moment to understand their process--this is a good example of a mature (but lean) design team making a big decision using insight instead of opinions.

    Notice where and how they measured their hypothesis (instead of relying on opinions), how much ideation they did before even starting the project, how they did usability and A/B testing while staying lean, etc.

    I found it really helpful :)

    2 points
  • Posted to Is Adobe Experience Design (XD) Ready for Production Work?, Feb 02, 2017

    Lots of valid points here, there's still a lot of work to be done on XD. Most popular feature requests are here: https://adobexd.uservoice.com/forums/353007-adobe-xd-feature-requests/filters/top

    That said, many of the requests listed aren't necessary for XD to be considered production-ready on a lot of UX/UI teams. If they fixed numbers 1, 2, 6, and 13, plus the ability to comment directly on prototypes, I'd be about ready to switch from both Sketch and Invision.

    Here are my favorite XD features for the curious:

    • The ability to edit symbols in place without being whisked away to another page is really convenient
    • Toggling between designing UI and prototyping in the same app saves a ton of time
    • Repeat grids (especially nested repeat grids) are another huge time saver.
    0 points
  • Posted to Authoring the design spec?, in reply to Joe Hsu , Jan 29, 2017

    Sure thing.

    So a UI component would be a Table for example. We have a bunch of versions of our tables in Sketch--tall rows, short dense rows, sortable tables, etc. These are defined w/ pixel precision on an 8pt grid using the standard set of colors and type on each platform (web, ios, android). There's only one high-res spec for table, though.

    The "feature" spec is separate--an example might be the Rainfall History page. The spec includes how the amount of rain should be formatted (units, degree of precision), how many days to show, what to show if there wasn't any rain, and what the columns should be. A different page, Heat History, would have different content in a similar format--this time units in degrees, with different columns, etc. The images on these pages are just rough wireframes of a table, but they both link to the original Table hi-fi spec.

    Happy to answer any more questions if that's not clear!

    3 points
  • Posted to Authoring the design spec?, Jan 28, 2017

    I've been running the product design team at FarmLogs for a few years, here's how it went for us.

    We didn't use anything more than casual documents or Invision for a long time. As our product grew large, it made it really hard for engineers, designers, and PMs to understand how our own products worked. Backend refactors would subtly break something without us knowing until a user complained much later, important details in how we showed data got lost in redesigns when a new person came onboard, etc.

    Now we have two forms of specs: our "Design Language" is in Sketch documents shared in Zeplin, which help us maintain the latest version of all of our UI components, visual styles, animations to some degree, etc.

    Our "feature specs" are wireframes and descriptions about the product itself in a wiki. They're co-owned with engineering and product management, and they describe what each page does, how the information should be displayed, edge cases, etc. These feature specs link back to the hi-fi Zeplin components so engineers know what "building blocks" to use to build each page.

    It's a pretty new distinction for us, but the separation between abstract components that "hold" data and the data and pages themselves has already been a big help to our team.

    5 points
  • Posted to Ask DN: Job title for Product Designer who writes Javascript?, in reply to Peter Vogt , Jan 27, 2017

    Design Technologist

    I dig it

    1 point
  • Posted to Ask DN: Job title for Product Designer who writes Javascript?, in reply to Caleb Sylvest , Jan 27, 2017

    Makes sense

    0 points
  • Posted to Ask DN: Job title for Product Designer who writes Javascript?, in reply to No Name , Jan 27, 2017

    Ha! That actually describes our workday pretty well.

    1 point
  • Posted to Ask DN: Job title for Product Designer who writes Javascript?, in reply to Nick M , Jan 26, 2017

    I am a hiring manager and I have to strongly disagree with earlier commenters - simply listing it as "Product designer" will get you job applicants that don't have the requisite javascript skills.

    My hunch, too. Very useful, thank you.

    0 points
  • Posted to Ask DN: Job title for Product Designer who writes Javascript?, in reply to Al M , Jan 26, 2017

    I love it so much I moved across the country to do it! (Current positions are open for remote work now though).

    Basically I tell people we're taking some of the most complicated kinds of data--geospatial satellite imagery of crop growth, real-time commodity market prices, etc--and distilling it down for an audience that needs extremely straightforward insights in their pocket.

    I think the number one thing I look for in work is meaningful impact. Agriculture's impact on humans and the planet puts it at the top of the list.

    0 points
  • Posted to Ask DN: Job title for Product Designer who writes Javascript?, in reply to jj moi , Jan 26, 2017

    Very interesting, thank you

    0 points
Load more comments