I make a living by breaking software and testing assumptions about user behavior. After 6 years, I have seen what a difference good design can make on the implementation and outcome of features.

Aside from my technical background, I also have a passion for education. Coming from a family of educators, I’ve witnessed the difference a passionate teacher can make on an individual, classroom, and community. Before my career in software development, I was also preschool teacher in Seoul, South Korea.

Growing up in a rural central Pennsylvania community then living in metropolitan cities like Seoul and Austin, I have come to appreciate the differences each area and culture provides. I see the next year at AC4D as a chance for me to acquire the skills necessary to help underserved areas without disrupting the environment which make them so unique.

When I’m not behind a laptop or burying my nose in a book, I like to walk my dog, practice Kendo, and explore Austin with my wife Qian.


Recent Tweets

@alex_wykoff: A robot just propositioned my design partner for 'non-committal sex' over the phone...I think I was just witness to a grad level HCI project

@alex_wykoff: Wykoff's Law: The last ticket you test WILL be the one which holds up the release.

@alex_wykoff: RT @xuhulk: We ask our students to try outsourcing some work to labor networks. @komichiewa had some great success with it! http://t.co/1cO…

@alex_wykoff: Kaffee und schnecken, eine tolles frühstück http://t.co/eAGFU5BI7d

Recent Blog Posts


New Quarter, New Queery, New Hubris

As Chelsea and I continue our quest to bring Queery to life, we had to start extracting a singular thread of reality from the mystical cloud-of-what-could-be.

In many ways I think this has been the most challenging aspect of our work thus far. Every decision is a hard-fought battle between individual expression of hopes and desires which is constantly tempered against what is appropriate for the community we are trying to serve. These decisions usually are a compromise in one measure or another and they ultimately pick a singular reality at the expense of all others.

That’s not to say that we can’t go back and try other solutions, but if you have ever been in any software development shop for any period of time you know how expensive and rare that is.

While we have been slowly building our app, it is clear that our ambitions were considerably beyond our talents.

We reflected on this, stressed out a bit, and considerably scaled back the fidelity of our pilot. We now have a Google form to handle what the schedule flow would have covered and we will be hand-matching individuals as they sign up.

Chelsea also created this nice sign to remind us to keep it real.

I’ve kept an eye on that sign to remind myself to work within the now instead of the what-could-be and to see if either of us had the courage to bump the day counter up.

It’s been over a week and that number hasn’t changed.

Posted in Strategy | Leave a comment

How to create a pilot app for $1.54 (and a fair amount of time and aggravation)

Fair warning, this is a technical post and doesn’t cover much (if anything) design-related. I just wanted to share what I used to allow for us to build up a prototype without much cost.

As we are knee-deep into the fourth and final quarter at AC4D, the task is to pilot our ideas within the community. The amount of fidelity can vary greatly, but one of the goals is to assess whether or not our abductive leaps have landed on solid ground.

I set a rather ambitious goal to actually build our application in its entirety. I also wanted to explore a few technologies which I haven’t had the time to investigate otherwise, but I believed were going to be a solid fit for our project.

The first thing I did was to go to Walgreens and purchase a pre-paid Visa card. Many online services, especially the ones I wanted to employ, require a credit card to be on file before utilizing any free trials. This allows me to create a solid budget constraint and to avoid any security issues with my personal credit in case the data is stolen, which happens more often than you’d like to imagine.

The next steps occurred in a less-than-ideal order, but it worked for me.

I went to Amazon Web Services site and configured an EC2 instance. The Linux micro instance is free for one year. Since I am no stranger to their pre-configured Ubuntu instances, it was an easy choice.  I could create a complete separate post about this step, but the short-short version goes like this: Read the directions they give you, read them again, attempt what they describe. Rinse, wash, repeat.

Once the EC2 instance was up and running, I poked a few holes in the firewall to allow for an SSH connection and HTTP. I also created a set of SSH keys so that I could safely connect to our git repo and deploy code. You don’t have to have a git repo, but I certainly recommend some form of version control other than copying and renaming folders.

So why choose EC2? Freedom and cost. The EC2 micro instance supports nearly any stack you could possibly wish to use. If I had chosen a typical hosting service, I would pay a lot more and have rather limited choices as the IT manager for hosting services usually likes to keep their servers in lock-step and tend to lag on support for the latest libraries. EC2 is free for a year and I can do what I like. That’s an incredible deal.

Having said that, if you would like to save yourself some incredible configuration headaches, Digital Ocean is a rapid up-and-comer in the hosting space which provides a ton of flexibility, a great management interface, and very little challenge in configuration. You just pay a bit more for the convenience.

With this much configured, I wanted to get a server up and running as quickly as possible. I had played a little bit with Meteor in the past, but I wanted to try it for our project for a few reasons:

Firstly, it is a complete stack with a Node.js front end and an integrated Mongo data store. My view is that if I need to use HTML, CSS, and JavaScript, why not let that be all I have to learn instead of trying to pile on Python or Ruby? Granted, CherryPy and Flask are pretty quick-and-easy, but a simple stack means that it’s easier to bring people onboard to help. Mongo is a recent favorite technology of mine since it doesn’t require a strict schema. I can add new attributes without having to retrofit.

Secondly, it takes only 4 lines to install, create a project, navigate, then start a server. I would be able to discover any network issues very quickly this way.

Thirdly, it is intended for use as a web app. Updates to data or behavior are pushed out to the user without having to ‘bounce the server’ (stop the server, make chances, then start the server).  This also means that the site is always ‘live’. As the users interact with the system, it can constantly update the other users’ view. In the case of Queery, this means that the moment a new meeting is available, other users could be notified. Static web pages can’t begin to come close to the level of interaction possible.

So far, everything I have described has cost $0.00. So where does the $1.54 come from?

If you want a domain on the cheap, 1and1 is impossible to beat. If you want a .com, it’ll set you back a whole $0.99. This sometimes means you need to get creative with you domain name, but ‘getqueery.com’ seems pretty reasonable to me.

To get the name ‘getqueery.com’ to point to the EC2 box, I had to use Route53.  I honestly don’t know if there is another way to use DNS to point to an EC2 instance, but for $0.55 including tax, it seemed like a pretty reasonable deal.

It was quite a learning experience to get this up and running, but you can now visit http://getqueery.com/ and sign up for our pilot!

As the pilot progresses, expect a few followup posts on how to implement multiple views in Meteor and how to use the HTML5 geolocation and vibration APIs!

I hope this has inspired you to think a little differently about just how far you want to go with your pilot. Got any questions or suggestions? Feel free to contact me via email or twitter

Posted in Startups | Leave a comment

The Spectrum Project Final Update – From 0 to Queery


As my partner, Chelsea Hostetter, and I have reached the end of quarter 3, it is time to summarize what this time has meant for us and where we will be heading as we step into our final quarter at AC4D.

However, before we dive into that, some thanks and recognition is in order.


Firstly, to our participants, including the Transgender Education Network of Texas, the Central Texas Transgender Society, and PFLAG . You have been incredibly generous with your time and personal stories both triumphant and painful. Thank You.

To our classmates, who have provided both support and challenge via their critique. You’ve helped us to create a better design. Thank You.

To the professors of quarter 3, Matt Franks, Kijana Knight, and Jon Kolko. You have all been instrumental in helping us to make sense of the data and continuously refine our ideas into something greater than it was before. Thank You.

Finally, to our friends, family, and loved ones. You have been our design guinea pigs and our most ardent supporters. Thank You.

Previous posts

For handy reference, here is the history of our posts in chronological order:
Spectrum Project – First post
Spectrum Project – Update 2
Spectrum Project – Update 3
Spectrum Project – Update 4
Spectrum Project – Update 5
Spectrum Project – Update 6
Spectrum Project – Update 7

At the beginning of this quarter, we had 300 design ideas.

Although we had picked 3 to present for our final, our hearts were not set on any particular idea. Initially, we were leaning much more in the direction of either a comic book or a videogame as we are both quite interested in such things.  However, we carefully reevaluated our design ideas and tried to strike a balance between presumed impact, our passion for a particular idea, and feasibility given our skill sets.

Our first concept : A Birchbox for the trans* community

We ended up with our first idea, which was Clique. A Birchbox for the trans* and gender variant community. The was a high level concept which strived to create a space to grow mentors who would curate boxes of things they wish they would have had during the earlier stages of their transition.

We brought this idea to the class for critique.

We carefully wrote down what each of our classmates and Jon had to say and systematically walked through each of the points to see what we wished to address.

We reexamined why we wanted a box and what this all really meant for our community. Our next iteration on this concept was to ditch the box but carry forward two concepts, mentorship and curation.

We asked the community what they wanted to learn about and what they were willing to teach.

Our second concept : Mutual mentorship

What resulted was a concept called Three4Three. We democratized the mentorship concept so that everyone is a mentor. By sharing their strengths, each member could gain confidence while making new connections.

Speaking of connections, this is where our curation concept was carried forward. Instead of curating a box, we thought to curate the community instead. Most websites are open and free. They want to have as many users as possible to that they can receive more advertisement revenue. As such, they do not work particularly hard on removing negative users as that would cut into the bottom line.
Out of concern for our community, we intend the opposite. With particularly strict controls on who can enter, we create a safe, trans* positive environment.

We then brought this idea to our classmates.

Again we were brought some incredible challenges from our peers. We thought carefully about why we felt mentorship was so valuable. After some consideration, we landed on the concept that companionship was the most valuable aspect of the interaction. So we then decided to carry forward 2 concepts: a curated community and companionship.

Our third concept : Friendship and networking over coffee and a game

Coffeeroulette was our next concept. It simplified the meeting of two individuals so that instead of a teaching session, they would meet over coffee and a game.

It was also around this time that we started thinking that this would be a mobile application.

We printed out a series of scenarios with common user tasks and had members of the community try to imagine themselves in those scenarios.

What we learned was that overall, the concept was solid, but there are foundational trust issues which needed to be addressed. We refined our idea once more, and tried to reduce the concept to its most distilled form.

A fundamental question : Can we bring two random people together?

We had a fundamental question which needed to be answered: Can we bring two random people together for coffee?

The answer is yes, however there are some caveats. Fortune smiled upon us as our random pair happened to both be enthusiastic programmers. Most importantly though, was that they both had a friend in common. This mutual connection was the linchpin to the establishment of their fundamental trust.

It was after this test where the mechanics of our community growth were established.

A network of friends

For this concept to work, we needed to create a network of friends. So we decided that instead of allowing for a free-for-all registration system, we would be invite-only.  In particular, we recalled the invite-only, early beta trials of other social networks and realized that after a certain point, a few things happen:

1. The invites become commoditized.
2. Someone is a little careless with their invites and negativity increases.
3. At a certain size, the community is subjected to Eternal September.

We needed to control two critical issues; the flow rate of invites and the quality of who is invited. From this, our ratings system was born.

We recognize that invites are a form of social currency and that there will be pressure to give an invite to acquaintances. In these scenarios, people who are not particularly trans* friendly would normally gain access to our network and wreak havoc if left unchecked.

We ask our users to rate one another and the location where they met after every meeting. With enough negative ratings, not only is a user ejected from the system, but the person who invited them has their rating lowered as well. This, along with a per user invite cap, provides backpressure so that they think very carefully before handing out access.

Between our scenario and live tests, we proved that while a game wasn’t necessary, having a common subject does help start the conversation.

Our final concept

From this, Queery was born.

We then brought this concept back to our users via usability testing. The response was great and we rapidly refined our interface. With some fantastic help from Matt Franks, we ended up with a smooth application which allows users to schedule a meeting around their selected topic, find each other with a discreet signal, and rate the interaction.

On Saturday, Chelsea presented our refined concept to a crowd of designers, entrepreneurs, and AC4D professors. The presentation is available here. We received some wonderful compliments and some sage advice on where to go next regarding business models and technical strategy.

So what’s next?

Over the next quarter, Chelsea and I will be building this concept into a live demonstration application and we need your help!

We’re are looking for mentors in entrepreneurship as neither of us have a sturdy background in finance, marketing, or sales. On the technical front, we are currently leaning toward an HTML5 responsive mobile webapp. If you can find the time to impart some of your wisdom, perhaps over lunch or coffee, we’d love to hear from you!

Posted in Interaction Design | Leave a comment

The Spectrum Project Update 6 : Getting specific

Last week, my design partner Chelsea Hostetter introduced Scenario Validation, where we allow the user to read through and imagine particular uses of our application.

In particular, Chelsea highlighted the core of our application which we believe works well:

CoffeeRoulette’s best features include:

  • a curated community of trans*friendly folks, initially seeded by the alpha testers in the trans*community.
  • a no-hassle 45-minute timed meeting to meet with others (but not feel bad if your time runs out and you don’t want to meet them again)
  • a way of connecting others in a generally anonymous, one-on-one way to protect the privacy of individuals.

Having these fundamental concepts of the structure of our community and the ground rules of a time constrained meeting between anonymous participants, we were able to rapidly try various permutations of the meeting mechanics, continuously refining our concept along the way.

After a certain point though, if the design idea is to become real, you have to prune your options and make some lasting decisions.

With that said, we have landed in a pretty solid place and have decided that the way we would like to go is to ditch the games, focus on the trans* and gender variant community, and give people the most direct path from invite to first meeting.


After receiving a lot of feedback, we changed the name one more time. ‘Queery’ plays on two concepts, the primary one is that this is for a nonconforming community, the second being that so many of our participants have questions and would like to find some friends with whom they could explore these questions.

From the image above, you can see the first few screens a potential user would encounter. The very first is an email invitation from a current member.  We believe that this social vetting mechanism is a great way to keep the community safe and to keep the quality of the interactions high.  After clicking on the link, the user is sent to a web app (see forecast.io via your smartphone for our inspiration) where the user is given a carousel of discussion topics. Most of the topics are rather broad and inclusive of the broader community, some are very specific to the trans* and gender variant community.

The user has to make 2 selections, create a password, then they are given an option to confirm the meeting. We decide the location and discussion companion, but the rest is driven by the user.

Our goal is to help introduce members of the community to one another in a safe manner. We hope that these meetings will help our members forge friendships and build out healthy, supportive social circles.

So how do we know this idea is useful for our community?

More testing!

Our mission this week is to complete a series of usability tests which allow our potential users to give us feedback on not only if the app feels easy to use, but also if is it useful for their needs.  Preliminary feedback is certainly looking good.

Would you like to help us test? It takes an average of 30 minutes, you’ll get free coffee, a sneak peek at our design, and the chance to help the community. Please email us at spectrumproject@ac4d.com

Posted in Design Research | Leave a comment