Update: I’ve edited a few parts to make it a little clearer. Same message, just easier to understand. Iteration for the win!
This could have also been titled: “Why you are doing your organization a disservice if you’re hiring researchers to only conduct usability testing, or hiring designers to do research.”
Welcome to this week’s soapbox post!
If you’re familiar with me or my work or you’ve been keeping up with this blog, you know that I am currently in the market for a new job. I fully realize in a post-COVID world that being a researcher (while it should be one of the most important roles today for a lot of companies during turbulent times) is actually a very tough position to be in when looking for a job as it’s always one of the first cut in product development.
I think this happens for several reason, two of which I am going to address today.
One: A lot of job descriptions I’ve read lately are looking for UX people who are capable of conducting research and doing usability testing. While these are indeed admirable traits to have as a UXer, and I’m one of those UXers that embodies them, I would not recommend relying on your designers to do all of the research work that should be done. Why? Well, if for no other reason these are two different skillsets. Additionally, if you have an agile environment with a continuous release cycle, your designers are already too busy keeping up with that. Not to mention the fact a proper research team should be a full quarter or two ahead of them! It is difficult to encompass both of these capabilities in the same role. Research should be a full quarter or more ahead, you ask? Yes, and this brings me to my second reason.
Two: There is a lack of understanding of what research is and how it can be useful. Usability testing (and yes it’s usability testing NOT user testing – we are testing the usability of a site not the user’s ability to use it, those are two different things and this means a lot when you get into inclusive design) is not the end all be all of user research. In fact, it is a tiny sliver and if the appropriate research has been done ahead of time in your organization, you will not need it as often and you won’t have to rely on it as much.
So let’s break that last point down. Usability testing is generally what I see organizations who are new to research using to dip their toes into the discipline. They have read and seen why it is important and think that it will make a difference for their users. This is all correct. The problem is many organizations who are new to this think that’s all there is to research and they feel they have to test every single thing before it is released. In reality, research should be more about problem finding than trying at the very end to work on testing solutions to problems that were likely not fully understood to begin with.
If you have a research team that is versed in problem finding (utilizing generative/exploratory/discovery methods) and uses those skills to help your product people fill their gaps and blind spots, it is likely that a lot of the issues that your products or services are currently challenged with will be solved as a nice side effect when you focus on those uncovered during this phase. Why? Because, solutionizing right out of the box is how a lot of products and services find themselves in trouble. Going problem finding opens your organization up to a whole host of new possibilities and opportunities that would be otherwise missed and cause issues down the road because you didn’t know they existed.
By conducting exploratory and discovery sessions first, you’re connecting with the people in your space who are trying to solve their problems with your product or service. When you understand what those are, it makes it easy to see that they are the problems your work should be focused on. If your product or service does not solve problems for your users, it doesn’t matter how usable it is or how many features it has, it will never end up being what they are looking for.
Additionally, the treasure trove of data your researchers will come back with during this phase will likely reveal a lot more opportunities for ideation and innovation than any single product manager will have the capacity to do. (This also helps relieve some of the pressure product managers have due to all of the other responsibilities they are saddled with in this day and age.) The added bonus is that when you use data to drive your designs from the beginning, it results in designs that have fewer hurdles to cross when it comes to usability testing because they started with a firm foundation of data to support them.
In the end, this results in faster design, development, and testing time which equals faster time to market. This, however, ONLY works if you have a research team that is able to work well ahead of your design and development teams while at the same time also working through the design and development phases to continue advocating for the users throughout the entire product life cycle. This is why I do not recommend designers be the ones who also have to shoulder that responsibility. Yes, EVERYONE on the team should be a part of the research process, but they also have their own roles to play and the researcher is there to help make it easier, faster, and more efficient for them to do so.
So the next time you’re writing a job description, I beg of you to keep all of this in mind. And, when you’re looking to cut – consider the amount of money a researcher can save you and make you if you truly utilize them in the right ways.
The first I heard of COVID-19 was at the end of January. I had a team member visiting family in China. She had flown out the morning the news broke here so she was in the air when we all found out what was going on. I was worried for her safety and her safe return. None of us had any idea that the effects of it would become so much broader than the concern we had at the time for our single team member. Within 2 months everything was locked down to help slow the spread. For a research team at a hospitality company, that meant our work took a hit as well. Three months later, we find ourselves here.
Last week was a hard week for my team at Hilton. We had hope we’d make it through, but in the end it was all for naught. I have to say, I really liked my job. I loved leading a team of amazing and brilliant researchers consisting of PhDs and Masters. They made it easy. They knew what they were doing and were able to carry out their work with no need for micromanagement (that’s not my style anyway). When problems or questions came up, they were interesting and challenging and we worked together to solve them.
At first I didn’t understand why they wanted a director with 14+ years of research experience yet was tasked with no hands-on research (even as the head of a research team at IBM, I still did a lot of heavy lifting). It was only after I started fielding actual on the job issues that it became much clearer. Though this was a different experience than the one I had at IBM where I had to build a team from scratch and then teach each of them what it meant to do research in the corporate world (much through example), I still found it worthwhile and fulfilling.
What was great about this team was that no one was afraid of what they had to do even if it was something completely new to them. Though we rarely worked together on the same project (they were all embedded on separate teams), when someone needed help, everyone jumped in!
For example, it is practically impossible to run an eye-tracking study alone. We spent an entire day together working out the research plan and then getting the hardware and software setup and running. It was a true team effort from researchers working on the ins and outs, to me setting up (and scavenging) the hardware and observation setup, to our research ops manager getting the eye-tracking company on the phone to help us get the software working. There was a real camaraderie where everyone was there for each other. We all wanted it to be successful and we knew we had to work together to make that happen.
The best part about my job was I felt like I really made a difference. I mean, what more can you ask for when you walk into an existing team. I focused on building up the team culture as well as the practice of research and the strengths of each individual. We worked hard to show the value we could bring and why research was important.
We had regular 1:1s where we discussed whatever they needed to that week. We had regular team meetings where we shared knowledge and expertise and learned from each other at all levels. And, we had a bookclub where we learned with each other. We genuinely cared about each other and our work, our users, and the company.
We haven’t worked together for nearly 3 months, but we all still chat in my personal Slack where I field everything from mentoring questions to keeping up with our ongoing bookclub and now help finding jobs. We may not work together anymore, but we are still a team.
What is sad is we had only been together 5 months. We were just getting started. I had a lot of great plans for the team. We were working on building up our own research repository that met our needs and would eventually fulfill the self-service needs of those with whom we worked. My next goal was to get our own Jira board and workflow setup so that we could standardize the way we took in research requests and so that it would be easy for me and my ops partner to show data to support the work our team was doing and that we had more work than people! (This worked well for me using Git at IBM, I was really excited about getting it going at Hilton, too.)
Additionally, I was making an effort on maturing the research model within the company. This meant gradually moving it from one where design relied heavily upon a lot of usability testing to one who tested when needed, but also prioritized problem finding – looking deeper into the wants and needs of our users from our guests to our hotel staffs – so we could solve the problems that really mattered instead of just focusing on things one screen at a time. I was also working out how to create a more inclusive research and usability testing process reaching out to our recruiters and panel companies on how to do this with dignity and purpose.
At the team level, I pushed for them to be thought leaders and to find ways to share their knowledge and craft with the outside world. One of our goals was to have Hilton Research representation at as many conferences as possible. The last panel we submitted was on how brick-and-mortar businesses could go through their own digital transformations and come out the other side with some very innovative products and services (digital key and connected room were my two favorite future facing technologies we worked on).
We could have done so much. I’m so thankful for having had the opportunity to have been a part of it all. It’s rare that I’m at a job less than a year (though my last one was a year and a half, the one before that was nearly 9 years). While this one was short, it will always have a place in my heart.
I know this socio-economic crisis has had a real human toll across the entire world. And for us, though we no longer have jobs, we are all physically safe and healthy. And for that, I am thankful. However, I know we all have families to support and that is very hard to do without an income. So, I am going to end this post with LinkedIn profiles of a few I know still looking for work including my own. Please feel free to forward these on to anyone needing top research talent and/or research & design leadership experience. Hilton only hired the best, so please let their loss be your gain.
As we go into the new year, I wanted to give a heads up as to a hiatus on any future speaking engagements. Given that I do all of these pro bono (completely unpaid) and they take a lot of time and effort, I am unable to do any more at this time. I have just changed positions and my new one is much more demanding than my last, which leaves me no free time at the moment to engage in any extra work. Thus, I will have to forgo any new ones for the foreseeable future while I focus on getting settled at the new gig.
That said, I will hopefully be updating this blog with all of my presentations from the last 18 months so that the content (including commentary) is accessible to everyone. Since I give all of these talks for free and I do all of the work myself, this will be me giving back to the design and research community. Once they are posted, feel free to share! Side note: I can’t guarantee when they will be posted as this is always a hectic time of year for a family of 5. If there is something specific you’re looking for before I post it, please reach out to me.
Considering blog updates, I’ll continue to post about research including part two of the Breakdown of a User Research Project as I have time. Beyond that, the posts may be few and far between. If you are a college student/new to industry person looking for mentorship, please feel free to use my contact form (don’t email me directly as it will likely end up in junk). I am always happy to help people out and of course there is no cost to that. We only excel as a community by lifting each other up and helping others along the way. I am happy to do what I can to promote design and research as much as possible and there is never any charge to do so.
If we don’t chat before the end of the year, here’s to a great 2020!
So, a lot has happened since my last post. The most important of which is that I have changed jobs and have moved out of the tech space and into the hospitality one as a Director of Experience Design Research. I am looking forward to lots of new, beautiful, and exciting challenges ahead working in a space I’ve never been a part of before.
That said, if you want to see something I worked on while I worked in the blockchain space, check out this Business Insider article on the work my team and I did for Coca-Cola. I was the design consultant that led the research/design thinking portions of the project and I did the designs and prototyping for the application we created that pulled data directly from the ledger for reporting insights.
In addition to that, if you missed my talk on Inclusive Design at Big Design I will be giving it again at DFW Beyond this coming Monday November 18th at 1:45 pm.
This will be a quick (well maybe not so quick) review of a user research project that was conducted in March of 2018. The designs that were tested during this and other research projects that were conducted during this time period helped the design team move forward with work that won design awards this year.
As in most cases, the research work that went into completing the designs is not something that is likely to be publicly recognized. So, I’m taking the time here to showcase one particular research project in order to shed light on the process and the effort that goes into making something like this happen. This series of posts will be a review of how we conducted, analyzed, synthesized, reported, and presented on this research to help inform both immediate design direction as well as strategic decisions.
My role for this research was the head of the research team. I designed the research study, worked with my team to conduct the sessions, and then worked with a junior researcher to analyze and synthesize the results. The junior researcher and I then worked together to writeup a results and recommendations report and we put together a presentation for leadership that we then presented to multiple levels.
Designing the Research Project
Truth be told, I was pulled into this project approximately a week before the research was to be conducted. I had very little latitude in what I could do to pull it off in such a way that it would be useful, so I did what I could with what I had. I was told we would be conducting research at our company’s annual meeting and that we would be doing so with “Inner Circle” companies. Or, those companies that paid a bit extra to see early work prior to release.
The design team originally wanted to hold a focus group, which I vetoed because given our timeline, we would not be able to recruit properly for one to be successful. (Side note: I generally dislike the group think that happens in focus groups. I find the data that comes out of them to be less useful than doing multiple individual research sessions and I would rather take the time to do it right than waste time on data that I can’t use.) Instead, I recommended that we do prototype walkthroughs with different companies who came to our three scheduled 1.5 hour sessions. Since there were four of us going, I suggested we could each take an interviewee and record the process so that it could be transcribed and analyzed later.
I provided a walkthrough procedure we were all to follow including how to set up the interview, the questions to ask, how to ask the questions, and how to probe as needed. Each interview was to take 20 to 30 minutes which meant that with the four of us we could get about 24 interviews. This is a pretty large sample size for this type of research. The thought was we could come together after each session to see what parts of the path were reviewed and then start users on separate paths during future interviews to make sure we captured data on everything possible. As long as we got 3 to 5 users to go down each path (there were 3 main paths), then we would have enough data to move forward with.
Had I been able to design the research early on, I would have gone out of may way to recruit different types of users for each path and separated each round for each path.
Prepping the Prototype
I also reviewed what we were to be doing a prototype walkthrough on and made multiple suggestions to the design team in order to make it a more successful artifact. Note: I highly recommend this for all researchers. If you’ve never conducted a prototype walkthrough before, please have someone who has done so review any work before it is put in front of a customer.
If a prototype is not prepped properly, especially a click-through one, then the user will end up getting hung-up on how the prototype works (or doesn’t) rather than the content within it. Prepping a prototype includes making sure all of the content is consistent from the colors, to the fonts, to the placements, to the images, to the interactions themselves. Even a word being misspelled will cause an issue.
This is one reason why I HIGHLY recommend doing prototype reviews on low-fidelity work. Low-fidelity work is easier to change quickly, easier to keep consistent, and easier to keep a user on-task and in the flow. Once you start adding medium or high fidelity flair, you provide more opportunities for bikeshedding.
I’m not saying not to test high-fidelity work. What I am saying is that it is better if that work has already been tested at a low-fidelity so that by the time you get to testing the hi-fi’s it should result in minimal changes and it should target very specific pieces of the hi-fi work itself and not the content, flow, or interactions. By the time you get to hi-fi, those pieces should already be vetted.
It also helps if you know the material being tested. Full disclosure, I was a designer in the space for nearly a decade prior to creating a research team and conducting this research. Additionally, I am a technical designer and researcher. I have a very technical background (from hardware support, to server administration, to web development), so not only do I very much enjoy this work, but I also have the background to be able to do it successfully. Though it is not a requirement for researchers to be super knowledgeable about what they are researching, I believe in the tech space, it certainly helps.
Conducting the Research
Of course nothing ever goes as it is supposed to. We expected maybe a few companies to trickle in during our sessions as we were in high competition with multiple other sessions being conducted at the same time. That, and who wants to do a prototype review? Well, apparently a lot of people do.
We walked into the room where our session was to be held at 8am and found it FULL! We had over 50 people in there to start with and most stayed the entire 90 minutes. The team I arrived with started freaking out a teensy bit, so I grabbed the mic and took over. I introduced my self, what we were doing there, and then asked for a volunteer from the crowd to drive.
Thankfully, a volunteer stepped up. We put a mic on him, aimed a camera toward him and the prototype we projected on a large screen behind him, and then I led the prototyping session with everyone at the same time. Note: We recorded him, his face, and his voice with one camera and we recorded the session on the computer at the same time.
So, did this turn into a focus group? No. That was the point in having a driver. We let him take the wheel and proceeded with him leading us through his own path. As he went through, members of the audience had their own questions, too. So, I took a mic around the room and got their input as well.
The most interesting part was we had a lot of different types of people from a lot of different types of companies in the room, which meant they all had a different use case or need. Hearing one company’s use case would then prompt another company to engage with them and then state how their’s differed or resembled the previous. Having a driver allowed us to pull people back on track as needed, but we provided a bit of leeway as was necessary if the questions were relevant and had bearing on the current or future design states.
The second session was right after lunch and that went a lot smoother as there were much fewer participants. As they entered the room we had them sign up for a session and provided them a time slot to return. We conducted 10 individual interviews during that 90 minutes.
For these, we simply recorded the screen as they clicked around the paths that were of interest to them. What we found during these sessions was that users were looking for more of a guided tour of our product and wanted to ask technical questions on existing interfaces rather than prototyping up and coming ones.
We decided to go ahead and do the room-wide prototyping session for the third round due to the fact that it was the last of the day and it was considerably smaller than the first session. Turned out we had a lot of networking experts in the room for that one, so it was a much different conversation. Overall, we had more than enough data by the end of the day to move on to the analysis and synthesis stage. I’ll save that for part 2.
I am frequently approached by students, as well as other professionals looking to further their career, on how an interdisciplinary approach has directed my career and where I hope to go from here. It’s been a while and job change or two since I last wrote about this. So, I thought I’d take the opportunity again to delve into my particular career path, lessons learned, and how I combine academics with technology to provide interdisciplinary insights into both research and design.
I started in photography back in the late 90s. And by photography I mean film and darkrooms and medium format cameras and black and white and doing a lot of things by hand.
It was the subject of my first degree (along with graphic arts) and I also worked at pro photo labs (using paint to hand touchup color printed photos or getting sprayed in the face by bleach bypass are things I’ll never forget) for a bit before landing my first job in the computer industry.
Photography taught me a lot of things including patience and technique are more important than hardware or software. I also learned about light, contrast, textures, movement, color theory, focus, and layout — all of which I continue to use to this day.
Darkrooms are one of my original happy places, and though I have yet to watch Stranger Things (hey! I don’t get to watch a lot of TV with all of the other things I have going on), I do appreciate the fact that apparently, they had a darkroom scene. Maybe some interest will spike again. It’s retro now, so that makes it cool, right?
Photography to… Computer Customer Support?
My photography degree also included graphic design and I’m talking old school graphic design here where it was meant for print, not the web. My photography skills blended well with this subject and I also learned things like Quark Express, Photoshop, Illustrator, and more. In addition to the applications, I also learned my way around a Macintosh and this is how I jumped into technology.
Turns out, I had quite the aptitude for working with computers (even though I didn’t grow up with them or even own one of my own until 1999). Here is where chance met happenstance. At the time, Apple had a call center in Dallas and I knew quite a few people who worked there. After talking about needing a new job, I was given a Mac for Dummies book, told what chapters to read, and sent in for an interview.
I was all of 19 at the time and was still working on my first degree, but in those days a bachelor’s degree was not required for work like this. That, and no one had any experience. So as long as you showed aptitude and had a good attitude, you were given a chance. I took that chance and ran with it.
I worked there for a little over a year and in that time I learned how to support every single thing Apple made from monitors to printers to all of their desktop computers including the G3 and OSs 7, 8, and 9. I went from level 1 to level 2 support and then I became the trainer for all new waves starting on the floor. I left the company just as the iMacs were coming out and they were pulling their support out of Dallas down to Austin.
I followed that job with a stint in the print industry (I’ll get to that in a minute) and then to support at 3dfx, which was one of the best jobs I’ve had to this day. Turns out, a lot of the people who ran the support center for Apple in Dallas moved to 3dfx to do the same thing for them after Apple went to Austin. I was brought on to support the Macintosh video cards, but supported the PC line until they came out. Funny thing was, I was the only one they hired to do Mac support, which meant at the tender age of 22 I owned it all (6 days a week, 12 hours a day, phones, emails, and forums – the overtime was lovely) and I loved every bit of it.
It was for 3dfx that I went on my first business trips. I was sent to California (my 2nd time ever on a plane) to QA the Macintosh cards in graphic arts applications. While this wasn’t the focus of 3dfx, they understood who their market was and wanted to make sure there were no problems with these, plus I had experience!
I also represented 3dfx at MacWorld 2000 where I was the tech for every computer on the floor and I demoed video game playthroughs before it was cool (PodRacer) to show the difference between the stock video card and ours.
After they realized the workload was more than they bargained for, I then became a trainer at 3dfx (see a trend here yet?). To help me do this with our European teams, I developed a Mac training support program (all screenshots and hotspots hand programmed in HTML), and used it to assist people in learning how to support a Mac without ever touching one. You could say this was the first application I ever developed, though at the time I never thought of it as such.
Gaming has always been a passion of mine, so this was the best of all worlds. Sadly, 3dfx went out of business and I was laid off as the company folded. Though I’ve yet to land another job in the gaming industry, that has always been a goal of mine and I still hope to do so.
Being in technical support taught me a lot that has served me well throughout the rest of my career.
I am not the person on the other end No matter how much I knew about the technology or how many games I played or how I used it for myself, I was not the person on the other end of the phone/email/forum post. Why does this matter? Well, everyone’s experience is different and there was always some variable that came up that I had never encountered. It provided both a learning opportunity for me and made sure that my focus was on the person on the other end rather than the technology or the problem.
There is always more than 1 way to solve a problem I’ve mentioned this in a few papers I’ve written on gaming as a part of my academic career, but it’s so important that it’s also worth noting here. Whether it is technology or gaming or development, you soon learn that when you get stuck it helps to evaluate the situation from multiple perspectives.
Community makes a difference And this is probably one of the reasons why I gravitated toward Anthropology when I started my bachelor’s degree. I learned early on what a difference a community can make in the workplace, online, and around a common goal. Techsupport, especially back in the late 90s and early 2000s, was a place where all three of these came together in a way I’ve only ever seen replicated in open source development and gaming.
I worked in the print industry for about a year. How did I end up there? Well, I answered an ad in the local paper (back when they were printed on paper) for a Mac Tech. I thought, well hey, I’m a Mac Tech. Turns out they were looking for an electronic pre-press (EPP) operator. I told the guy doing the hiring that if he hired me I could learn very quickly and I could fix/support every computer he had in his shop.
And yet again, someone gave me a chance and I ran with it. By the time I left, I was an expert in Quark and Photoshop and a layout artist and I could do random things by hand that no one has to deal with today like trapping colors and sending work to a rip to print to film and evaluating bluelines and finally to printing on web presses in the back of the shop. This all reinforced the focus and layout, and color theory from my photography days and I was able to support it all with my love for technology.
As I mentioned before, I started with an AA in photography and graphic design. After I was laid off from 3dfx I applied for a certificate program in Intermedia arts. Only 10 students were selected based on their submitted portfolios (mine was mostly photography). In that program, I learned digital music (MIDI, ProTools, MOTU), digital photography (digital cameras in 2001! and photoshop), digital video (Final Cut Pro), 3D Animation (Cinema 4D), and web design (HTML). Since it was all on Macs, I also took up a position as the lab assistant. There were no web design degrees at that time, so this was the best I could do and it helped me land my next job.
(Unfortunately, I have almost no examples of this work, as it was all on DVDRAMs, except for this silly digital music piece.)
Yet again, someone took a chance and hired me for a job I was not qualified for. This is a definite theme throughout my career. The first step is me taking a chance and applying for a job I’ve never had. I highly recommend this. The worst someone can do is say no. The best is you land an opportunity to shine.
Though I had never had a job as a web developer, not many other people had either in 2002. Everything I knew about web development I had either learned on my own or as a part of my certificate program I completed in 2001. I used all of that to my advantage. Additionally, I knew how to support a Macintosh server and the company who was hiring specifically needed someone versed in Mac.
What started out as a simple HTML programming job turned into developing web applications where I turned paper processes into electronic ones and reduced the duplication of information by linking systems together. I learned Lasso and PHP (and subsequently MySQL) in the process as well as user experience design and information architecture. At the same time, I could apply all of those lessons from photography and graphic arts as well as my technological background. I supported the Mac server and even established the first Wiki system at the company (for the copywriters).
As a part of that job, I developed workflows to help me keep my head straight when I was developing a system and linking them together. Turns out, this was a skill that was useful in other areas.
Bachelor’s in General Studies
While I was working as a developer, I went back to school in 2004 for my bachelor’s degree. I had to wait until I was an independent student in order to take out student loans on my own (oh if I had known then what I know today). Given that this was now costing a pretty penny, I looked for the fastest way to complete my degree and settled on General Studies where I focused on Anthropology, Psychology, and Philosophy.
Though I didn’t know it at the time, all of that would apply to my career and even my current position. After I started applying my anthropology and psychology lessons to my work, a whole new world opened up. I completed my degree in 2006 and finished with an ethnography of a guild in World of Warcraft as well as an ethnography of ecologically friendly people for Motorola and their EcoMoto project. Being able to do an ethnography entirely online in 2006 and taking a design anthropology class that same semester helped influence my entire academic future (and is what helped to start this blog). Funny side note, my World of Warcraft paper is one of my most referenced papers to this day.
Interaction Design & Information Architecture
Though I had no idea what user experience design or information architecture was when I started my development position, these are where I started focusing my career by the time I was ready to move on. And yes, in both of the following cases, once again someone took a chance on me applying for a job I wasn’t “qualified” for.
First, I took a job as an interaction designer at a startup. There was just 8 of us working for this company and that was quite an experience. I’m glad I had it, but I’m also glad I was able to land on my feet quickly after as that company was sold after almost a year.
I then moved on to a position as an information architect at a marketing firm that also developed web applications. There, I became a Visio pro and versed in e-commerce. This was the first time I would work as a consultant and travel in that capacity. I worked directly with Lowes at the time and performed activities such as Card Sorts on-site to help them narrow down their navigation categories.
Quickly, the company learned they had gotten in over their head and they let go of most of their e-commerce staff. My talents where agnostic of technology or industry, so I was able to be moved on to other projects and customers like Samsung and EDMC. In that capacity, I designed everything from landing pages to full-on applications created in Director.
The best part about the job was the variety in the work. The worst part of the job was tossing it over the wall to the next team and rarely ever seeing the finished product. I enjoyed my work and I learned quite a lot, but I realized quickly that it wasn’t the type of position I was best suited for.
Masters in Applied Anthropology
As I moved on from the interaction design position at the startup to the information architecture position at the marketing company, I also continued my education and started my MS in Applied Anthropology where I focused on Business, Organizational, and Design Anthropology. (I also started this blog the same year I started my degree.)
My thesis focused on how to Maintain, Sustain, and Grown Online Open Source Communities where I worked with The Fedora Project through an entire development cycle and conducted almost all of my research entirely online. To do this, I was a participant-observer in the community (IRC/mail lists), I conducted 13 interviews with key informants and then created a survey that had over 100 full responses from over 20 countries. After a full analysis and synthesis, I was able to outline ways the community could help improve itself both for its current members and those looking to become a part of it.
While I was working on my MS, I was recruited from my consultant job at the marketing company to work on an HR software as a service (SaaS) application. The person who hired me was a true visionary and though he didn’t necessarily know what exactly I did, he knew he needed one of me. And yep, you guessed it, yet again I landed a job for which I wasn’t exactly qualified.
In the full throws of my MS education in anthropology, I pulled out all of my tricks to perform as much guerilla research as I could to figure out what was going on with their current implementation. This included talking to the developers and hanging out in training classes with users. Though I was never given the opportunity to speak to them, I listened to everything they talked about, every question they asked, and every complaint they lodged while undergoing training.
This was an amazing treasure trove of information I couldn’t have done my job without. Based on all of this, I took their completely siloed system (all the way down to the dev teams!) and changed it from a product-focused application to a role-based one that included customized navigation and statefulness. The change in nav was just the beginning of our complete overhaul of the system.
Working for this company was my first introduction to agile (though I’d argue our team of 5 back at my dev job and team of 8 at the startup did it, just not in a formalized way), and it would be the first time I was a single UXD on a very large dev team. These two themes continued at my next job, and I even had a couple of devs follow me over.
Our changes to the system, though drastic, were met with overwhelming success and helped the company win an industry award. You can review the navigation changes in my portfolio for highlights.
Senior User Experience Designer, Information Architect, & Researcher
What was essential about this process was getting out a version of our product that would be most useful to our users in a mobile setting. This meant we had to determine what they used the most and why, which of course was a great opportunity for user research. Our research resulted in focusing on the 3 specific categories of Servers, Tickets, and Invoices, which you can see in the example. After this initial project, I went on to completely redesign The Planet’s customer portal interface, which turned into another project altogether when The Planet was merged with SoftLayer.
After the merger, it was the job of me and my agile team to go through and merge two separate customer portal systems together. Rather than trying to start with what we already had and create a mishmash (which trust me, never ends well), we started completely over again and utilized user research to build a brand new experience. This included web, mobile, and desktop applications for infrastructure as a service.
In addition to user research (which included analysis of usage as well as user interviews), I conducted a full information architecture inventory on the existing SoftLayer system as that was brand new to me. This way we knew where to start from and it helped me catalog the existing pages and interactions.
We eventually released our new system and slowly transitioned our current customers off the old ones while introducing new customers to our new experience.
Throughout the entire first phase of this project, I was the sole user experience designer, researcher, and information architect of the entire system. This was the case until 2012 and then I was the senior designer until 2016 (after that I did spot design work/internal consulting until I left in 2018). Throughout that time my team and I created interfaces for all of our infrastructure as a service product ranging from access control to server administration, firewalls, load balancers, a storefront and more.
IBM bought SoftLayer in July of 2013 and I was moved over to IBM Design in May of 2016 as Design Lead of Identity and Access Management and Business Systems Support for our Platform as a Service IBM Public Cloud (Bluemix at the time) offering. I did that for a year and then started our own public platform research team from the ground up (including hiring and mentoring).
This team worked embedded within our verticals doing everything from quantitative analysis of auto-collected user data to interviewing major stakeholders and conducting qualitative evaluative sessions with industry professionals. From there, I was promoted to Head of Strategic Insights before I left to pursue a position in Blockchain.
All in all, I worked for those combined companies a total of almost 9 years. There were a lot of ups and downs with mergers and acquisitions and reorgs, but in the end, I’m ever grateful for the experience I gained while working there.
Doctorate in Interdisciplinary Information Science
I completed my MS in August of 2010 with a 4.0 and rolled right into my Ph.D. less than 2 weeks later. I was granted a Doctoral Fellowship for the first 4 years of my degree program, where they paid for my degree, which was awarded based on my previous academic success. Just 3 months later, The Planet and SoftLayer were merged. Professionally, I was up to my eyeballs in information systems, so I decided to focus my studies on the other thing that was near and dear to me – gaming.
It pays to pick a topic you enjoy when you’re working on your dissertation, and the universe knows I couldn’t take any more information systems at that time and stay sane (this really was one of the best decisions I’ve ever made as the ability to go back and forth kept them both fresh and gave me needed breaks from each other). Also, it was a hot topic at the time as in 2010 video games finally made it to the Supreme Court. I won’t bore you with the details of the dissertation, I’ve written other posts on it (and will make at least one more in the future).
I will, however, provide the research process details. I did a full ethnographic study on families that had children between 4 and 17 who played video games. I interviewed 46 people across 26 different households in May/June of 2015. I then transcribed all of the interviews and conducted an inductive thematic analysis using Altas.ti and over 500 codes. From there I was able to answer my research questions around the usage of the ESRB and whether or not parents felt any legislation was required to assist them in making appropriate video game choices.
I also developed a model on parental information behavior and media that changes as their children age. This is the topic that I will address in a future post. Though it is pretty academic and over 200 pages long, feel free to check out my dissertation. If you like gaming and you’re a parent, you might find it interesting.
Blockchain Design Consultant
After almost 9 years working on what amounted to a single product (through various iterations), I thought I’d try my hand again at consulting. I mean, it had been a decade since I had been a fully external consultant (I had done various types of consulting at in the interim, but not completely external). And, where do you go after SaaS, IaaS, and Paas? Blockchain seemed like the next logical step. It was something new and different and of course something I was not at all qualified to take on. Perfect!
In the last nearly year and a half, I’ve worked with multiple major companies to help them understand what blockchain is and how it could help them influence not only backend systems but also business processes. Though I am not able to talk about any of this due to NDA, I can say I was the designer for the SAP + CONA project mentioned in this Sapphire Now playback. This project included virtual research with the team, a design thinking + design workshop session, creating a fully clickable prototype using Fiori and Build, and working with the front-end and back-end engineers to develop it.
I also had the opportunity to represent SAP at Sapphire where I demoed IOT technology for 400 people over 3 days showcasing our Smart City work. This was in addition to presenting on Design-led Innovation and Inclusive Design (which I will be presenting on again in September at the Big Design conference). Overall, the best part about being in this position is all of the opportunities to learn something new while at the same time helping our customers with truly innovative solutions.
In addition to my Blockchain work, I’m also the owner of Design for Innovation Services including outlining all of our deliverables and scoping. I’m also the project manager for a Knowledge Management initiative as well as an Innovation Management one. Really, I just wear whatever hat needs to be worn at the time and I’m happy to do so.
Teaching & Mentoring
As if all that wasn’t enough, I’m also mentoring a few researchers/designers as they navigate their careers and teaching as an adjunct at the university level. I have to say, out of all of the things I’ve done, teaching and mentoring have been some of the most rewarding.
As you can imagine, one of the things I love to promote is going out and trying something new for which you are completely unqualified. If you’re out of your comfort zone, then you’re learning and growing and becoming something more than you were before. In the words of Nike, Just Do It!
I don’t know what’s next and that’s the beauty of it. All I can hope for in any new opportunity is an environment that encourages learning and mentorship and community and allows me to take advantage of all of these experiences while gaining new ones.
Please reply if you have any comments or questions. I’m also interested in learning about other’s journeys and how you got to where you are today and where you’re looking to go from here (and how you’re going to get there).
If you would like to learn more about my history, check out my CV and Portfolio. My portfolio is a bit sparse due to NDA. So, if you’d like to see more recent work and/or if you would like to connect, you can find me on LinkedIn or you can contact me.
As I mentioned in my last post, I presented at a local conference in October of last year. Well, my participation in that conference led to an opportunity to teach Design Research Methods at a local university as a part of their requirements for their design tracts. I jumped at the chance to do so and I poured everything I had into the class design from November to January along side doing my day job as a blockchain design consultant.
We are now two weeks away from midterms, so I’m taking some time to reflect on the curriculum I’ve put together and what we’ve done so far. I’m taking the time to do it here, because it’s always nice to be able to look back on it later and because others may find it useful. That, and this blog has always been related to my work and my evolution as a researcher, designer, and now teacher.
To begin, I had to consider what would be some of the essential lessons designers should take from a research methods class. The designers in the class span the gamut from traditional design to graphic design, to interaction design, and more. To satisfy the needs of all and the course, I had to come up with a way to present research methodology to them in a universal way, and I had to consider the fact there were 30 people signed up for the class. So, this class has a slight interaction design focus, but the students are able to stretch beyond that if they find a way to do so within the goals and structure of the class.
Overall Class Goals
As presented in the catalog and the syllabus:
This course will explore a variety of behavioral and attitudinal design research methods. Students will walk away with an understanding of how to plan, analyze, and execute quantitative and qualitative methods, understand ethical concerns related to understanding users, and how to deliver artifacts that summarize your synthesized findings.
This course will help you to:
Understand how design research fits in the design process and how to apply research results to design projects
Describe and identify uses of various types of design research methodologies
Plan, manage and execute various design research methods
Understand ethical concerns related to design research
Understand how to report on research in an engaging and useful way
My overall design is an applied one where the students learn about design methods by carrying out research projects on a universal theme. For this semester, I chose social media. I felt this was a great choice because of how ubiquitous it is, because it can be utilized in many different types of environments, and because it is not person, platform, or product dependent.
They are tackling this topic in groups of 3 to 5. Though they are working in groups, each has individual assignments that contribute to the group work in addition to working collaboratively on various assignments with their fellow group mates.
The first half of our 3 hour class time is based on discussion of the topics (not a lecture!), the second half of class they work together on their projects. The first half of their semester focuses on generative research where they interview & survey people about their social media experiences, not products. The goal of this is to understand the space and to surface problems that currently exist. The second half of the semester focuses on evaluative research where they will have to design something using their research results and then test it using various methods with live users.
We are using tools such as a class Slack with private group rooms, Box with private group folders, RealTimeBoard with private group boards, and a class blog where the students have access to their entire syllabus, all assignment requirements, and thorough write-ups of each class with additional materials provided as needed so they can go back and review what we discussed.
Because this is just a beginning research methodology course for designers, I am touching on a lot of different parts of the research process at a high level to get them familiar with them, what they are, what they are used for, why they are used, and how and when to use them. For their first assignment, we started with a Research Guide where they had to come up with a topic, assumptions, a minimum of 2 hypotheses, a minimum of 2 research questions for each, and then use all of that to create their interview script. They completed this work in class so that I could assist them as they worked through it.
Before stepping out to conduct their first interview, all of the students had to familiarize themselves with research ethics. We touched on topics such as honesty, objectivity, integrity, carefulness, openness, respect, confidentiality, social responsibility, competence, legality, non-discrimination, and human subjects protection. Additionally, though this is just a class project, they all had to provide informed consent to their interviewees and had to have them sign a consent form. Before each and every respondent interaction, they had to explain what the study was about, that the respondent could back out at any time, that there were no right or wrong answers, and that their answers would be kept confidential. Confidentiality was preserved through the recording and transcription where no personal identifying information was gathered or used.
They then set out to conduct their first interview with someone they knew. One of their groupmates transcribed this interview and provided a critique for improvements to take into consideration before conducting their second. They all then took the next class to reflect on their first interviews and their critiques, then updated their scripts in class as needed. They used this updated script to conduct a second interview that they then self-transcribed. The caveat for the second interview was to interview someone they did not know. To find this person, their job was to ask the first person they interviewed to recommend someone. This way they got a taste of snowball sampling. We didn’t focus on recruiting, but I did bring it up as an important part of the methodology in the field.
This process gave them a chance to get used to the idea of interviewing by first doing so with someone familiar. They were then able to take that experience and build on it before they had to try to interview someone they didn’t know. They also had the opportunity to learn how to give and take, then apply critiques. Critiquing is something we will continue to use throughout the rest of the semester as they will each critique all of their groupmates for their final and midterm and will also critique the group presentations. We will also have a full in-class critique towards the end of the semester where the students can get feedback from other groups to incorporate for their final.
Analysis & Synthesis
All of these interviews were then placed on RealTimeBoard so that they could work on inductively coding and theming collaboratively for their analysis and synthesis. They are also to take this data and create three different types of generative deliverables including personas, journey maps, and user stories. Though we are using a form of visual coding via an interactive whiteboard for this part of our research, they will be introduced to an excel method for the evaluation portion of class. This way they get a taste of both and are able to adopt in the future which ever works best for their individual needs.
Surveys & Triangulation
Throughout their analysis and synthesis process, they are to be looking out for research gaps. They are to take these gaps and formulate survey questions to help fill them. We will be doing this in class tonight. They will then use their survey and their interview data to provide triangulated results for their midterm report.
Results & Recommendations
They will then take all of this and create a Results and Recommendations report, a Creative Brief (specifically for designers), and a class presentation for their midterm. This way they take into account all of the different audiences that will have to consume their research. The goal of their presentation is to make it engaging and to tell a story. The class will have 5 minutes to ask questions and each classmate in the audience will provide a critique to the group, which will be consolidated and provided as a part of the overall midterm feedback.
Following their generative research results and recommendations report, they will all receive a set of business needs that they will have to take into consideration along with their user needs to design an experience that addresses both. This way they not only learn why to conduct research and how to do it but also how to apply it and how to deal with situations where the business needs and user needs don’t always align.
Low Fidelity Design
As a part of the short design phase, they will be creating sketches, flows, & storyboards. If their design is interaction based, they will also have to create wireframes. Otherwise, they will have to come up with a creative way to display their designed experience so that it can be tested. I’ve already received feedback about the class being too interaction design based, so we’ll see what they come up with if they decide to do something else.
Testing & Iterating
All students will be required to complete 2 usability tests/evaluations using at minimum 2 methodologies for paper prototype testing. Most of this research will be evaluative/formative in nature rather than summative or for validation as we are keeping their designs very low fidelity so they can quickly iterate for additional feedback.
Design Critiquing & Heuristic Reviews
In addition to their usability testing/evaluations each design will go through a heuristic review and a peer critique. After all testings and reviews, the students will have gone through 3 iterations and will be able to provide actionable objectives to design and development teams.
Their final presentation will be a culmination of their entire process including where they started and the path they took to reach their end design. They will have to do it in such a way that an executive would be able to walk away with what they need while at the same time everyone including project managers, designers, and anyone else working on the experience will understand what their next steps are. My hope is to bring in a few “Executives” for the final presentations to ask questions.
The best part of this class, I think, is the curated readings. Once the class is over, I’ll post a link to all of the sources they’ve been tasked with reading. Their individual homework is to read all of the weekly assigned readings and then ask 3 questions for clarification. These questions help inform our discussion for the following class. Though not all of the students have participated (and this will count off for their grade), most have and their questions have been really interesting! I’ll also post some of those and the answers. My guess is that if my students have these questions, it is likely others do as well!
As with my students who I have provided access to feedback forms throughout the entire semester, I’m always eager and willing to take and learn from feedback. This is my first semester teaching in an academic sense, so I know there is a lot to learn from a pedagogy perspective. Please feel free to comment on this post or contact me if you have any feedback. I look forward to hearing from you!
I missed posting last month because a lot was happening! Of course, for everyone who is involved with technology and data at a global level, we have all been touched in some way by GDPR. I know my inbox was flooded with emails on the changes to everyone’s privacy policies and probably yours was, too. It’s worth a read to learn more about it and why it’s such a big deal and how it’s affecting businesses all over the world.
For me personally, May was a big month because I changed jobs after almost a decade at The Planet/SoftLayer + IBM where I had been a design lead for Infrastructure as a Service (IaaS), IAM (identity and access management), and BSS (accounts) and then head of the Strategic Insights team for Public Cloud Research (covering all of Infrastructure as a Service and Platform as a Service). I moved from there to SAP Leonardo Services where I took the position of a Blockchain Design Consultant. This means I’ve been heads down learning all I can about Blockchain and my new company for the last 3 weeks.
To summarize the article, given the immutable state of data in a Blockchain, there is no way to update or delete it. In developer’s parlance, there is no way to perform the UD operations of basic CRUD. In fact, the entire acronym has been updated for blockchain to be CRAB (create, retrieve, append, burn). The problem is, does burn accommodate the “right to be forgotten” and “erasure of data” portions of GDPR? If personal data is in the Blockchain, then the answer is no.
That said, there is a workaround as discussed via creating a hash and a link in the Blockchain that refers back to PII (personally identifiable information) that is stored OUTSIDE of the Blockchain. This results in the PII data only being accessible through an encrypted hash and link to it provided in the Blockchain that can only be decrypted by those who have the key. To ensure the data hasn’t been tampered with, the data retrieved via the link would need to provide its own hash that can be compared with the hash in the blockchain. If the two match, the data has not been modified. This is GDPR compliant because all of the data off-chain can be deleted thus making the hash/link in the blockchain useless. However, the blockchain is then reduced to an access control mechanism to data that remains centrally owned and located rather than a decentralized encrypted transparent immutable replicated ledger of actual data that is owned by everyone.
This results in the following:
The goal of GPDR is to “give citizens back the control of their personal data, whilst imposing strict rules on those hosting and ‘processing’ this data, anywhere in the world.” Also, one of the things GDPR states is that data “should be erasable”. Since throwing away your encryption keys is not the same as ‘erasure of data’, GDPR prohibits us from storing personal data on a blockchain level. Thereby losing the ability to enhance control of your own personal data.
In the coming months, I’ll be posting more about Blockchain along with some Machine Learning, IoT, as well as other forms of AI from a user and design perspective along with my ever-present posts on the Internet, privacy, security, gaming, and social media. I imagine the various topics will merge at some point down the line. I’m excited to be here in the edge technologies space. It’s exactly what I told my circle of friends I wanted to work on at the turn of the year. Thank you to SAP for making that a reality.
This picture is one of the last I took, December of 2016, while we were living on the island of Oahu. It was a beautiful place to live and as the hashtag states, #luckywelivehawaii, we felt lucky indeed. But, that luck only went so far. Working in the technology industry as a remote worker for an off-island company (we had one office on the island that I never visited – it was mostly for transient workers going between the far east and the US) I was able to continue to work in my field. Had I not had my remote job, however, I would have never found work on the island.
I interviewed for a job before moving out there, hoping that I’d be a great fit coming from the mainland with all of my experience and expertise (which by the way you should never do – Hawaii has her own way of doing things and it should be appreciated). The problem was, though the cost of living was at least 3x what we were used to in Texas, they paid a 3rd of what I was making to do the same work. In all my time living on the island, I never saw another job available in my field. And yes, I did look.
What I found instead were other workers like me who worked for mainland offices, on mainland hours, from our tiny island in the middle of the Pacific. There weren’t many of us, but we did exist. Other technologists, I found in the tech startup community, mostly tried to develop opportunities that focused on capitalizing on the tourist market, because it was the only market. Either that or they did like Hello Makana, a company that ships Hawaiian delicacies all over the world, and catered to the people who had left and wanted a reminder of home.
Still, others who were once the white-collar workers of the mainland fell so much in love with the island that they found a way to make it work by doing things like becoming bee-keepers, tour guides, or were a part of the service industry in jobs like bartending and masseuses.
What I will never forget is the disparity between the tourists, the rich who make money off the backs of the tourists, and then the natives who were either exploited for the tourists or forced to work menial jobs because that’s all there was available. In the worst cases, they were destitute or completely homeless. Of those who were able to afford homes, they did so because they had multiple extended family members or multiple families living under one roof. Those homes they could afford were dilapidated, old, and generally unkept due to the cost of doing so.
Now, this is in no way meant to be representative of every possible Hawaiian experience on the island, just a snapshot of what my experience was there and one that falls in line with what the article reports. The natives will always have a soft spot in my heart. During our time there we did our best to avoid most of the tourist trappings and instead sought out experiences of the beauty and the nature of the island that helped the islands in one way or another. That will always be my recommendation to anyone who visits. Skip the tv dinner version and find a way to support the local culture and community any way you can.
Would I have stayed had I been able to find equal work for equal pay? It’s a possibility. What was more important were the opportunities afforded to my children, not only as children but also as adults. While we had to leave the island, part of it will always live within us. My children are better for having experienced their early childhood there. And, though they may never remember it, I have a lot of photographic evidence to help them relive as much as possible.
These are some notes I put together for my team last year. They are based off of a few books I was reading at the time and when I can remember those, I’ll post them for reference. We never made use of these due to reasons other than want and need, but others made find them useful.
These are just notes. Feel free to fill in any gaps as needed or ask questions if you have any.
Creating a User Experience Strategy
An experience strategy is a guide for verticals / projects to be referred back to and updated as the vertical and/or project matures. It is a way to maintain focus on the end goal, providing the user with an experience, and is to be shared with and used by everyone on the team. For our purposes, they would likely live in confluences and our bullets would be numbered so we can refer to a specific portion of it when needed. Personas and journey maps as well as other UX artifacts (research before release / usability tests after the fact) would be parts of the experience strategy.
A strong plan will guide decisions about how the business executes, maintains, and manages experiences to create value for the customers and the business. These should be invested in and managed as well as cultivated and nurtured. A strong experience strategy not only makes it clear what to do, but also what NOT to do.
An expression of the experience you hope customers will have. A statement.
Bulleted list of experience requirements (not ui / developer requirements, not tasks / goals – it’s all about the EXPERIENCE)
user behavior, motivations, context, meaning
usefulness / desirableness
how does it help the user accomplish what they want to get done
how is it (or can be) different / innovative
What do people want to accomplish?
How does this activity fit into their lives?
How can we help deliver on those desires?
Hypothesis based on
personas – which are project based, but stem from our basic set
research – which is project based, but builds on all other research – must be actionable and durable
previous testing – which can come from anywhere, but should help craft project based
Against user stories
With Users / Analytics
Iterate and Evolve:
Take all previous information, build on it, then start over if needed.
Strategy should bring clarity and should act as a sign post to show the company where ewe are going and what we need to do to get there.
Consider making it visual when possible.
Leveling Information – so we all start out with the same definitions.
activities in which people engage
drive and shape behaviors
– understanding the basic drives that lead people to do certain things in certain contexts
help provide meaning to the motivations
learn by doing
worthwhile? important? necessary? required? needed? changes based on context and motivation
Perception is preceded by sensation and followed by cognition if bottom up, if bottom down – then knowledge influences everything (Gestalt).
Ability – consider memory, it includes sensory (get attention), working and encoding (requires heavy attention), long-term and retention (storage). Recall falls off dramatically after 1 day – this is an issue for users who do not / would not / don’t need to / shouldn’t have to – interact with us or a particular tool / experience on a daily basis. Always something to consider. Reduce memory load / ability requirement whenever possible.
Flow – form follows function. Affordance means there is no need to learn. Avoid multi-usability (modes).
Form hypothesis – test hypothesis whenever possible early and then test again with analytics later. (See my pyramid)
Users / Personas in terms of behaviors, motivations, context and meaning:
Who? – are they
What? – do they need, want, use, are they trying to accomplish and is there a better way to do it
Why? – do they need it, want it, use it, like it, dislike it
Where? – do they need it, want it, use it, expect to find it / access it
How? – do they need it, want it, use it, does it fit into their workflow
Theories should be as simple as possible, but no simpler.
Acknowledge and embrace the complexity
Look for differentiators here – avoid parity, novelty, and trying to “be the best” at everything – just boil it down to the essentials, and then go a step further into the murky and complex chaos of the user until you come out on the other side with something that resonates with the users behaviors and motivations while considering the context and meaning
I get a few inquiries each semester from students looking for information on how to get into user experience design, especially those with an anthropology background. I generally try to respond to each of these separately as they each have their own perspective and needs, however, this semester I am trying to get my dissertation defended on top of my every day job as a UXD (which is getting more complicated by the minute). So, rather than leave these unanswered, I am providing a public response here that includes the most common things I share. If you have comments or questions, please leave them! It will be easier for me to respond to those here than individual emails and you may help someone else who has a similar inquiry.
Thank you for reaching out to me. Let me start out by saying that having a background in anthropology will lend itself greatly to UX design, however, it is only one part. My suggestion is to consider opportunities where you will be asked to learn to program or script (even just HTML/CSS) and have real users use what you create. This is not necessarily where your career path as a UXD will take you, but creating something, having users use it, and then having to “fix” it to make it better for them, will provide you with insight that no degree program will ever do.
After that, I suggest looking into classes in cognitive psychology and information architecture or information behavior. Adding those to your anthropology perspective will help you find out what users want and then understand what they really need – which may be two separate things. 😉
As for internships, consider looking into the agency world. What I mean by that is marketing/creative agencies that do campaigns for other companies. Not that you want to go into marketing, I prefer the high tech/application world myself, but it allows you to see how UX is applied to multiple groups of people and projects in a short amount of time. A lot of times you can find UXD or IA (information architecture) opportunities – both of which would be beneficial to you.
And I suggest taking a look at the UX Slack channel that has UXers from all over the world lending their perspectives to the field (and it may lead to internship opportunities).
I hope that helps!
There is a lot that could be added to this, however, I feel it is a great place for people to start. I definitely recommend everyone going into user experience design have some sort of programming or scripting background where people have had to use what you create. My biggest failure as a developer led me to becoming a UXD and in my particular field I use skills I learned as a systems administrator/developer all the time. Not that I do those things anymore, but my past experiences and my understanding of those things definitely help inform me how to make those things easier for others to do. And really, that’s the best part of being an anthropologist and a UXD – being able to use your own experiences to inform your designs. That is, after all, what participant observation is all about!
Following on the heels of last weeks post on my UX Pyramid, I thought I’d talk more about the methods one can use to produce the information that would be used to create the deliverables mentioned in it.
I am an anthropologist first and foremost, so being able to use my anthropological methods in user research is important to me. This particular method uses journaling as a means to gain insights into what the user actually does in the system by having the user document what they do when they do it rather than trying to run them through various fabricated scenarios that we as designers might come up with. This allows us to really see the application (this could be software, games, mobile apps etc.) from their perspective rather than trying to force our perspective on them.
As a part of this process, we ask the user to not only document what they are doing, but also to provide screen shots and any other collateral that might be of note (such as information about another site that may do what they want in a better way).
With the information gathered in the journaling portion of the study, we are then able to provide the users with access to new tools or scenarios we are working on that they may be interested in using. This way we get better feedback as these are parts of the system these particular users actually use.
This research then allows for the segmentation of the user base not only by the type of user they are, but also by the way they use the system and the parts of the application they use the most. All of which provides ample information for personas, concepts, process flows, story boards, and wireframes.
Every now and then my work bleeds over into my blog here and this is one of those such occasions.
I was recently tasked with creating a slide deck to help spotlight all of the things that User Experience (UX) Design could do above and beyond wireframes. As a part of that process, I collapsed a previous slide deck I had crafted about 5 years ago into a single infographic. Though it is a stacked pyramid, it should be thought of more of a cycle. The pyramid was built to illustrate how giving a user experience design a solid foundation would help inform the experience throughout the entire design process, which starts well before any boxes and arrows are placed on a screen. Once you get to the top of the pyramid, the analysis of the design should feed back into the discovery process and reinform the strategy for improvements.
This is hardly news for most of us, however, I always enjoy a simple, concise, and useful infographic – so I thought others might as well. Please feel free to share and iterate on this. I always appreciate the feedback.
I have worked from multiple parts of the world with people from all over the world, but this is the first time I’ve been sequestered to a single place with a single in person contact for multiple days on end. Here’s a bit of what it has been like to go from being some what of a highly motivated social butterfly both online and in person to someone who fell into social isolation and un-motivation before I even realized it and what I did about it.
When my husband was assigned to Fort Bliss in El Paso Texas, I was excited because that meant we could actually live together and I could still keep up with things like work and school. The company I work for gave me the opportunity to work remote and I was able to fill my semester with all online classes. We then traded in my sports car for an SUV and headed off to West Texas.
After a month of spotty internet connections from the hotel we were staying in, the Starbucks down the street, and the public wifi on base, I was ever so thankful to finally get setup in our home off base. What I didn’t realize is that I would for 6 out of 7 days have only 1 person I would physically see and converse with now that I was at home. While I’m ever so happy this person is my husband, and after a year of him being in a foreign country I am definitely not complaining, I had no idea the effects this would have on my psyche.
What I have learned is that it’s not just about the fact that I am home alone all day. No, it’s also the fact that even if I wanted to leave I do not have the option to do so. You see, we opted to have a single vehicle because well it was cheaper and I didn’t have to drive to work. So, though it made sense at the time, I now see the error of my ways. This situation has set me up with the overwhelming feeling of being trapped in my own house!
After two and a half months of this (July, August, September), I found myself feeling more and more down, uninspired, and completely unmotivated. What was more alarming was I found that after the 3 to 5 days a month I spent in Dallas in the office and on campus I’d come home feeling renewed and refreshed only to have it all drain out of me within a day or two. For those who know me, this is the very opposite of who I am. I generally have so many projects going I don’t know what to do with myself! To go from that to having absolutely no interest in anything was a giant red flag for me.
I tried many tips and tricks including:
Getting up and dressed for work even if you’re not leaving the house
Having a specific room in the house where work is conducted
Taking the occasional afternoon out where I worked on base until my husband got off
Unfortunately, none of these seemed to make a difference. I had to find a way to fix this or it was going to drive me crazy, and not in the figurative sense. To that end, I started running. Yes, running. I don’t know what it is, whether it is just getting out of the house farther than the few streets I normally go to walk my dogs or the resulting endorphins in my head – but it seems to be working. It helps now that it’s cooler outside so I’m not killing myself in the Texas heat. It’s also nice because it’s something physical and I completely leave all of my work and school work and RA work behind to just have a bit of time to myself, for myself.
Being the self-competitive person I am, it’s also turned into a bit of a game of going further, faster, longer. Though I love my computers and I love being online, sometimes you just have to step away from it all to get some perspective. This taught me something else as well, I need time away from work. Working from home means for most people, myself included, more hours and more varied work times.
I found myself finishing something Sunday night that I could have had completed the Friday before had I just had it in me to do it. Now I turn off my work email and chat at 5pm. My work day is done and it doesn’t start again until 8am. This means I HAVE to get my work done during the hours allotted. I get even more motivated when I spend my lunch hour running as that means I can’t do work during lunch time either! (Which I was guilty of doing while I was in the office all the time.)
This change in my schedule also meant I had to tell my boss, no I cannot work on that tonight – giving me time to set aside specific hours to work on school work as well. Funny enough, this in turn gave me more time to do things I enjoy doing outside of work and school like gaming! Putting exercise and more structure in my day was a brilliant way for me to get out of my funk.
Last week, not only did I run every day (2.5 miles), but I also took 3 quizzes, 1 test, participated in class discussions, conducted a bit of heuristic evaluation for my research assistanceship as well as completing all of my office work before the weekend. In addition to all of that, I also got a lot of work done for my wedding (yes, I’m already married – but we didn’t have a wedding as we go married at the US Embassy in Seoul, South Korea). This included designing and ordering save the dates and proper invitations as well as getting a photographer, a cake baker, a DJ and working with all of my bride’s maids to get their dresses ordered. This also meant that I actually got to play video games last weekend as I actually had free time for once.
So, there you have it. Now I actually get to take advantage of some of the freedoms granted to me by working from home even if I don’t have a vehicle and only see a single person in person 6 out of 7 days a week. All it took was a little organization and thinking outside of my computer screen.
My next couple of posts will go into some of the interesting things I’ve experienced in online gaming as of last as well as how I am using a Facebook group to organize my wedding. This is just my way of getting back into writing something at least a little relevant here. My hope is that someone gets some use out of this. If nothing else – this place will not look as dormant as it has of late.
So, I know this has been a widely written about topic from multiple sides of the equation. I have to say though, if there is one thing I’ve learned from Agile – and from Organization Behavior in general – there is no “one best way” to do anything. That said, I’ll give a short explanation of our version of Agile, what I do, and how I work within our Agile environment as a UXD.
Let’s talk about Agile:
Agile is defined as iterative incremental development methodology. What? This means the product we are working on has new features and bug fixes released, in our case, every two weeks. Everyone involved in the process works together within those two weeks to make it happen from graphic designers to quality assurance testers. This is different from waterfall where the discovery, architecture, development, design, testing, and release phases are all very separate from each other, happen in a specific order, and in the end the product is “final”.
While that may not sound revolutionary by any means, people moving from waterfall to agile tend to have a rough start. Biggest reason why? Things change, nothing is solid, it’s not final, and the team needs to be agile enough to roll with the punches. Let’s put it this way, I haven’t seen a statement of work or product requirements grid for nearly 4 years and I’ve never been finished with a project.
That brings us to the next part. What is it that I do?
User Experience Design:
Well, my official title is User Experience Designer (UXD). In short, I design user experiences.
So, what is a user experience? A user experience is what the user sees, feels, hears, touches, uses, understands, believes, and comes away from any application with. This means I’m a bit of a business analyst, information architect, interaction designer, art director, user researcher, usability expert, heuristic reviewer, and decipherer of languages of developers and business processes past.
But, what do I actually do? My main function is to do all of the above to create wireframes and application requirements from which developers take direction and create an application. Then I go through continuous reviews and revisions throughout the development cycle with the developers where we have to make changes and compromises due to time, resources, and hardware / software (API) restrictions that do not surface until we are already neck deep in the iteration. During that process I’m researching features for the next release and working those into wireframes which include processes and interactions that are then translated into stories. Let’s just say where people normally have peaks and valleys in their work, my work tends to run at a constantly high level.
Our Agile Process:
The other part of the Agile process is the use of stories and tasks by the developers which help direct how they spend their time and what they spend their time on for each iteration. A story is basically the development requirements for each piece of development occurring during an iteration. Each story has a set of tasks and subtasks that developers then divvy amongst themselves. Each story / task / subtask has an amount of time the developer thinks it will take to do, then as they work they report against it the actual amount of time it took. This gives us an idea from iteration to iteration what can be accomplished by the team given the tasks at hand. This helps for planning and keeping the team on task.
Our original process included a meeting to come up with the stories based on the wireframes for the devs to follow. This meeting was important because the stories had to be understood by the developers and had to capture all of the specific dev particulars that a wireframe doesn’t necessarily convey. After that meeting there were meetings to decide tasks, subtasks, and time allotted for each.
Getting Agile with Agile:
During the last two iterations we’ve change it up a bit where I wrote out the stories while I was doing the wireframes and we now use the story meeting as a brainstorming meeting for the devs. This was an important change which allows the developers time to actually collaborate together on the thinking part of development rather than just banging away on their separate pieces of code. It also makes the meeting less mind numbing and monotonous as they actually get to throw ideas out there and bounce concepts off of each other whereas before they had no time to do so. While there are specific Agile processes, we go with what works and the best part about that is it allows us to be agile with it.
There you go! Not the most earth shattering ideas or methods out there, but I think it’s always nice to document what works and to share what you can when you can.