Makoto Kern, Houston Texas UX Designer

Rachel Andrew on the Business of Web Dev: It’s the People They Know

Posted by The fine folks at A List Apart |03 Dec 15 |

I was never supposed to be doing the job that I do. Via a series of fortunate events and chance encounters, I’ve built a career in an industry I that love and that still interests me today.

When I was at school, the web didn’t exist. Like many web folk of my age I stumbled into my career of the past 19 years accidentally. I might never have discovered this career had a PC World salesperson not upsold me to a computer on interest-free credit. It was 1996, and my aim was to get a word processor so I could take in typing work while pregnant and taking care of my baby. The computer enabled me to earn money typing while it opened up for me this new world of the web. My journey from new computer owner to web developer is a story for another day, but that salesperson will never know what he started by making his targets that day!

It was by chance that I came to have access to the web at all, and I might have remained someone who liked to play around with computers, who built websites for fun, had it not been for people who asked me to build websites for them.

My first paid work as a web developer came via friends of friends who needed websites. I would talk about the things I had been teaching myself. I had my own site online and a couple of sites I had volunteered to build for charities I was involved with. One by one, little jobs arrived, always because someone had mentioned to a friend of mine that they needed a website. All the things I learned building those small sites—learning Perl to add functionality, learning Linux so I could install a web server locally—enabled me to find a full-time job, and then leave again to set up on my own.

My husband and business partner Drew McLellan has similar stories. The first website he was paid to create came about while volunteering at the local amateur dramatics society. He met someone who was setting up a new business and needed a website. He was someone who she trusted who built websites.

I asked some fellow freelancers if anyone else had these stories of chance, or of the unusual ways we find work or contacts who are instrumental in our business success. Andrew Areoff had already written up a tale that spanned over 40 years, documenting how a man from Rhodesia is connected to the success of his business and that of his best client. Harry Llewelyn of Neat in Somerset, UK, told me how he made a friend in the USA via posting photography on Flickr. While staying with this friend he was introduced to another friend—a web designer who ultimately outsourced front-end work to Harry, bringing enough regular work for him to make the leap into full-time self-employment.

Jonathan Rawlins of Pixel Pixel Ltd had a story of how a Christmas Eve flood at home resulted in a painter and decorator being in the house while he was working from home. They chatted and Jonathan explained what he did, and discussed setting up a simple site for the decorator’s business. The site for the decorating business never materialized, but the two stayed in touch. Around two years later the decorator got back in touch about an idea for a much larger project. Jonathan is now working on this project in stages—helping to grow the application as the business grows.

Another freelancer had a lovely story of how a project he was working on with a friend failed due to the friend having personal issues and needing to get his life back on track. Despite the failed project, he supported his friend, who then introduced him to another contact. That contact has become a great client, and also brought interesting new possibilities.

There are common themes in all of these stories of chance and opportunity. They show that it is always worth talking about what it is that you do, even if the person you are speaking with doesn’t look like an obvious fit as a client. You then need to be ready to follow up leads that come from an unusual source. Even more than that, opportunity often comes to those who are willing to give freely. That giving might be in terms of your skills as a designer or developer, but might be in doing something else entirely. It might even be in terms of being supportive of a business partner or client when things don’t work out.

One thing I know for sure is that the more generous I am with my time and my knowledge, the more good fortune seems to come my way. This isn’t due to any mysterious karma at play, but simply that people talk to one another. As one of my contributors to this piece wisely pointed out, “it’s not the people you know, it’s the people they know!”

How to Create Successful Mobile Experiences

Posted by Alex Asianov |03 Dec 15 |

December 3, 2015

The key to creating successful and user-friendly mobile experiences is empathy. Not the mushy kind, but the pragmatic kind of empathy in which you put yourself in the user’s shoes and try to really understand their needs and wants.

An easy shorthand is to factor these wants and needs based on the questions familiar to journalism students: who, what, why, when, where, and how.

Who

Who is your target user? Basic user demographics like age and gender are a must, but try to go beyond that— think about their desires, ambitions, obstacles, and pet peeves.  Creating user personas for each of your expected types of users can help answer this question and design a better mobile experience.

What

What does your target user need or want that they cannot currently get at all or get easily? What are you considering to offer via mobile experiences to give the user what they want? Whatever…read more
By Alex Asianov

How to Create Successful Mobile Experiences

Posted by Alex Asianov |03 Dec 15 |

December 3, 2015

The key to creating successful and user-friendly mobile experiences is empathy. Not the mushy kind, but the pragmatic kind of empathy in which you put yourself in the user’s shoes and try to really understand their needs and wants.

An easy shorthand is to factor these wants and needs based on the questions familiar to journalism students: who, what, why, when, where, and how.

Who

Who is your target user? Basic user demographics like age and gender are a must, but try to go beyond that— think about their desires, ambitions, obstacles, and pet peeves.  Creating user personas for each of your expected types of users can help answer this question and design a better mobile experience.

What

What does your target user need or want that they cannot currently get at all or get easily? What are you considering to offer via mobile experiences to give the user what they want? Whatever…read more
By Alex Asianov

The Age of Information Architecture

Posted by Peter Morville |01 Dec 15 |

Nearly 20 years ago, Peter Morville and Lou Rosenfeld wrote a book on information architecture. Now, Peter returns and reflects upon the impact and evolution of the famous “polar bear” book.

The post The Age of Information Architecture appeared first on UX Booth.

The Age of Information Architecture

Posted by Peter Morville |01 Dec 15 |

Nearly 20 years ago, Peter Morville and Lou Rosenfeld wrote a book on information architecture. Now, Peter returns and reflects upon the impact and evolution of the famous “polar bear” book.

The post The Age of Information Architecture appeared first on UX Booth.

Planning and Organizing Workshops

Posted by The fine folks at A List Apart |01 Dec 15 |

To be successful, workshops need to be planned carefully and explained clearly. Good workshops start long before you get people together in a room. They start with a list of goals, an agenda, and clear communication to the attendees. While this does not guarantee success, it does set a solid foundation for how you want things to run. It also provides a framework for the tasks and activities you use in the workshop, but we will take a look at that in another post.

Setting workshop goals

Let’s start at the beginning. Someone in your organization, whether it’s you or another leader, has identified the need for a workshop or session with the team. This is most likely in response to a perceived lack of skills, lack of direction, or the need to form consensus around a decision. Pinpointing a problem is always an excellent first step, and lets you define some high-level goals.

Start by writing down some general ideas of what you want to achieve. I usually end up with a list of five to seven goals, all related to the team need. Then that gets whittled down to two or three sentences. I state them like this, to help guide me as I create the rest of the workshop:

At the end of this workshop:

  • Attendees will be able to define, plan and conduct UX research on a new product feature.
  • Attendees will have decided on a set of research questions, so they can gather user feedback.
  • Attendees will have demonstrated the power of UX research planning to the organization.

Creating an agenda

Your workshop agenda should, in every way, support the goals you stated. Every agenda should have an intro and a wrap-up. Depending on your goals, sometimes a Q&A session at the end is necessary. If a goal was to train your coworkers on a new system or strategy, then questions and answers fit perfectly. However, when the goals of your workshop are to generate or refine new design ideas, a Q&A at the end would not contribute much.

I also make sure to define, down to five-minute blocks, how long each section of the workshop will take. This is key. The relative amount of time spent on each task tells attendees exactly how important it is to the topic at hand. 10 minutes spent brainstorming ideas and 30 minutes spent critiquing them says something very specific about your team’s skills and needs—that they need practice generating ideas quickly and then analyzing them for a longer period.

Here’s a sample 90-minute agenda for a workshop for a team of designers who need to learn how to scope and deliver user-experience research. The tasks are loosely based on Chapter 3 of Just Enough Research:

Intro (5 minutes)
Task A: defining the Research Problem (15 minutes)
Task B: selecting a Style of UX Research to Conduct (20 minutes)
Break (10 minutes)
Task C: conducting the Research (20 minutes)
Task D: collecting and Sharing Data (10 minutes)
Wrap-up (10 minutes)

For sessions longer than an hour or two, it’s essential that you plan bathroom and laptop or phone breaks. Although you want attendees to be engaged and “with you” the whole time, life doesn’t stop for anything, and people need time to check in at work. It can also serve as a release valve if there are tensions or disagreements happening in your session. We will talk about how to manage these situations in a later post.

Deciding whom to invite

Each attendee should have a role to play. The goals of your workshop are there to help you. If any attendee will not be able to contribute to achieving them, they don’t need to be invited. Political considerations may trump this, but try to keep your attendee list focused. When it comes to design workshops, there are five possible roles that will show up.

  • Sponsors are the people who have asked you to conduct the workshop, or are on the line politically for the success or failure of it on an organizational level. They will often speak to higher-level concerns and strategy.
  • Stakeholders are the people who have a stake in the results of the workshop—they are most often directors, team leads, or others with responsibility for others. What is learned or decided in the session will be what they need to manage or implement, so they care on an operational level.
  • Participants are team members and attendees who have been invited because of their design, marketing, or even development skills. They will be the ones most often tasked with doing the actual user research, writing the code, and designing the interfaces that come out of the session.
  • Users are those who will be consuming, or interacting regularly with, the final product the workshop seeks to work on. As geography breaks down on the internet, often it’s better to plan separate research sessions focused completely on users, but for some design projects, it can be effective to have them attend. When the workshop goals are about an internal tool or platform, users will be your coworkers.

There will be overlap in these roles, especially with smaller teams. That’s fine. Simply decide which one best defines the attendee’s role during the workshop, and you’ll be okay.

Participation vs. facilitation

One other role I want to mention is the role of the facilitator. A facilitator is not actually an attendee. Facilitators remain impartial, inform attendees of timing and schedule, guide but do not dominate a discussion, and take notes in a way that provides documentation. They listen, coax, and sometimes even redirect attendees in the tasks and discussions that arise. If you cannot play this role, then assign another member of your team to facilitate, and communicate this early and often to the rest of the attendees.

Okay. You’ve now done all the prep work for this workshop. You have some defined goals. You have a list of attendees and the role they each play. You’ve emailed everyone with the schedule, name of the facilitator, and given instructions for the day of the workshop.

Next time, we’ll look at how to run the actual workshop, and how to choose tasks based on your defined goals.