I hope this short, 2:36 video is just the start of a more public conversation about hiring practices within the UX community. I hope it helps to define UX titles and terms, and I hope it helps UX teams break past unspoken practices in team dynamics and hiring. A video like this is a long time coming and covers one aspect of a topic I have been thinking about for the past few years.
The UX Unicorn Myth (Jakob Nielsen)
Summary: UX constitutes many different specialties such as researcher, interaction designer, and Information architect. Forcing one person to do it all is a prescription for mediocrity.
On June 24th, I attended a one-day “unconference”, called UX Camp. I heard about this through Meetup/email. I’m not sure what I expected, but I did hope for more hands-on workshops.
Using Dance for Cultural Exchange: This was presented by Ana Milena Aguilar-Hauke. I thought it was really smart and innovative, but only 2 people showed up to learn about this which is a shame. We could use more cross-cultural exchange these days. Her idea came from her experience living in Germany and the United States from the perspective of someone of Colombian descent. Her idea was to use salsa, which is a fun, easy to learn dance, to might help people interact with each other.
Independent UX (More of a pow-wow/thought exchange): Helpful, especially for people who are managing their own work as an independent or seeking to. We used voting and Kanban boards, which I hadn’t heard of before, to go through ideas. I got that recruiters really take away your ability to earn more money because they’re skimming off the top. And, I learned that other UX professionals are experiencing the same portfolio headaches that I am.
I’ve since become interested in learning more about Lean and Kanban, which I’ll talk about in an upcoming post.
Tips on Design Sprints: I kind of wish I’d skipped this because, apparently, a really great talk that confirmed many of my job hunting suspicions was going on that I missed and probably would have enjoyed. But on the other hand, it was a hands-on activity like I wanted and it gave me new ideas to think about.
Agile to Tri-Track: This was presented by Dave Malouf. I wanted to learn more about Agile. I figured “tri-track” was an improvement…? I am still not quite sure what this was about.
Systems Thinking: I went because I wanted to learn about systems thinking. It sounded like an interesting discussion. It wasn’t quite what I’d hoped, but maybe he will improve it later.
Portfolio Discussion: This was helpful and vindicated some of the concepts I’ve been thinking and writing about when it comes to what UX managers look for (or don’t look for) when reviewing portfolios. My strategy now is to include information about an unexpected challenge I experienced and what I learned on the job.
OK, XYZ Foundation is not really the name of the organization. But I really was asked to complete a UX challenge for a job application.
Since it helped me get through to the 2nd round, I thought it would be nice to share it. The challenge description (from them) and my submission (from me) are indented and given a different color.
Kudos to them for choosing a challenge that had nothing to do with the company itself. They don’t have anything to do with food or supply distributions.
Scenario We are building a tool to connect restaurateurs and chefs with food and kitchen equipment distributors. We want both groups of users to have the capacity to search for one another and set requirements in order to get their needs met. Also, each set of users should have the capacity to record and broadcast their needs or resources so that other users can browse through them.
Task We’d like to see a plan for how you would go about assessing the needs of the various users, collecting and studying similar projects and potential competition, and designing and testing the experience of this tool’s users. We are expecting a roadmap for what steps will be involved in conceiving, developing, and testing the design of this tool.
My only clarifying question was what “record and broadcast” meant. They estimated this to take 1-2 hours, so I didn’t try to go into too much depth.
I wasn’t really sure who would be reviewing this, or how it would be used. Ostensibly, this was just for them to understand if I really understand usability. But if this was real, and I had been asked to create a plan, I wasn’t sure if they would use this as a formal plan or as a general outline.
So, like going to a party where you don’t know the dress code, I decided to go a little more formal with a report using a Google template.
New restaurateurs and chefs expanding or creating a new restaurant need kitchen equipment to stock their kitchens. Kitchen supply distributors (KSDs) want to be able to find restaurateurs looking for kitchen equipment.
1 – Restaurateurs need to be able to search for equipment and post requests for quotes.
2 – KSDs can search for restaurateurs and send quotes.
Online exchange where restauranteurs can search for supplies, as well as post request for quotes from participating KSDs. KSDs can search for restauranteurs and send quotes. Perhaps a Craigslist for restaurant equipment. There may also be a weekly newsletter with new requests.
Below are milestones that would be part of the design process for this tool. In the real world, constraints such as the budget and release date would have a bigger impact on the functional scope and timeline. Also, the actual process might not be this clean, or steps might be skipped or combined, as needed.
1. High-Level Process Map / High-Level Research
Create a basic high-level map of the process, to get a fuller picture of the scope of the problem. High-level research of kitchen supply distributors, to get a sense of what they do and offer. (See example, below.)
2. Stakeholder Interviews
Interview 2-4 restaurateurs and 2-4 distributors. Analyze finding and create personas if needed.
3. Research kitchen equipment distribution sites
What do these sites do well, what do they do poorly. How are their times organized and catalogued. Probably will return to this list often.
4. Create list of tasks tool should support
Decide on the scope of the tool. Don’t need to work on everything at once, but have a sense of the bigger picture. This is also a time to figure out the overall information architecture.
5. Create workflow for first task(s)
Pick one section of the tool, and sketch or list out a more in-depth workflow. For instance, what is the post process for chefs? What is the search and reply process for suppliers.
6. Create a draft of wireframes for task(s) – repeat
Sketch wireframes and create a first set of wireframes for whichever tasks were identified in part 5. Use these documents to meet with internal teams regarding feasibility, scope, business strategy, research, and timeline.
7. Refine designs / Prototype
Use feedback from internal meetings to refine wireframes, as needed. Progressively getting more detailed. Create a prototype, if possible.
8. Usability Testing
Return to earlier users, or sample of users, to test prototype or designs. Update design based on feedback. Could also try paper prototypes, between step 6 and 7.
Example: High-Level Process Map / High-Level Research
1 – Chef wants to open a restaurant. 2 – Thinks about his needs.
3 – Option 1: Goes online and searches for supplies. 4 – Pays for items. 5 – Items are delivered.
6 – Option 2: Chef fills out a form or posts needs online. 7 – Distributors get or view the request. 8 – Distributors create bids/quotes for chef and send them. 9 – Chef reviews options and picks a quote that works. 10 – See 4. 11 – See 5.
This overview can be digitized, if it needs to be shared out.