The Ubiquitous UX
Pleasant Charles
Table of contents
0. A newcomer's restless ramblings.
1. What is UX?: knowledge reuse (collecting already-defined content).
2. UX application process: cases already used at professional UX firms.
3. Utilization process (1/2): custom UX.
4. Utilization process (2/2): after UX.
[ Applying the UX design process in the real world ]
http://openux.co.kr/open_blog/5629
1) What is the starting point of the project?
In the existing project process, what was the starting point?
— Did projects start with a function list derived from benchmarking competitors, or with a function list suddenly decided by someone (usually a decision-maker or planner)?
— Maybe you're making a service just to "make something" (to show a result, or because making things is your job)?
— Have you forgotten that we make services for users?
Every service is made to be used by someone. Those someones are the users. Isn't it natural that "worrying about what the users want" should be the starting point of the project for a service made for users? Keep in mind: we are never the "users," and we cannot become similar to the "users" we target. "Worrying about users" is not optional — it is a precious jewel we have been forgetting and losing.
2) Was the UX work process considered when estimating the schedule at the project's start?
When estimating the schedule from the beginning, did you consider the UX work process? Or did you already lay out the schedule along your existing process and then try to stuff "users are important" into it because it suddenly came to mind? Any stage, when inserted later, looks schedule-lengthening and unnecessary. Think about this: before front-end development (HTML markup, Ajax/Flash scripting, etc.) was separated from development, you could just lump it all together as "development." (Of course, there was a detailed WBS inside "development.") If you didn't plan front-end separately and later had to budget time for it, it was natural to wonder, "can't we shrink this?"
3) Have you ever considered the headcount cost and time for service improvement after launch?
Most companies or project teams, when starting a new project, tend not to consider at all the headcount cost and time for service improvement that arises after launch. Even during operation, these costs are often ignored. All the personnel costs and time of a company are the company's resources. (Do we blow through them because it's "not our money"? ^^;) Even if it takes a few weeks longer than the existing process, understanding users well the first time and making the service well costs far less than launching and then reworking or tearing up the service direction.
Our users are no longer the kind who simply "feel grateful that the service exists and stay loyal to it." Every day the world is flooded with Me Too services and services with new concepts. Language barriers are falling, and yesterday's US-oriented service can shift into a Korean-oriented one today to enter the local market. If you can't appeal in one solid shot, you may remain in competitors' shadow forever until the service closes.
Considering the UX work process
vs. improvements after launch
Time needed for UX work — roughly 2–4 weeks (varies by project).
Time needed for revision or redevelopment:
— Planning: revising the service direction.
— Design: rework due to the direction change.
— Development: if it's only a UI issue, good; but sometimes the system structure itself must change.
Personnel cost: UX staff cost — roughly 0.5~1 M/M (varies by project). Planning, design, and development staff cost. Can target brand/service user needs. Can miss the chance to appeal to users.
[ UX work process ]
http://blog.naver.com/ssoowoo/50045943787
1. Service definition — Deliverable: a service concept expressed in one sentence.
In the original service-development process, steps like market and user research lead to positioning maps vs. competitors or top-level strategy. But in most cases, top-level strategy is done by marketing or planning, so it's often not included in the UX work process. Often the service concept gets defined sprawlingly — "we do this, and this, and..." — and this planning document needs tidying up.
As the cornerstone for making a user-centered service, the concept must be very concise and clear. Avoid concepts like "a service that will beat the competition" or "the world's first XXX service." Describe a concept in terms of clear utility from the user's side, and strongly try writing the concept as a single sentence. (Please don't build a sprawling sentence with "-hago," "-haneun," and so on to glue many sentences into one... please -_-;;) If it cannot be concisely written in a single sentence, the service's direction is unclear or there is no direction.
E.g., Traffic-information search service: based on geographic data, provides traffic information drivers need while driving.
2. User definition — Deliverable: user-group definition and priority among user groups. Usable methodologies: User Profile, Persona, User Research, Literature Review.
This step defines the users to whom the service concept provides utility. If there is existing user-related data for this or a similar service, use it. If you have Persona or User Profile data, great — pick the user group that will consume the service's utility. If you have no data, you can run user research. Use the research to build user types.
If time and cost don't allow (which is often the case), you can look at competitors or similar services. The so-called Bench marking or Competitor Analysis. The caution: your main purpose is to understand direction and target users through others' features, feature combinations, and content — not to copy competitors' features.
You can also infer probable users from academic materials or statistical data — Literature Review. These days, most materials can be found online. ^^; Using specialized databases like ACM Digital Library is another way.
Once you have data, define the user groups. The important thing is to give each group a "name" that represents its characteristics. For a Q&A service (like Knowledge-iN), here are sample user types:
1) Asker: user who asks about their own curiosities.
2) Answerer: user who answers using their own knowledge or references.
3) Information relayer: user who can't directly answer but has search skill and relays related info by clipping.
4) Information consumer: user who neither asks nor answers but merely consumes Q&A.
You can segment further — e.g., "questioners about daily life," "academic questioners." How finely you segment, or what level to match between types, depends on the service.
If you have Persona or User Profile, you already have concrete user-types and can use them as-is or with small edits.
Caution! Never segment users by demographics like "male college student in their 20s." Define types by user needs or service-usage purpose.
Caution! Defining users with "there will probably be this kind of user" after defining the concept is very dangerous. You need concrete grounds for why you defined them this way. If you find no materials, look closely at competitor services to see what user needs exist. By combining those needs, you can derive a handful of user groups.
Once user types are defined, from the service-provider side, define the priority among user types to activate the service. A good method is to assign each a percentage summing to 100%.
3. User needs definition — Deliverable: user-requirement list. Usable methodologies: User Profile, Persona, User Research, Literature Review.
Honestly, the line between this and "2. User definition" is fuzzy. You could derive needs first, then define users, then reorganize needs. The priority of user types naturally determines the priority of requirements. A requirement list includes: "whose requirement is it?", "what is the requirement?", and "how important is it?"
4. Function definition — Deliverable: Feature List.
Think about solutions for the requirements organized above. Organizing these yields the function list. Sometimes one function satisfies two or more requirements; sometimes two or more functions must combine to satisfy one. The most important thing in defining the function list is to exclude "Nice-to-have features" as much as possible. Satisfy the requirements with the minimum set of features. A good method: first write every feature that seems needed, then delete features one by one based on inclusion relationships. Function list contains: "which requirement is this for?", "what is the function?", "how important is it?"
Caution! "Function list" is not only "Function." It can contain Content or Relationship too. Think of it as "anything that can solve the requirement." Broadly, "information that can solve the requirement."
Caution! Do NOT think about service Features before reaching this stage! The moment you start thinking "I'll add this feature," the service begins to warp toward adding that feature. A Feature is just one way to solve a user need. Don't forget: you can solve the same need with endlessly different Features.
Tip! Related departments often want to pack in as many features as possible, or insist on specific ones based on their interests. In those cases, proposing "that feature can be defined into the next development scope" is useful. It effectively means "Spec Out" — but at a meeting it's a polite way to remove a feature without damaging the other side's feelings.
5. Information-architecture definition — Deliverable: Information Architecture, Sitepath Diagram.
Based on the defined functions, draw the information architecture. For services where user-to-user relationships or interactions matter (e.g., SNS), a Sitepath Diagram is useful. With a Sitepath Diagram you can define the relationships among user types required for the service to run intact.
The key when drawing the IA is to view the service as a whole and clearly define the relationships among functions, or concretize the hierarchy among them.
* Sitepath Diagram: simply put, expressing the Actions among users in a single picture. Similar in concept to UML or Flow Chart — the key is that interactions across various user types must be expressed in one picture. This concept is well explained in "Information Architecture: Blueprint for the Web."
Caution! A site map is one kind of information architecture. A site map can show function hierarchy but not the relationships among functions. The deliverable at this stage is IA, not a site map. Don't confuse them. You can use a drawing tool like MindManager.
6. Basic screen design — Deliverable: Wireframe.
Based on the IA, enumerate the pages that must be shown to users. Derive the elements that should appear on each page from the IA. See this as projecting the IA onto pages. Not every information unit in the IA becomes its own page — two or more info units may share a page, or one info unit may appear across pages.
Even if you plan to use Rich Interaction, it's best to first define the needed pages and then merge or split pages. Once pages are defined, define UI units (also called Widget, Component, Pattern) for how information should be displayed. For example, a "search results" page needs UI units like "search field and button," "search result list," and "related information." After defining UI units, place them on the page considering the user's Task Flow. At this point, use the priorities defined in "4. Function definition" to weigh the UI units' relative size and position.
7. Interaction design — Deliverable: Interaction Design Document, Prototype. Usable references: Design Patterns, Rich Interaction Design Patterns.
Use the defined screens and UI units to define interactions. You can say "pressing button A sends data 1 to the server and switches to button B," or you can document screen-design screens for each detail step. Consider not only UI-unit interactions but also inter-user-type interactions.
If you use Rich Interaction, besides the Happy Path (the way the provider wants the task to succeed without errors in one go), you must also define Alternative Paths (different methods/routes to success) and Error Paths.
* Up to here is the most common UX-organization work process. Later steps depend on each organization's and project's characteristics and involve collaboration with related departments.
8. Visual design — Deliverable: Graphic Files (design team).
Usually the visual-design department or designer starts work from this stage. But depending on the service's media or attributes, the UX org can take a more organic part. Examples:
1) A service with a new kind of media concept: IPTV, iPhone applications — anything that must have a consistent UI or Interaction Style — where the UX org can guide the design team.
2) Info-based services: when the purpose is clearly to deliver info, the UX org can even define how to arrange info — how many characters, how many lines to show. But while you can suggest whether an icon or text link is appropriate, or what metaphor an icon should carry, defining an icon button's color or style may overreach. Of course, giving a color guide for readability is fine.
9. Development — Deliverable: Product (development team).
You can offer some opinion on development style.
10. QA — Usable references: Interaction Path.
If you precisely defined Happy, Alternative, and Error Paths in "7. Interaction design," hand these to the QA team to help their work.
* The steps below are easy for juniors to overlook. A service launching does not mean the project is finished. What I always stress to new hires is: "Until the service closes, the project is not over." The UX org may not own the service, but to keep improving the service from the user's side you need love and endless interest in it.
11. Service launch — Usable methodologies: Web Analytics / User Research.
Once the service launches, understanding user responses matters. We may have thought A was important, but users may think B is. We may have thought Solution 1 was easiest to understand, but users may still find it hard. After launch and a stabilization period, run user research. Observe how people actually use it. Users also struggle to give opinions on things that aren't visible (not concretized), but once a service launches, they tend to give many opinions.
Apple is famously not a user-research organization — but that refers to not doing user research at the concept stage about "what do users want." Apple is also famous for running many research sessions that gather user opinion via prototyping during development. (They're the kind of organization that researches users by constant observation of their daily lives, producing and verifying hypotheses about what they want.)
For online services, log-data analysis is easy to apply. Besides the basic server logs, consider data accumulation using JavaScript tags. If user research is an in-depth qualitative study, log-data analysis is a quantitative study that generalizes easily.
* Tip! Google Analytics is still free. Even its basic features cover most of what you want to extract from log data. If budget allows, consider various paid solutions too.
12. Service improvement — Deliverable: Revision History Document.
Many factors affect a service's usage rate. Competitors may collapse and users flood to your service; seasonal events (Valentine's, school opening) or disasters (earthquake, typhoon) may spike or crash usage. Keep a habit of noting these events for later analysis. An event calendar is especially useful for log-data analysis: when there's a big traffic shift, log data alone may not explain external factors.
Services are constantly improved, but sometimes you get a "funny renewal" — you end up reverting to a previous UI to "improve" the improved UI. Whenever you improve, document: "why did we improve? what was the problem?", "what's the solution?", "who was the decision-maker?" Build an archive of screenshots with each improvement too.
The process above is what I consider the most basic. It may be hard to apply depending on an organization's characteristics. But if we want a service users love, a good service, isn't it worth trying? Also, the above is not a Waterfall model — each stage runs Iteratively. Design processes originally have continuous iteration in each stage, and recent development processes also push fast with frequent iteration.
[Source] "UX Work Process for Juniors" | Author: Tony
Additional references
A few notes on UX: blog.naver.com/ssoowoo/50045943787
Contributing to UX design in open-source projects: http://blog.naver.com/ssoowoo/50045943787
Definition, scope, and misconceptions of user experience: http://alankang.tistory.com/235
UX-design process cases: http://tranbot.net/UXMyth/31_ux-design-is-a-step-in-a-project/
Collection of UX-related diagrams: http://kangcd.blogspot.kr/2009/11/ux...
agile UX, fast usability test service-design: http://blog.naver.com/tag2010?Redirect=Log&logNo=60140067936
Service scenario: http://blog.naver.com/seashinvi?Redirect=Log&logNo=130129166395
