If you build a truly great community, it becomes a self-fulfilling prophecy. I’m proud to say that the UX Mastery community is panning out to be one of the truly great ones, and here is an example of why.

Just over a month ago, a new member who goes by the name of Noquarter signed up. He had an idea, and in doing so, he became one of my favourite community members of all time.

I have an idea. I want to redo my portfolio and I thought this would be a good opportunity to use you guys as my team.

In essence, Noquarter’s idea was to run a UX project that involved the UX Mastery Community as collaborative team members. The project? To create a great UX portfolio for himself. In Luke’s words “UX work experience FTW!”

Stage 1: Strategy – Project: Portfolio – Kickoff meeting

We began with a planning meeting. Using a 1000-foot document we established the structure of the project by answering these questions:

1. What are we hoping to achieve?
2. How will we measure success?
3. Who is the audience?
4. Who are the SME’s?
5. What personas should we use?
6. Who are the stakeholders?
7. Do we have a copywriter?
8. Who can help facilitate user testing?
9. What is the scope of the project?

Stage 2: Research – Project: Portfolio

Once we had established some clear goals and key responsibilities, we moved onto the research stage. This meant creating some personas (in this case modelled on UX recruiters and HR personnel), conducting stakeholder and user interviews, and competitive analysis.

Noquarter surveyed a group of UX recruiters and came back with some useful data, along with some people willing to be interviewed over Skype. Competitive research was conducted using data that I had collected for an article that I wrote last year.

At this stage our 1000-foot document looked like this.

Stage 3: User Testing – Project: Portfolio

This is where we’re at. We need to begin by writing a usability testing script, which will be used to conduct a dry-run test on project collaborators. We’ll then use feedback from the team to tweak it for user testing with the recruiter volunteers established in Stage 2.

Would you like to be a part of our project?

In my opinion, this use of the community is genius. Noquarter is getting experience in following a user-centred process, he’s providing opportunities for all members to collaborate and learn from each other, and obviously the final result is a slick new portfolio for Noquarter. Win/win/win!

As a result, we would love to have more people join in. This is a unique opportunity to be involved in a project with a group of UX professionals who have a wealth of different backgrounds and experiences. Even better … it’s fun.

If you would like to take part, you can join our community here and get stuck in here.

We’re looking forward to seeing you.

The post A Collaborative UX Project: The Power of Community appeared first on UX Mastery.

Most website projects have inherited a traditional model of the software development process, typically something like:

1. Understand – The designer talks with the business owners to find out what they want and get an understanding of the product
2. Feature wishlist – The designer keeps a feature wishlist and starts putting together visual designs that reflect this
3. Build – The product is built
4. Give to users – A version of the product is launched and made available to the users
5. Collect feedback – The designer and/or the business owner get feedback about the product, perhaps adding some user tracking or analytics.
   

Funnily enough, if we tip that list upside down we get a process that much more effectively considers the needs and wants of the users:

1. Collect feedback – The designer talks with users to get feedback and learn about what their needs and contexts are, and might set up some web analytics to record what people are doing.
2. Give to users – Design sketches or existing products (perhaps even a competitor’s product) are shown to the users to see what works and what doesn’t
3. Build – Learnings from this research and testing help inform the way the product is built
4. Feature wishlist – By the end of an iterative process a clear understanding of the features is known
5. Understand – The designer and business owner now have a strong understanding of the product and its users that can be built on into the future

It is easy to see that the main differences are in the assumptions made at the beginning of the process and in how this colours the remaining activities. The two important things to understand from this are:

• Without a user-centred approach we rely heavily on the business owners knowing most of the answers before the project even begins.
• With a user-centred design process we have the ability to learn things early and make changes to correct the course of the project.

Defining factors

A user-centred design (UCD) process has the following characteristics:

1. The philosophy is to design the product to fit the users, not to force the users to change their behaviour to accommodate the product.
2. The needs, wants and limitations of real end users of a product are given extensive attention at each stage of the design process.
3. It’s a design process – it identifies and solves problems, and does this by paying attention to the ‘needs’ rather than just the ‘wants’. It is objective rather than subjective – the researchers, designers, developers (and even the users) don’t necessarily get to pick their favourite colours.
4. Users are consulted from the start (so designers can analyse and foresee how users are likely to use a product), considered during development (by testing the validity of design assumptions about user behaviour by conducting real-world tests) and the product is validated at the end by testing.
5. It is multi-stage and almost always iterative.

A popular alternative method for software development is Agile, and the lightweight, iterative nature of an agile software development method marries very nicely to our UCD process. There are some great strategies UXers can use to contribute effectively in an Agile team, balance some weaknesses in Agile methods (for those who have some concerns about its approach), and produce a more robust process and more successful designs.

If you’re a UXer who is new to agile methods, a book that explains well the mindset for user-centred design projects is Hugh Beyer’s User Centred Agile Methodologies.

We’ll be talking in more detail about user-centred design in our next few posts. Keep your eyes peeled!

Have you ever wondered how you’re expected to quote upfront for a large, unknown web project?

This post has been translated to Croatian.

The post Why Web Design Projects Shouldn’t Be Treated Like Software Development appeared first on UX Mastery.

Web industry professionals have mostly moved beyond labelling themselves as ‘web designers’ and the importance of a good user experience has been popularised in part by the Apple design aesthetic and other interface and gadget makers. There is a growing awareness that usability is important as the web matures, and staff are being added to design teams with the specific purpose of taking responsibility for user-friendliness and for setting a broader vision for how users might experience a product or service. But can UX be considered a job description? Or is it more of a process and set of design responsibilities? Why do these questions even matter?

In trying to pin down a comprehensive title for UX people have suggested names like Information Architect, User Experience Architect, Interface Designer, Interaction Designer, Usability Specialist, User Researcher or UX Professional. In the bigger or more specialised teams these may each have become specific roles, but the one title that seems to have stuck for smaller teams and freelancers is User Experience Designer.

1) It’s an impossible title, but that’s not important

“We don’t design a good experience, we design for a good user experience.”

When the title User Experience Designer began getting popular people questioned its validity by pointing out that you can’t actually design an experience. There are some good (albeit very semantic) reasons why that is true (Helge Fredheim articulated them well in his article Why User Experience Cannot Be Designed). However, a popular response countering this is that most UX designers don’t think they literally design every user’s exact experience – they just think about and practice designing for UX in particular.

2) The experience of a product or service is more likely to be affected by how it is designed than who designed it

By using a pseudo-scientific method and allowing the whole design team to respond to insights from real users the end result has far more likelihood of succeeding than if a single person in the team was charged with the care of UX responsibilities. A user-centred approach needs to be incorporated throughout a project’s strategy, design and development for it to be most effective, but that’s a UCD process, not necessarily a UX one.

3) A UX practitioner performs best within a collaborative environment

Collaboration may be with users, project stakeholders, designers or developers and to some extent these people therefore also perform UX tasks as part of their own roles. How can UX be called a separate role if all of these people also participate in user research and workshops, produce sketches and concepts, test them with users, apply usability best-practices or document features and requirements? Doesn’t that make everyone a UXer?

4) Users still need a champion for their needs during design

Although UX may be part of the team’s shared responsibility, there still needs to be an appointed ‘champion’ – someone to go into battle for them when it counts. The early stages of a web or mobile app project may be mostly driven by business strategy and marketing requirements. The design stages may better recognize the value of aesthetics, but could still struggle with remaining objective when responding to the brief. And developers may not necessarily solve code and interpret problems in line with the needs they’re building for, despite doing well with requirements. With understandable competing pressures, these different roles may assume they already know what is best for the user within their sphere of expertise. However, even when all of these roles participate in a user-centred design process it is still important to have someone managing the user experience across the project, and perhaps beyond – touching on other aspects of the user’s experience with the organization such as customer support, accounts or logistics.

5) UX is multi-disciplinary

People generally associate a UX professional with specific tasks such as interviewing users, producing wireframes or making usability recommendations. This suggests that UX is a particular role within a team. However, many jobs that may in essence be aligned with UX are advertised with different titles: business analyst, account coordinator, front-end developer, web-interface designer, product manager. In the same manner, UXers often come from diverse backgrounds in management, content, design and technology. UX covers a range of skills and perspectives and can borrow from an even wider range of disciplines.

6) There are multiple processes used by UX designers, and no single process fits everyone

All designers, projects, or even design teams and businesses have a preferred way of implementing a project. The nature of client/agency enagagement also differs fundamentally from how an in-house design team may work, so it’s not easy to define a UX process that works across the board. However UX does have a set of principles, and can be applied within, or to complement, many existing processes and frameworks such as Agile, UCD, waterfall, lean software development. If the core ideas of user input and iterative design are included, that goes a long way to being called a UX process.

*          *          *

Asking whether UX design is a role or a process is important because it helps us identify what we should be doing when we apply UX to a project, or as part of a team we’re working in. It also helps us articulate to others what it is that we UXers are doing.

On balance, we can see that UX needs a holistic approach and does best when embedded within a user-centred design team.In these cases UX might add to an existing process, and help drive collaboration throughout a project and even into the organisation itself. It’s not an isolated role, but a responsibility that needs to be held by everyone involved on a project. And yet the core skills aren’t necessarily an assumed competency of interface designers, front or back-end developers or project/product managers.

Depending on who can already do what, and the nature of each project, a team may be looking for very different skill sets in their UXer. They’ll still be looking for guidance, a high view of the user experience and a passion for championing the user’s perspective.

How do you describe your role, and how does this reflect the process you use? We’d love to hear what you think – please leave us a quick comment!

The post Is UX Design a Role or a Process? appeared first on UX Mastery.