Welcome!

kerryis
  • ๐Ÿ˜ present โœจ
  • ๐ŸŽฒ randomized ๐ŸŽ‰
  • ยฟdesveloping?
  • โžณ (t)here โ˜œ
  • ๐Ÿ  home at last โŒ›๏ธ
  • ๐Ÿ—บ all over โฒ
  • ๐Ÿ‹ carrying on ๐ŸšŒ
  • ๐ŸŒฝ listening ๐Ÿ‘‚
  • ๐Ÿƒ breathing ๐ŸŒฌ
  • ๐Ÿ’ gazing ๐Ÿ‘
  • lucid dreaming ๐Ÿ˜ด
  • ๐ŸŒ” waxing poetic ๐Ÿ““
  • ๐Ÿ– waxing on/off ๐ŸŒ’
  • ๐Ÿƒ improv(is)ing ๐ŸŽป
  • ๐Ÿ“š (re)searching ๐Ÿ”
  • ๐ŸŽ™ responsive โŒจ๏ธ
  • ๐Ÿ•น adaptive ๐Ÿ’ธ
  • โŒ›๏ธ pausing ๐Œ
  • ๐Ÿ““ writing ๐Ÿ–Š
  • โœ๏ธ drawing upon ๐Ÿ–Œ
  • ๐Ÿ”ฎ concocting ๐Ÿ‰
  • ๐Ÿ“ฐ distilling โš—
  • โœˆ๏ธ climbing up ๐Ÿ”
  • โ› scrambling over ๐Ÿž
  • ๐Ÿ—ฟ bouldering ๐Ÿ‰
  • ๐ŸŒก riding hard ๐Ÿ‡
  • ๐Ÿ™ ruminating ๐ŸŽ“
  • ๐Ÿ‘Œ๐Ÿ‘†๐Ÿ‘Š๐Ÿ––โœ‹๐Ÿ‘
  • ๐Ÿ˜” embracing pain ๐Ÿ˜‘
  • ๐ŸŒฑ growing up ๐ŸŒณ
  • ๐Ÿ˜ fullish ๐Ÿ˜ฌ
  • ๐Ÿ˜ฒ open to that ๐Ÿ˜
  • ๐Ÿ’‚ meditating ๐ŸŒ
  • ๐ŸŒŠ running toward ๐Ÿƒ
  • ๐Ÿ—ฝ leaning in ๐Ÿ•ฏโš–
  • ๐ŸŒฐ๐Ÿฟ fastingโ€ฆ ๐Ÿ˜ถ
  • ๐Ÿ‚ stewing ๐Ÿฒ
  • ๐Ÿ›ฉ speeding along ๐Ÿ‡
  • motorcycling ๐Ÿ
  • cycling ๐Ÿšด
  • (re)mixing โ™ป๏ธ
  • ๐Ÿ”™๐Ÿ”› upcycling ๐Ÿ”๐Ÿ”œ
  • uplifting ๐Ÿ›ซ ๐Ÿ‹
  • ๐ŸŽˆ๐Ÿ–‡๐Ÿค” MacGyvering ๐Ÿš€
  • ๐Ÿšง slowing the hurry ๐ŸŒบ
  • hitting the brakes ๐Ÿ›ฌ๐Ÿšฆ
  • ๐ŸŒŽ leaving no trace ๐Ÿ‘ผ
  • ๐Ÿ’ช holding the door ๐Ÿ˜—
  • ๐Ÿ‘ lending a hand ๐Ÿ™Œ
  • ๐Ÿ‹ barely aware ๐Ÿฃ
  • ๐Ÿฆ€ delinting ๐Ÿ’
  • imbibing ๐Ÿธ๐Ÿป
  • ๐Ÿšš moving on ๐Ÿ›ซ
  • ๐Ÿ•ธ settling in ๐Ÿš
  • ๐Ÿก like a good neighbor ๐Ÿด
  • โ›„๏ธ warm enough ๐Ÿ”ฅ
  • ๐Ÿ˜› yearning ๐Ÿ‘น
  • nothing ๐ŸŒ‘
  • ๐ŸŒœ๐ŸŒš ๐ŸŒ ๐ŸŒ๐ŸŒ›
  • ๐Ÿค“ anyone ๐Ÿ˜ถ
  • ๐Ÿ‘ค no one ๐Ÿ˜Ž
  • ๐Ÿ™ˆ nowhere ๐Ÿ’จ
  • out there ๐Ÿ“ก ๐Ÿ‘พ
  • ๐Ÿฆ„ within ๐Ÿ’Ž
  • ๐Ÿ’ผ traveling ๐Ÿšž
  • in town ๐Ÿ™๐ŸŒ†๐ŸŒƒ
  • ๐Ÿ˜‘ happy here ๐Ÿ˜
  • ๐Ÿ‘ฃ on the road ๐Ÿ’บ
  • โŽ devsigning โŽ 

Hi, I'm Kerry

anyone-friendly designer
user experience developer
ace up your sleeve
jack of many suits

I'm all over the place


Q. Do you know what you get when you mix:

  • an atmospheric array of professional experience
  • a passionate, humanitarian, mission-driven work ethic
  • an indefatigable fervor for progress and growth
  • an incorrigible attention to detail
  • decades of overzealous thesaurusizing
  • and a giant gummy lizard?
A purple donkey who loves blueberries too much
What do you mean I'm turning purple?

A. That special someone who can build:

  • a world-class, cutting-edge software team
  • rapid-fire working prototypes of your outlandish concept
  • a fully custom development environment, build system, deployment strategy, and release cycle
  • your billion-dollar revolutionary idea to completion
  • this silly portalfolio from scratch
  • a heartwarming 83rd birthday card for dear old Grandma

Or anything in between. Get at me if you've ever found yourself wanting any of the above and have a budget to throw at it.


  • Built with ๐Ÿ’— and ๐Ÿฎ๐Ÿ’ฉ in 2016 by Kerry A. Snyder
  • Licensed under Creative Commons: by-line, non-commercial, share-alike

Past work

Over the years I've had the opportunities to work on small teams and big, at huge corporations and tiny startups, on solo passion projects and on multi-departmental, company-wide integrations.

As the need has arisen on various projects and teams, I've played a host of different roles, including but not limited to:

  • tech lead
  • developer recruiter
  • user experience designer
  • front-end developer
  • prototyper
  • business developer
  • growth hacker
  • patent drafter
  • culture crusader
  • scrum leader
  • interaction designer
  • interface designer
  • game designer
  • release engineer
  • devops engineer
  • product manager
  • project manager
  • content strategist
  • market researcher
  • user tester
  • quality assurer
  • copywriter
  • videographer
  • voiceoverer
  • gopher
LL Cool J's hats
I've worn more hats than LL Cool J. (source)

What follows is a sampling of my experiences and output on three such teams. Due to the nature of my work, there's a lot I can't publish or discuss. The vast majority of my work has been confidential (like prototypes for former employers), transitory (like dust falling from a whiteboard), or just downright obtuse (3GB Photoshop files with thousands of layers, or Mindnodes analyzing huge systems). I'll share what I can, please bear with me.

Oh, and if you'd just like the one-page overview to-go, I've got you covered.

I love SolarCity.

Nowhere else have I found such a density of positive energy. Those who joined us wholeheartedly agreed that we need not dig up and burn the Earth to power our progress. The pace was quick. Even after my full-bore headlong startup life at Togetherville I found SolarCity collectively kept the pedal even closer to the metal.

Initially I was engaged as a UX consultant by John Linney, then SolarCity's VP of Marketing and a noble mentor/colleague from my Togetherville days. John gave me gracious space to get up to speed on the clean energy sector, and pressed me and all of us to find a way to connect with the next segment of potential customers. SolarCity needed to go mainstream to save the planet.

SolarCity's homepage today
A recent SolarCity homepage

I boned up on the energy industry and the current ferment of climate change. I read exhaustively about the state of our planet and how we power our civilization. Before long I had convinced myself that the greatest challenge humanity will face in my lifetime will be an energy crisis. This crisis might be triggered by climate change, by an impending dearth of oil, or by the tyranny of those who hold our excavated energy sources as private property. The mission became clear.

In my first year at SolarCity I searched the company for emergent problems and great opportunities for growth. All the while SolarCity grew explosively, more than doubling in personnel and revenue each year, and was experiencing some of the growing pains you might expect: too many sticks, not enough glue.


Leadgen at a glance

Leadgen login
The login page for Leadgen, as seen on an iPhone 6
  • Empowered field agents to focus on their strengths
  • Solved a core organizational inefficiency
  • Fully responsive and adaptive
  • Built and deployed in weeks

In 2013 our field sales reps were still taking down their fresh leads on paper, leading to lots of mistaken, incomplete, and misleading information. The field agents would later sow their mealy leads into our CMS to be eagerly plucked by our inside sales acolytes. These brave souls struggled to make follow-up calls to ostensibly interested homeowners whose real names they didn't know, or whose phone numbers and email addresses didn't seem to be right.

To ease this organizational pain, I set about designing, developing, building, and deploying a web application we called Leadgen.

Leadgen's main interface, lead form and map side-by-side
Leadgen's main view, an interlinked form and map, side-by-side on wider screens

After interviewing several sales agents and analyzing the lead generation process from end-to-end, I whipped up a slick new user experience with invaluable input and feedback from my boss and a handful of esteemed colleagues, designers, developers, and engineers.

The Leadgen User Experience

By design users of Leadgen (our field agents, and by proxy their prospects) would have an experience something like this:

A SolarCity field agent intercepts a prospective customer (prospect) in a Home Depot, near a mall kiosk, or at their front doorstep, holding a smart tablet.

The agent asks the prospect if they have considered going solar. If the prospect has considered it but not taken action, they often have some objections or reasons why not. The agent dispels those swiftly and politely.

The prospect then either escapes or volunteers their home address, ZIP code first, which 5 little digits the agent taps into the tablet.

Leadgen territory check
The ZIP code autofills the city and state, and zooms the map to that region. This is the widescreen view.

The street address centers and zooms the map to the prospect's rooftop. Or if the address isn't accurate, Leadgen figures that out and corrects it.

Now the agent can make a preliminary determination as to whether the prospect has a good roof for a solar system. They can talk about roof materials, azimuth (which direction the main slopes of the roof are facing), shade, and obstructions.

Rooftop ready for analysis
We aimed to make address entry as quick and easy as possible so our field agents could focus on what they love: educating their neighbors about how easy and affordable going solar can be.

It's important to the solar installer that a prospect uses enough electricity to warrant installing a power plant on their roof. Hence the next question: "What's your average monthly electricity bill?"

Energy bill slider FTW
This little interface nugget first appeared here, and ended up on just about every customer-facing web form in the home solar sector.

If the prospect's electricity bill is high enough, and the prospect is excited about going solar, the agent collects some contact information and asks them when it would be convenient for a SolarCity rep to follow up with them.

This seemingly simple form has a lot under the hood. It'll pick up invalid phone numbers, geographically impossible addresses, impossible names, and even suggest the right email address if someone makes a typo. Once everything checks out, the agent submits the lead to Salesforce, and voila! A hot lead is born.

Typo in the email? Fake phone number? Not on my watch.
Typo in the email? Fake phone number? Not on my watch.
A completed, validated lead, ready for submission
A hot, complete, validated lead, ready for submission.

Interested in the Leadgen tech stack?

  • MongoDB as the data store
  • a Node.js web server
  • Express as the app framework and router
  • EJS templating
  • stylus for CSS preprocessing
  • jQuery for the interaction design and UI events
  • the Google Maps API for, well, maps
  • the Salesforce API to record the leads entered.

Since 2013, Leadgen has helped our field agents bring in thousands of quality leads more efficiently and reliably. And it only took a few hundred design and development hours, just a few weeks work for a single devsigner. I wish you could see the Github logs, but they're of course proprietary and hidden away at this point. That said, none of this would have been possible without John's vision and the invaluable input and incisive feedback from him and several key others at SolarCityโ€”you know who you are ๐Ÿ˜‰.

I loved building Leadgen, and learned a boatload about Node, jQuery, Google Maps, responsive design, CSS media queries, and HTML5 forms. All of these learnings eventually fed into the experience of which I'm most proud SolarCity Go!


SolarCity Go! in a nutshell

  • A first-of-its-kind DIY home energy product
  • Condensed a multi-week process into a ten-minute web experience
  • Fostered a comprehensive suite of APIs connecting customers with real-time, real data
  • Pioneered the adoption of git versioning, Slack team communication, a cutting-edge release strategy, and continuous deployment within the company
The initial view of Go! asks for your ZIP
It all started with a ZIP code.

Next we sought to seize a much bigger opportunity. Our market research indicated that many of our potential customers were the couch-quarterback DIY-type. They didn't like waiting around for their solar system design, or for the next phone call in the process. They would rather decide to go solar and then do whatever they could to make it happen. The frustrations of these prospects often stemmed from hold-ups in the sales and design process, and those hold-ups often arose out of missed communications or unclear correspondence. We identified a veritable quandary of bottlenecks in our customer onboarding process and set out to ***86*** them as adeptly as possible.

We asked homeowners to estimate their average monthly electricity bill.
We gave homeowners a ray-gun to zap their own electricity bills.

After three or four rapid prototypes, we had bolstered the confidence and grasped the attention of the C-level, and a new product was born, which we called SolarCity Go!

The concept was bold: enable interested homeowners to:

  1. craft their own preliminary solar system design,
  2. determine how much money they could save on electricity by switching to solar, and
  3. qualify themselves as promising customers with good credit,

all in ten minutes while comfortably lounging on their couch with an iPad. We gathered many of the best and brightest at SolarCity and put our noses to the grindstone.

Prospective customers could find their own roof and draw solar panels on it
Next we asked prospects to find their roof and draw solar panels on it.

We're extremely proud of what we were able to accomplish (in under a year, no less!):

  • We pioneered APIs that provided potential customers with real-time quotes based on their real data and ours.
  • We empowered energy-conscious homeowners to design their own solar system in a few mouse clicks or smartphone taps.
  • We made this experience available on any modern browser or mobile device.
  • We took a qualification/design/signup process that once took several people multiple weeks to complete, and condensed it into an interactive DIY web experience that a prospective customer could finish in minutes.
  • And we trailblazed a new design, development, communication, and deployment process that soon spread to many of the software teams around the company.
A DIY solar quote generated in minutes flat
Only minutes after they had arrived at Go! they had a quote in hand.

By no means am I trying to claim all the credit for this massive undertaking. The vision, the idea, started with John, and I ran with it, building prototypes until folks started to see its potential. Then one of SolarCity's most brilliant JavaScript engineers jumped into the mix, followed by someone I like to call "The O.G. of U.X.", and the smartest, most effective product manager I've ever had the pleasure of working with. Then a dozen or two more of the sharpest cats in the pride. Looking back, it felt like we were moving mountains, which is no big deal when you're solar-powered.

Tech stack breakdown!

  • Firebase data store
  • node.js web server
  • express back-end framework
  • AngularJS front-end framework
  • ReactiveX observable streams
  • Custom automated build system using: gulp, browser-sync, bower, nodemon, autoprefixer, etc.
  • Versioned with git
  • Hosted on heroku
  • Accessed endpoints from Google Maps, Force.com, Twilio, and our own newly minted internal API suite.

TL;DR on Togetherville

  • Built and sold a kids' social network to Disney within a year and a half
  • Blazed a trail for kids' safety and full participation in the World Wide Web
  • Lived on dreams of a better tomorrow, Red Bull, and peanut-butter-filled pretzel bites all the while
A summertime homepage for Togetherville
A summertime homepage for Togetherville

We pioneered a Facebook-esque social network where six-to-ten year-old kids could safely be themselves and play with their real-life friends on the Internet with parental supervision. We built a training ground for the next generation of digital citizens: a place to learn how to be cyber-friends rather than cyber-bullies. Disney bought us less than two years after our beta launch.

In those less than two years, I lived and breathed the Startup Life: 100-hour work-weeks, always on call, barely livable salary, weekly about-face pivots, agile scrums, pair programming, many-hat-wearing, all that and a bag of VC chips.

Flyers were a paper airplane flier to help kids connect with school-friends on Togetherville
A Flyer was a paper airplane containing a kid's secret friending code. Take them to school, throw them to your friends.
Tbills were the digital currency in Togetherville
Tbills were the digital currency on Togetherville. Kids could earn them by competing in Game Challenges or making and sharing digital art.
A panel introducing Trumpets
Trumpets gave kids a voice. We'd prompt them with a fun question, and kids could upvote their favorite responses.

Initially I was charged with heading up content strategy, so day-to-day I perused, screened, acquired, uploaded, and curated thousands of kid-appropriate videos and games to our platform. I soon transitioned into a UX design and product management role, learning the Adobe Creative Suite as well as ActionScript and Flash along the way. It was at Togetherville that I became a UX designer, and developed a taste for writing code.

A banner introducing the new Trumpet feature
A banner introducing our new Trumpet feature, which was like a Tweet, but screened by parents for inappropriate content.

But having just graduated from law school, I also was faced with addressing nascent legal issues as they arose with regards to information privacy, the Children's Online Privacy Protection Act, and intellectual property law more generally. I'll always look back fondly on those harrowing debates in our basement office in Palo Alto. I haven't since found a team of individuals so intelligent and so altruistic.

The straight poop on Disney Interactive

  • We rebuilt the identity platform for all of Disney's online properties.
  • We secured a patent (albeit for Disney) that encompassed much of what we had been driving toward at Togetherville.
  • I worked mainly on R&D: designing, prototyping, and developing Disney-wide interactive experiences.
  • In 2012, we designed and pitched a game concept eerily similar to Pokemon Go.

Digging back now into my work archives I find myself aching to share all the cool stuff we came up with while I was at Disney Interactive. However much of my work never made it to public eyes, so I venture to guess that the Mouse would prefer that I don't publish it, even now, years later.

So what can I tell you?

In 2012 I conceived of and pitched the Disney equivalent of Pokemon Go: Buzz Lightyear and Cinderella instead of Bulbasaur and Charmander. My 4GB professionally narrated pitch video made it all the way up to Bob Iger and the Board, but they decided not to pursue the concept. I wish we had gone all the way with that one, especially in light of Pokemon Go's breakout success.

In other news, I became a legitimate full-stack developer while I was at Disney. Designing experiences without being able to manifest them became untenable and downright frustrating. So I rolled up my sleeves and taught myself how to build them. Gone were the days of painting pictures of interfaces in thousands of Photoshop layers. Gone were the days of pitching interactive experiences in Powerpoints or Keynotes.

And it's made all the difference. Pursuing development as fervently as I have pursued UX design has yielded incalculable benefits to my efficiency and conveyance of interaction designs and flows. An architect who presents an accurate model stands a much greater chance of getting a building up.


  • Built with ๐Ÿ’— and ๐Ÿฎ๐Ÿ’ฉ in 2016 by Kerry A. Snyder
  • Licensed under Creative Commons: by-line, non-commercial, share-alike

What's next

AETHER

Aether houses my vision for the future, or at least the brushstrokes I would like to paint on the brilliant visions of Kurzweil, Musk, Diamandis, Brand, and maybe even Zuckerberg or Bezos.

Cuppa

How do you find the perfect cup of coffee?

I make mine myself, but it's taken me years of practice and research. A simple coffee logging app could have directed me toward the perfect cup a lot faster.

UXioms

UX (user experience) design is such a broad, nascent, and all-encompassing field. The term used differently by nearly everyone, even those that claim to be UX professionals, and consequently these UXers are difficult to value.

UXioms seeks to define the core tenets, the axioms, of UX, in order to foster a more universal understanding of the field. With the basics worked out, we can move toward unifying and aligning our efforts. UX will need a stronger foundation if it is to lead a business revolution where the customer is valued rather than deceived.

A while back I put together a 3D presentation to introduce my perspective on the field of UX. It's still up and you're welcome to check it out, though it may be a bit outdated at this point.


  • Built with ๐Ÿ’— and ๐Ÿฎ๐Ÿ’ฉ in 2016 by Kerry A. Snyder
  • Licensed under Creative Commons: by-line, non-commercial, share-alike

Meta

N.B., this is a work in progress and not yet complete. But I couldn't wait to start sharing it and gathering feedback, so please bear with me. If you find bugs, have suggestions, or would like to see improvements or additional content let me know.

This silly place is the result of a labor of love, but really not all that much work. It's a safe place I've made to test out some responsive navigation layouts and transitions, and play with some randomized animations. Nothing too intense, mostly design explorations. After my last year's deep mechanical dives into build systems, deployment strategy, and release cycles, it was time to return to aesthetics.

If you're interested in the design effort that went into this little corner of the web, visit here on different devices. I've done what I can to offer a pleasant, navigable experience from any terminal: hand-held, desk-topped, or wall-mounted. Try it from your phone, save it to your homescreen, hit it from your smart TV.

I'm aiming for a universally slick, responsive, adaptive experience, so if you encounter any rough edges, don't hesitate to tell me.

Design

Function before form. Let's explore the aesthetics a bit.

  • Layout
  • Typography
  • Color
  • Imagery

Tech Stack

I made some early choices that determined much of the tech stack. I chose Roots as my framework, and chose not to use jQuery or any event libraries.

Everything you experience here I made from scratch in my spare time this summer, save for the libraries listed in my Oscar speech. The photographs in the background are ones I've recently taken on the road (hit reload to see a different one). I've shied away from using any client-side libraries like jQuery or Bootstrap which has forced me to strengthen my grasp on vanilla Javascript and CoffeeScript. The animations and transitions you see were hand-crafted in CSS.

Oscar speech!

I'd like to thank:

  • Jeff and the Carrot Creative team for Roots, without which this site would have been a great deal more work
  • Jxnblk for Geomicons Open, some kickin' icons you get to clickin'
  • Iconic for Open Iconic, more such kickin' icons
  • Elon for keeping us looking up and to the redshift
  • Gary for making a ship holy
  • Claude and his dirty birds for flocking together
  • My dear family for always having my back
  • My partner for providing everything else I could want

0. The Problem at Hand

You may already be aware that for the past eight months I've been gallivanting around swashbuckling and writing. I'm going to keep doing that, but I'm also going to start hiring myself out as a consultant, advisor, and/or independent contractor. Which means, I think, that I'll have to finally answer the $20,000 question. It's one that has come up a lot as I travelโ€”in my own mind and in conversation with the hundreds of awesome people I've had the pleasure of meeting.

"Soโ€ฆ what do you do?"

God Science knows I've tried to answer this hundreds of times in my recent travels. Here is a representative sample of what has slipped out:

"I make web sites."

"I write stories in code."

"I do UX."

"I'm a developer."

"I design experiences."

"I'm a writer, sometimes for people, sometimes for computers, usually both."

To those who have asked: I'm sorry, I wasn't trying to be coy or confusing. The truth is I don't have a concise answer.

I mean, what would you call a chimeric monstrosity who runs the gamut from initial user/market research to shipping and deploying a production-grade web application and everything in between? Someone who is equal parts developer, designer, and dev-ops engineer?

There oughta be a wordโ€ฆ

Panda Panda Panda Panda Panda
Desiigner or Devsigner?

Enter the Devsigner

Imagine my delight in the Spring of 2015 when I shared my supposed coinage with an esteemed colleague only to discover that Dustin and I had each arrived at the same title for these multidisciplinary polymaths ninjas rockstars cyborgs unicorns gems. Maybe it's a thing. Maybe it does make sense!

The term 'devsigner' first sprang to my mind when we were building a front-end team at SolarCity. I wrote a job description for a suitable web designer, and then one for a suitable web developer. I circulated these two JDs to my team for feedback. It became apparent that we were looking for individuals with both skill sets. We sounded a call for this new breed of developer/designer, for proper devsigners.

I dropped this shiny coin into Google's slot to find that a few others had arrived at this portmanteau. I wasn't surprised or disappointed to find that we hadn't been first call a developer/designer a devsigner. In fact, the more I "invent" things, or "coin" words, the more I'm thrilled to discover brilliant people that have beaten me to the punch and publication.

Bryan Clark has been leaving us notes on devsign.co since the summer of 2014. So far he has focused on devsign within the iOS and tvOS realm. And his approach to prototyping certainly rings a bell.

I also turned up an adroit pitch for the devsigner by Noah Addy in late 2014. He touches upon two of the definitive merits of a devsigner: (1) making concepts feel realer sooner with prototypes, and (2) acting as a liaison among designers, developers, and stakeholders.

Then in June of 2015 a Devsigner Conference was held in Portland. This year it's in August and I'll be there barring some force majeure. I'm excited to dive headlong into this nascent field with some like minds.

Some honorable/international mentions:

Looking now at the Google Trends, I see a surprising dearth of steam-building since the term was first ostensibly queried in 2005. Perhaps I can help. Perhaps the DevsignerCon cats, Bryan at Devsign.co, Noah, Dustin and I can band together to foster a broader recognition of the immense value that lies in rapid prototyping and in attracting cross-disciplinary team members.


My name is Kerry, and I am a Devsigner.

It took me far too long to realize this, to admit this. But now that I have, it's time to get busy devsigning. I've started on a new site, aesh.me, a portal into the devsign studio of my mind. This is the first entry in a chronicle of that project.

Stay tuned for the nitty-gritty as I start applying my very own rulesโ€”my UXioms as I like to call themโ€”to the devsign process.

Next, we'll set some goals or objectives to narrow down the solution set.

P.S., Initially I wanted to put this new smoosh out there as "devsigneer" to call out the dev-ops engineer facet more explicitly. But I can't help but cringe when I mouth those syllables. I can't even bring myself to say it aloud. Disney's "imagineers" have already pushed that envelope to the edge of the ledge. So, devsigner it is.

1. The Objective

This project is many things at once. It's an opportunity to reevaluate the experience design and development process I've been employing for yearsโ€”one I first published on UXioms and often refer back to. It's a stab at personal convergence after a period of willful diversion. And it's a fun way to dust off the mental machinery and play with some shiny new web dev toys.

Before we dive in, let's briefly review where we started. In the zeroth entry, I stated the problem, the $20,000 question I struggle to answer: "What do you do?" I've figured out the answer ("I'm a devsigner!") and now I'm faced with conveying that answer to those who would ask.

Now I must start to formulate a solution, which starts with a goal or an objective.

Second things first

What's my objective?

I'm feeling a bit scattered these days. Over the years I've started and sunset four different blogs on four different platforms. I've got accounts and presences on hundreds of sites, apps, and platforms. I've started linking them up a bit, tying them together with IF (formerly IFTTT) and various other integrations. My Instagrams auto-post to Twitter, Facebook, and Flickr, and save to my Dropbox, archive in my iCloud storage and Google Drive.

But I've still got no central hub, no permanent address on the web, no nexus. That's what this project is all about: putting forth a collected, unified presence.

Presence: the prime directive

So I'm framing up a new front door, and building a modest foyer behind it. Anyone with a browser and an uplink will be able to find my cyber-abode in seven little keystrokes. I've got a strict open-door policy, so you probably won't notice the door so much as peep into the foyer, which is magical and so also difficult to notice.

Once you intuit that you're inside the foyer, you may choose to travel one of four directions with your keyboard arrows, your mouse, or one of your greasy little swiper-tappers: up, down, left, or right.

  • If you chose to go up, you'll find yourself in THIS: a meta-space which endeavors to explain the very place you're occupying
  • Traveling down will lead you to ME: a panoply of ways to get hold of me or track my every word, selfie, and move.
  • Swerving to the left, you'll enter the PAST, where I wrote code, built apps, designed stuff, and had a blast.
  • Kick it right and you'll step into the FUTURE, where work is play, hearts are light, and everyone likes my crazy ideas.

What I'm driving at: The Objective

So my objective is to solve The Problem: I struggle to sum up what I do, and I lack a central presence on the web that could do that for me. The solution I've concocted so far takes what I do and employs it toward what I want to conveyโ€”which is what I do. This seems direct and efficient.

Sliced another way, I aim to design and develop a web experience that exemplifies my abilities to do just that. The content for this experience is the biggest mystery in my mind so far, but luckily I've got five other steps to walk through before I have to figure out the content. What sort of book do you write to show readers how well you can write a book? I suppose it depends most heavily for whom you're writing. That's why we do our research and personas next!

Next, we'll do some market research and build personas.

2. The Audience

Now that we're a few entries into this chronicle, I feel obliged to do a brief recap, as any responsibly made series would do before dropping you into the new episode.

0. The Problem

When people ask what I do, I don't have a succinct, clear answer.

1. The Objective

I aim to synthesize my past work, future ambitions, and current skill set into a web experience for anyone who is interested in what I do. Show what I do by doing what I do about what I do. Such meta, so layers!

Which brings us up to here and now.

Let's poll the audience.

I've been through this process many times on various projects. So much so that I summed up my process in this UXioms presentation. Why reinvent a wheel I've already reinvented? Instead I'll start with a few pointers from UXioms.

  1. Meet the folks with the problem you're solving.

    I experience the problem, as do all those who have asked what I do and were left more confused than before I tried to answer them. I've met hundreds of them; it's what drove me to prioritize this project at this time.

  2. Interview and survey them; internalize the problem.

    I can think back to the difficulties I've had explaining my occupation to old friends, family, Lyft drivers, club patrons, AirBnb hosts, waiters and bartenders, festival goers, and those amazing new friends I've made in my recent travels. This problem is fully internalized.

  3. Identify the archetypes that define your constituency.

    I could play act the answer to this one.

    "Soโ€ฆ what do you do?" "Well, that depends. Who wants to know?" "Hmm. Well as I said I'm Phil, I'm an independent filmmaker, and I make commercials to pay the bills." "Oh right, I'd love to see one of your films. Or commercials even." "Right on. I'd love to see some of what you do to. Which is what?"

  4. Construct personas that exemplify the archetypes.

    Phil's a good start. In fact, right off the top of my head we've got a beautiful cast of savory characters:

    • Phil, the fellow independent creative who works in a different medium
    • Tony, my older cousin who has stayed out of the whole Internet thing, but excels at sales, networking, and UX in the meatspace.
    • Berry, a very zen lady who runs her own software startup and could use a cost-effective ronin who does what I do
    • Helen, who really wants to earn those placement commissions. She's a talker, and she knows all kinds of people who need help and don't know who to ask
    • Buck, the aging desk jockey/tech manager who doesn't code but who attends festivals like Further Future with business cards in hand

Now, let's build some dossiers for these crazy cats!

Who in the world is Carmen Sandiego?

Usually I give my personas playful names that evoke their qualities or circumstances. Back at SolarCity I developed a couple of personas that came up constantly and always brought a smile to my face. Wanda Panels was a potential customer who was uninformed but enthusiastic. And Sonny Roรผf was a potential customer who hadn't thought to go solar but who was otherwise an ideal candidate.

So for this project I'll do the same, basing them on dozens of real people I've encountered, and filling in my best ethnographic guesses for each one.

(Author's note: I've never been the dungeon master for a D&D game, but as I wrote these dossiers out I could sense the grandma's basement aura of a twenty-sided die nearby. In this same vein, it felt more natural to write them to 'you' rather than to myself. You'll see what I mean.)


The Filmmaker

The Filmmaker knows this racket better than you do. He's been through the wringer more times than he'd like to admit, and he's a little worse for wear but wiser for weather. Down deep you really wish you were making movies instead of websites. You stand to learn a lot from people like Phil.

persona The Filmmaker
name Phil Harmonique
age a silver 35
location Echo Park
devices Galaxy Note, Mac Pro
OS Android, Mac OS Yosemite
browsers Chrome for Android, Safari
need street cred, panache, verve
savvy Keanu + Fassbender + Cumberbatch
style his mustache rocks a mullet
comms Instagram, Snapchat, SMS

Phil knows ten people that do better work than you ever will. If you play your cards right, you might accidentally bump into some of them when you and Phil are catching up over a grass-fed kombucha on Abbot Kinney. Authenticity is paramount with Phil: pull no punches, mince no words, and if you left your fly down, leave it that way.


The Old Boy

The Old Boy knows people. He can introduce you to a whole slew of folks that you wouldn't encounter in the usual techie web circles, folks that could use your services but might not otherwise know how to find them or what to call them. Plus Tony's not afraid to call bullshit on anything you do that just so happens to be one of the oldest tricks in the book.

persona The Old Boy
name Tony Bologna
age 40/50-something
location suburbia
devices Android, PC desktop
OS Android OS, Windows 7/8
browsers Android, IE10/11
need real world tie-ins, pictures
savvy fair to middling
style bold strokes, unambiguous
comms meat, phone, email

Tony won't have any use for your services directly, but the more Old Boys who see and understand your portal-folio the better. You'll want to extend a usability hand to the Old Boys. Don't expect Tony and friends to know their way around the latest interfaces. Clear labeling, accessible controls, and responsive design are especially important.


The Entrepreneur

The Entrepreneur is in way over her head and likes it that way. She is onto all the new-new, so you don't have to hold her hand interface-wise. But the Entrepreneur has a sharp eye for those usability bugs you've been shooing away but haven't quite squashed. Berry is a real treat.

persona The Entrepreneur
name Berry Dwithwerk
age 22 going on 27
location tech epicenter
devices iPhone 6, MacBook Pro
OS iOS 9, Mac OS El Cap
browsers Chrome for iOS and Mac
need Github repos, success story
savvy high to expert
style direct, nuanced, cutting edge
comms Twitter, email, meat

Berry is very busy, and yet an expert at GTD (getting shit done), so as long as you offer clear value and don't waste her time, Bob's your uncle, errโ€ฆ Berry's your gal. First impressions are very important to Berry, so be cognizant of initial load time, clear navigation, and graceful error handling.


The Headhunter

The Headhunter knows some of those that do the hiring for stable and growing companies. She gets requests for personnel that fit certain job titles or skill sets. She's aware of a lot of the buzzwords that those in the HR scene use, but less aware of the jargon used by those doing the jobs Helen gets paid to fill.

persona The Headhunter
name Helen Huntress
age forever 32
location regional territory
devices Galaxy S6, PC laptop
OS Android, Windows 8
browsers Chrome for Android, IE10/11
need resume, pay grade, portfolio
savvy medium-high
style direct, high contrast, familiar
comms email, phone, LinkedIn

Helen would love to connect you with her clients, but doesn't have a lot of time to waste trying to figure out what exactly it is that you do. You'll want to give Helen a personal sound bite, and an easy way to connect with you and later reach out as opportunities fall on her desk.


The Middle(-aged) Man(-ager)

The Middle Man knows his place. He tightly grasps the keys to a small corporate fiefdom where he must oversee a horde of rambunctious serfs. He doesn't know how to write code, but his serfs do. They don't know how to dress or feed themselves or find health insurance, but Buck does. He routinely leaps through (and sometimes holds up) bureaucratic hoops.

persona The Middle Man
name Buck Passer
age always turning 40
location Office Space
devices iPhone, PC laptop
OS iOS, Windows 7
browsers Safari, Firefox
need a safe, established bet
savvy enthusiast
style P.C., buttoned up, clean
comms email, resume, phone

Buck would love to work with you if you have your shit together. He doesn't want to add any more risks or variables to his already precariously balanced juggling act of a career. That said, he'll be your strongest ally and meal-ticket-by-proxy if you focus on making him look good for engaging with you. Clear communication, timely replies and updates, and consistent, polished work product will go a long way with the Middle Man. Also Buck and Helen Huntress go way back.


Yours Truly

When it comes to your personal portalfolio, you are a key persona as well. You'll have to enjoy sharing it with anyone and everyone to get any value out of it. You ought to love looking at it, love using it, potentially more than anyone else. Because you are me and I are we, and other riddles of spiritual oneness to that effect.

persona The Me
name Kerry Snyder
age eternally 8
location the cyberverse
devices iPhone, MacBook
OS iOS, El Capitan
browsers all of the above
need savvy clients
savvy UXpert
style eurotrash glamstar
comms any and all

I'm super excited to share this silly site with all of you dungeon slayers. I love adding little easter eggs, tweaking the animation timing, massaging the transparencies and color palette, weaving strands of whimsy into the labels and copy, and stripping away every last extraneous bit.


Ubuntu: I am, because of you.

This portalfolio isn't primarily for me; it's for all of you.

Phil! Put me in your next movie. I'll be the back-end of a purple horse with leprosy if you want, no speaking parts necessary. Just get me on camera and in those credits. Also I'll make the promo site for it and manage the social media campaign.

Tony! Your golfing buddy who needs an e-commerce site for his beer belly girdle company needs to quit chewing the fat about it and pony up my two-week stipend. He's gonna make millions!

Berry! I know you've got it all under control, but I've been there too. You can always use more Zen and poise in the room, someone who's weathered many a storm, but now feels them coming and steers around them.

Helen! Please stop throwing typical jobs my way. They sound great and all, but I don't commute anymore, and I mic-dropped that 9-to-5 crap way back. But please do introduce me to anyone that wants results instead of a warm butt to fill an ergonomic swivel chair. Take my rรฉsumรฉ, share and share alike.

Buck! Together we're gonna nail your numbers this quarter. Those upstarts bullshitting you about scrum velocity, technical debt, and major blockers? Leave 'em to me.

And YOUโ€”whoever the firetruck you areโ€”did I miss you? Do you find yourself underrepresented by these personas?

Find me any way you'd like via my contact page. Tell me about yourself. How can I better serve you?

Next, we'll search through the available tech for what will best achieve our objectives for our audience.

4. Tech Audit

As you may know I'm building a personal/professional portal. The goal is to enable anyone with a web browser to tap seven characters ('aesh.me') and find anything and everything they might want to know about little-old-me. My presence on the web needs a nexus or a nucleus, or at least a new foyer.

A foyer is not terribly complex: it's a small room just inside the front door that itself contains a selection of doors, each of which leads to a more interesting, spacious, important room of the manor.

Usually I start with a hand-rolled Node-Express webserver built on a highly modularized Gulp system involving BrowserSync, Browserify, Bower, and a host of other automated productivity boosters. But this bit of home remodeling is long overdue, so I'm going guerilla, staying tactical. I'm prioritizing quick results and fast iteration over deep functionality or robust architecture. This time I'll keep the architecture simple, and focus on the experience and the content.

So I quickly outlined some tech requirements.

I'm building an app that:

  • auto-reloads as I develop
  • minimal back-end or webserver work
  • easy to deploy to a foolproof host like Heroku
  • a stylesheet preprocessor that handles vendor prefixes and supports variables, functions and mixins (Sass, LESS, Stylus, etc.)
  • templating engine that handles markdown, nested layouts, and dynamic content
  • nimble, bloat-free, and streamlined for static site development
  • enables users to navigate the space with their keyboard

Then I surveyed the landscape. These days there are a mind-numbing and ever-growing number of configurations and generators for a JavaScript-based web app: Brunch, Yeoman, Ember, Meteor, Angular, React/Flux, Metalsmith, etc. I combed through all of these, weighed my options, and settled neatly on an old familiar friend.

Start at the Roots

Thanks to the continued efforts of @jescalan and the team at Carrot, Roots is slicker and more robust than it was some years back when I first stumbled upon it. Back then I remember trying to npm install -g roots: I'd watch as thousands of lines of dependencies successfully installed only to eventually come grinding to a mysterious halt. After a harrowing bit of StackOverflow mining, I figured out what was happening: my Bash was running out of allotted processes. I had to up the ulimit. Once I got it running, I tooled around quite a bit, built a few prototypes, and eventually decided it was wrongly opinionated for the project I was spearheading.

At the time I was fascinated with the resurgence of the static web app. To be frank, I didn't know static apps had ever lost their prominence. I suppose I didn't get into web development until after they had declined in popularity, giving rise to generations of server-heavy PHP sites, Java and then Ruby-on-Rails web applications and platforms. Wordpress and Wikipedia had taken over the web by the time I knew what it was made of: lots of page loads, and server-side templates, and labyrinths of routes, with a sprinkle of DHTML and AJAX here and there.

It all made sense to me though. Bandwidth had skyrocketed since the Prodigy and Altavista days, and server costs had plummeted since the AOL and MySpace days. We soon had collected way more data than we knew what to do with, and had no intention of slowing down. These pivotal factors changed so rapidly that it left most of our heads spinning. The way I see it, back in our hardware and network infrastructure left our software in the dust, and we've been playing catch-up ever since.

If you look at how fast the global internet population has been growing since the advent of the Internet, an interesting trend emerges. While it's true that the absolute number of Internet citizens has been increasing ever since it came online, the rate of adoption has been decelerating rather dramatically. Here's a graph illustrating the steadily decreasing percentage growth month over month. It follows a roughly asymptotic curve, the sign of a saturating market or a dominating contagion.

Internet Growth is shrinking
The Internet isn't growing as fast as it used to.
A graph of y = 10 / x
y = (10 / x) + 1

Here's a graph where we can imagine monthly percentage growth and time passed are inversely proportional by the factor of 10. That is, it's a graph of y = (10 / x) + 1. This factor being accurate greatly depends on the scales of the units in play, and my econometrics are rusty enough to leave that alone for fear of mental tetanus. But you get the picture, right?

What I'm getting at is a hypothesis: I expect the rate of change of the complexity of web software to slow in the coming years. The Internet ballooned up, now everyone is online and trying to figure out what to do about it.

This time around I'm better off starting with a battle-tested tech stack, built system, and development environment. There is a time to question all the premises, to inspect the foundation. I'm sure I'll go back and start from scratch again soon, but not this time. This time I stand on the shoulders of giants.

How many templating engines does one guy need?

It seems like every new app I build uses a different templating engine. Thinking back through the last few years of prototypes, I can recall using <% ejs %>, {{ mustache }}, {{handlebars}}, %haml, <ng-templates>, and now Pug (formerly Jade). I haven't mastered any of these approaches to templating except Angular's. And since I don't want to use Angular in every little app I build, especially a lightweight static site like aesh.me, I think it's time to pick a templating engine and commit.

These days I'm trying to write as little code as possible. Instead I write copious inline comments and verbose documentation, which helps me distill the intended function or feature into its simplest logical form before I write a character of code. Consistent with this code tersity, I've doubled down on meta-languages that prioritize readability and minimize symbol-driven syntax. My favorites, and those endemic to a Roots app, are Markdown, CoffeeScript, Stylus, and now Pug.

So far I've had little trouble jumping back into Stylus or CoffeeScript. But I'm still a bit cloudy when it comes to Pug. Perhaps if I write about my struggle here, I'll clarify my confusion into a delightful ghee. Mmm, ghee. Must be time for lunch. The food metaphors are creeping in.

As I explore the possibilities of Pug/Jade and think about the navigation experience I'd like to offer to my visitors, it becomes clear that these are tightly intertwined. The most promising library I've uncovered is an officially maintained Roots extension: roots-dynamic-content. This ought to enable me to manage my content in the templates using some clever directory structuring and front matter properties.

roots-dynamic-content

So I've struggled for the last week to structure my site's content so that I don't need page-loads to change the content visible to the user. And then it struck me: "Is this the true definition of a static site? One that shows you a static page at a time?"

Prior to this week's toil, I had thought that static sites loaded all at once, and then required no additional HTTP requests as the user navigates around. I suppose I'm trying to deliver a dynamic experience within a static site, so I've had to write some rudimentary show/hide functions for the main panes and their sub-navs. There are plenty of libraries out there that supply show/hide functionality, but they're all bigger and less directed than the tiny library I put together.

5. Specs & Prototype

Specs often take the form of a requirements document, or an outlines of features. A well-formed requirements document can be broken into features and tasks and fed into a task management tool like PivotalTracker, Asana, or (God forbid) Jira. In practice though, I've rarely seen a requirements document get read, or digested, or used at all.

Rather their main functions seem to be to help the product manager solidify the concept by having to describe every sordid detail, and to show the management that progress is being made as the concept is being formed and explored.

Barely anyone reads specs. But they are useful to their author. Getting concise about the software solution you envision will reveal flaws in the architecture and expose missing and extraneous details in your concept.

Then when the specs are fleshed out, it's time to start designing the information architecture and the interface. Or is it? Why bother drawing pictures of an interface when you can build the interface and try it out? A working prototype accelerates progress like nothing else. Said another way, if you want build something, just start building it.

I wrote these specs months ago when I started this project, and looking back at them now, I see that this portal-folio has developed and changed quite a bit as I've built it. You can get an idea of where I thought it would go below.

the original specs for aesh.me

a personal portal and professional portfolio

  • this - meta-section describing the experience as designed
  • play - links to writings, latest mediums, side projects
  • work - portfolio of sites, apps, sketches, documents, work product
  • me - contact info, social presences, etc.

THIS: ABOUT THIS SITE

  • A Devsigner Follows His Own Rules series
    1. resources & objectives
      • all the time I want
      • Macbook
      • open source
      • family, friends, girlfriend, mentors, colleagues for feedback
      • put myself out there
      • drum up clients
      • connect with colleagues
      • refresh my chops
      • exemplify my skillset
    2. research & personas
      • potential client
      • ux professional - review portfolios
      • experience designer - network
      • dev/engineers - befriend
      • non-tech manager, board member or VC - ask questions
      • friends/family
    3. tech & architecture
      • static web app
      • simple to run and dev
      • stripped down chassis
      • easy to deploy on Heroku
      • others considered: Yeoman-generated MEAN app or React/Flux app, Gulp-built app based on Valence (SCTY)
      • docs in markdown
      • minimal syntax: Jade, Stylus, Coffeescript
      • hosting and deployment
    4. specs & prototype
      • this outline embodies the specs doc
    5. specs are a place for:
      • exposition and exploration
      • reference during the initial prototype
      • outlining functions and features to be ported into a task manager
        • first prototype is the unstyled, contentless skeleton stood up locally
        • second prototype has functionality
        • third prototype has style
        • fourth is deployable
        • fifth has content
    6. aesthetics & style
      • analyze the competitive landscape
      • moodboard or Pinterest
      • choose 5 design adjectives
      • color palette
      • typeface(s)
      • responsive, relative, adaptive, stretchy, universal
    7. content & copy
      • first draft
      • feedback
      • refine voice
      • define voice
      • link out
    8. development & iteration
      • optimize size and speed
      • host, deploy, test
      • announce
      • gather feedback and continue
  • omotenashi - be hospitable
    • welcome your guests
      • load order is important
        • background
        • greeting
        • headline
        • links
      • ask them what they seek
        • concierge rather than coach notes
    • anticipate their needs
      • architecture mapped to use cases; give 'em what they came for
      • fast loading; don't keep them waiting
      • responsive interactions; johnny-on-the-spot
    • make it seem effortless
      • transitions between states (no jumps or snaps)
      • swift, graceful, eased animations
      • universal nav
      • no sharp corners or dead ends
  • set the stage
    • hero and headlines introduce sections
    • nav teaches the spatial layout
    • rotate underlying photos
  • use the space
    • main sections slide in from edges
    • fill viewport whenever possible
    • agnostic/responsive to mobile, tablet, big screen
    • negative space to frame focal points
  • speak clearly
    • big, bold typography
    • terse copy
    • links lead to what they say
    • leave room to think
  • show don't tell
    • use images where they say more than text
    • use icons
    • have/use a logo
  • don't make them think
    • use text with unfamiliar icons
    • annotate screen shots instead of captioning them
    • name things carefully and obviously

WORK: MY PAST WORK

My work as an experience designer and developer takes on many forms, the most developed of which is a production grade web application. The less developed forms are all of the conceptual, processional, programmatic, systematic, documental, sketchy types of work product you might expect from someone in UI/UX or product management: user flows, workflows, tech audits, API designs, interface mockups, product roadmaps, feature/release plans, and so on.

There's a place for humility and there's a place on the internet where I talk about the things I'm proud of having done. This is the latter :) After all, I'm just a speck in the cosmos, just a few bits of star dust with very little significance in the grand scheme.

  • I built a lead entry app from scratch to replace the paper forms our field sales agents were still using. It's now used companywide and has been ported several times.
  • I mapped out development, hosting, and deployment processes for our larger new projects, standardizing a git flow and a weekly release cycle that kept us moving and stable. We integrated this with a Jira issue tracking, Jenkins automation, and some git hooks which automatically pulled reviewed and approved feature sets to our hierarchy of quality-assured Heroku instances. It was slick, shipping it had never been so easy.
  • I got us going on Slack when it had just launched. And my custom hubot (raybot) was able to join us. Growing our internal Slack community from one to hundreds took mere months. And raybot did its job delighting our Slackers with useful automation and measured doses of whimsy and serendipity.
  • I spun up self-hosted Discourse instances to foster broader discussions among customers, designers, builders and stakeholders. Discourse is a very promising community platform; I hope to explore it further.
  • I put together a simple node app where we could securely publish our notes and product documents. Team members previously relied on email attachments which kept getting lost in jumbled threads. Then along came Confluence (blech!) and Slack (hurray!).
  • I built four successive, bodyless prototypes of a new sign up flow for SolarCity customers. The last one convinced our founders to pursue online sales, which then became the prime directive for the marketing, sales, and software teams. The result was Go! which you can peruse yourself, or check out my extensive walkthrough of its fruition.
  • PINS presentation
  • Vinylmation game concept
  • Togetherville flash games
  • Togetherville music composition for intro video
  • Togetherville videos (embarrassing but worth it)

Work Views

  • thumbnail view with blurbs (scrollable)
  • summary view
  • fullscreen view

Work sections

sorted by anything I damn well please:

  • project
  • work product
  • cool picture
  • role played

PLAY: CONCEPTS AND WRITINGS

writings

  • latest Medium stories and opinion pieces
  • The future of AI - personality design for sandbrains
  • The future of IoT - connecting people in meatspace with cyberdata
  • Genes, memes, themes, and teams - the next evolution of evolution
  • DLing minds would yield eternal family lines
  • An AI will be the sexiest woman alive in 2022

My Personal Canon

things I wish everyone would read, see, or listen to

  • "The Myth of Sisyphus" by Albert Camus
  • [Yoshimi Battles the Pink Robots] by the Flaming Lips
  • [Stranger in a Strange Land] by Robert Heinlein
  • [Let the Right One In]
  • [Snow Crash] by Neal Stephenson
  • [Snowpiercer]
  • [Speaker for the Dead] by Orson Scott Card
  • [On the Road] by Jack Kerouac
  • [The Information] & [Genius] by James Glieck
  • [Zen and the Art of Motorcycle Maintenance] by Robert Pirsig
  • [All the Pretty Horses] by Cormac McCarthy
  • [The Selfish Gene] by Richard Dawkins
  • [Slaughterhouse Five] by Kurt Vonnegut

concepts

  • Will (WILL) - a fun, cathartic, legally binding will generation wizard
  • Souvenir (SVNR) - slick contact entry/recall app with Gotcha moment
  • aether (AETHR), formerly TURNT, formerly LEDMob
  • gumshoe (GMSHU) - sticky little wireless camera
  • Cuppa - coffee taste honing assistant, one cup at a time
  • Didit - log your have-dones, not your to-dos, earn points, figure out what you care about
  • tidbit (TDBT) - craft an audiovisual snippet, demand response from friends
  • Post - old post offices become Internet training depots
  • Youlogy - archive a life, distill it into a beautiful memory when it ends
  • UXioms - the axioms of UX
  • Magic box - easiest search ever
  • PRIM - person-reaction-interest matrix
  • Human as API - GET POST PUT UPDATE DELETE
  • Feelswall - an interactive moodboard on your wall
  • Snowpiercer - development/engineering workflow and roles
  • Wayin - a yes-or-no icebreaker game for the harsh winters
  • Button of Destiny - an A/B testing experiment
  • FlashMob - cutthroat Survivor-style interest-based chatrooms
  • buseyvsnolte.com - redefine the greatest leading men of our time
  • Church: The Game - become the Pope, but watch those sins
  • Miss Cleo's Drinking Game
  • SkyCavity - a place to bitch about Bluetooth
  • Cumpernitits and Galile-ho Galile-he - randy ancient astronomers
  • FOMOKUN - this monster's always missing out on the fun stuff
  • LED Goggles and Arduino and C++ - the Feynman Algo

ME: ABOUT ME

short bio, contact info, etc.

ID card

  • name
  • avatar
  • taglines

Contact info

  • a grid of links to my presence around the internet
  • Categories
    • social media
    • blogging and writing
    • profiles on various platforms

Bio

  • professional description
  • origin story?
  • career narrative

7. Content

What belongs in a UX portfolio?

This is a question I've been trying to answer for years. No matter how I slice it, this question ends up begging another: "What the H-E-double-hockey-sticks is UX design?" Call me skittish, mail me about it if you want, but I'm gonna save that white whale for another day.

Moby Dick flips us the tail
Some white whales should be left alone. (source: In the Heart of the Sea)

My "UX portfolio" is better likened to a Yeti or a S'quatch: long-fabled, highly sought-after, and rarely (if ever) spotted. Even the most hi-res captures of this mythical manifestation leave much to the imagination. I might as well be concocting a vat of snake oilโ€”ahem, I mean, cure-all tonic. I might as well start touting UX as the panacea for any and all of your business woes. And I might, but I'd call it experience design, and I'll save that for another day too.

UXers! If you're out there, send me some links to your favorite UX portfolios! I need guidance and inspiration. And we in the field need to foster some solidarity, don't we. They don't know our worth. Think of all the unusable software they're making! Think of the users!

Maybe we're too nice. Maybe we're too hard to pin down or put in a box. Maybe we're a bunch of shallow-skilled, talentless hacks that know how to talk the talk, but balk at the walk. Let's make sure they all know it's not that last bit.

Walking the walk

I suppose I could show you the thousands of hand-drawn interfaces in my notebooks. Some are paper prototypes drawn with indulgent care, fine-tipped markers, and a straight edge. interface sketch Or we could run through a riveting slideshow I slapped together: over 800 fluorescence-washed phone-pics of the ashy miles of dry-erase marker I've scrawled on walls while mapping out workflows, data streams, user paths, and customer journeys. whiteboard snapshot Still farther down the rabbit hole, would you like a tour of some of my flat mockups? I've got megabytes upon gigabytes, hundreds if not thousands of layers impeccably labeled and nested to be hidden and shown as a poorly pantomimed proxy for an interactive experience. photoshop mockup No? Oh well, no big deal. None of these would give you a round conception of what I can do, or even what I have done. My finished product is something experienced only by, well, experiencing it yourself.

Many designer's portfolios are viewable on paper, in two dimensions. But an experience designer's work is five-dimensional at the least. Until recently the first three dimensions are those of the user's screen, let's call them x, y, and z. That's horizontal, vertical, and depth, respectively. You may be thinking, "Hey, my screen's flat! Who's out there playing Angry Birds in 3-D without me!?" Well, the z dimension is the one that tells you what's-on-top-of-what on your otherwise 2-D screen. That's right kids, we've all had 3-D desktops since our windows could cascade or tile. Windows cascade vs. tile (I've always been a devout tiler. How about you?) And with Facebook throwing Oculus a POV-porn-themed quinceaรฑera, expect a plus-one, like ฮธ, as in theta, which is the Greek letter often used to signify the angle of rotation in a polar coordinate system. Which way is the user looking? How fast is she moving? Before long we'll be cracking our old dogeared copies of Einstein's Relativity.

Spatial dimensions aside, the UXer must also consider the t dimension, time. How long does the user want to spend on this? How does a 500-millisecond transition feel compared to a 200-millisecond transition? During what time of day do we expect users to be logging on? We're aiming to launch this when!? Time holds the music, carries the dance. Designing for t brings rhythm into the mix, something visual designers use as a metaphor when discussing composition, texture, layout, etc. But experience designers must weave a tapestry in space and time, and often in another multiverse altogether.

The multiverse I'm referring to arises from offering choices to the user. The choice dimension, c, is not linear or scalar like the spatial and temporal dimensions. That is to say, we can't plot the user's current choice position as being some measurable value on a line with known endpoints. Wait, who brought maths into this!?