User Experience is a budding discipline. How can we share information the way “view source” allows coders to learn from each other? The rate of innovation was faster because coders can see how a website is put together with little barriers. User Experience encounters obstacles that make learning from each other more difficult.
Issues
Often we can’t get specific about our project details because it’s proprietary. The stuff that we end up looking at is generalized and often too vague to be helpful. User Experience is a broad enough category that we don’t have an agreed upon vocabulary. Access is limited. Unlike the international HTML, user experience is not without language barriers.
Potential Solutions
UXRSS. A multimedia, open protocol forum feed similar to Stack Overflow, complete with wiki excerpts that help define terms, whiteboarding sessions, and video. It’s important to not just have solutions (See The Dribbblisation of Design) but lots of process work too. A formatting system where we can search by root problems, so if we’re having the same problem as someone else, we can learn from their solution as well. And often the solution is more than just some screens. It’s a system. And more, proof that the system works, some well-documented metrics.
UX without Borders. A reference to Doctors Without Borders. It’s where nonprofit agencies can band together in “industry collaboration” and share real projects and insights. Think Data Scientists meets Mozilla. And they would document everything.
UX Community. There are the monocultures of Amazon and Microsoft with their own way of doing things, their own vocabulary. In the future, after their employees leave those companies but take their frameworks with them, may we have an infusion of ideas into the population at large? A set of best practices an professional principals? There will be devoted researchers. There will be a separate set of ethics relating to the corporation and the individuals. Will there be a Hippocratic oath but for UX designers?
UX Leadership. UX has and will have thought leaders. There will be a push in marketing the tasks of user experience as necessary as there was a push for “good design” a hundred years ago during the industrial revolution. The dialog of “good user experience” is beneficial in driving interest in user experience. But, will user experience leadership be centralized like Wikipedia. Or will it be distributed, Amazon, Microsoft and others having their own lingo, standards, etc. like varied dialects?
Eric Bell (ericthebell) talked at InfoCamp 2013 about Hackthons and why they are awesome! Eric Bell is a designer, formerly Seattle-based, currently lives in SF and attends hackathons. During his talk, he showed us some of his team projects at hackathons.
A typical hackathon is a weekend of work, has an attendance of primarily developers. It’s sometimes sponsored by a company interested in promoting their platform or by a local makers chapter. Sometimes there’s a theme, rules and prizes. The work over the weekend sometimes leads to a real product, but other times it’s a great exercise in developing something in a short time.
The reasons to attend one include working with new things, developing new skills, encountering new people and networking with potential employers, and exploring the challenges of a project with tight time restraints. For a user experience designer especially, it helps one evaluate and execute minimal necessary process. Tasks like personas, scoping the problem, sketching, prototyping, front end design (CSS), taskflows and story boards and mock ups are always needing to be done and often there’s a dearth of UXers to do those things. Often developers skip over a lot of these tasks in favor of doing what they do best: developing. It’s important for UXers to communicate their value to a team. Hackathons are great opportunities to get really good at explaining your trade– it seems everyone has a different concept as to what designers do and that’s because it’s a huge umbrella term for all of these roles.
M Theory Part 1 – YouTube. I saw this and I really liked the abstract content, but I thought the visuals could use a little update. Perhaps some kinetic typography. I’ve been dazzled by some well done typography videos recently, so I’m itching to be good at it. So, I tried it out. I started by picking out a color scheme by looking through my pinterest board of colors I’m interested in exploring together.
I started at the beginning and tried to use shapes (with moving masks) to illustrate the spacey music. I think for the upcoming parts and second draft, I’m going to sketch out the typography and look for more appropriate fonts. I feel like my current font choices aren’t sophisticated enough (or coordinated enough) to handle something that requires a high level of understanding to explain with typography. Here’s the beginning of it. I could definitely align the timing a bit more, but I appreciate how the shapes help enliven the reception of the music. I have no deadline, and I’m thinking about putting this off. Letting the idea marinate and perhaps my return to the project will be a bit more inspired.
2. communicate style and function Branding (style Tile) Version 1, very basic.
3.wire-framing explore more efficient layouts (Don’t forget Advertisements if necessary!)
4. understand mobile strategy and other media requirements. The client is very tech savvy and I want her to be able to show people her classes on her ipad, phone and desktop. As well as parents driving need easy to find information about the location.
5. Users: audience, demographic. Who is this for? How should that influence the website? I want it to look clean and efficient (think discipline), but also fun. The main demographic of attendees are 5-10 years old.
After one day working on the project, the first iteration. I’m thinking this needs a lot of type and layout work yet. I also want to include the client’s social media icons and color correct some images. And then work on the enrollment special ads. I feel like I rely on this one framework too much and I’m not flexing its capabilities. I will think on this more tomorrow.
This is composite of images. A reference photo for a commission for a birthday present. I think most of my paintings are birthday presents.
Here’s after three hours at the canvas. I think I’m going to add a yellow wash and then a darker wash over the rockface to make it a little more pleasing to look at. I sent the image to my sister/comissioner. Hopefully she likes it!
Today, I stepped back into code land. With my layout complete from my last session, I started on methods so the buttons would actually do something when clicked. Note: in the button’s description, you must add the “onClick” part, otherwise it is an inactive button. I needed to have the program to have the id of the button to perform the button-specific task. So, I call it.
This is what I see when I look at the code now.Int means integer. This code wouldn’t actually fly. Computers like their naming done in a particular way.This is code to simply add digits to the output screen corresponding to the button pressed.
Try Block
The concept of the try block is fabulous. Say there’s an input that does not compute, like divide by zero or letters or whathaveyou. Without the try block, the program crashes. The try block “catches” exceptions like that and essentially says “chill, we just won’t do this one.” I like computers. They are really dogged. They will try to the point of crashing. But, that trait really isn’t desirable when life hands you so many exceptions. So, the try block will be that code that I imagine will come up a lot. Thanks, try block.
This is for a particular application found on the internet. I did not use Protein as a variable for my calculator app.
Boolean Logic
Today, I used my first “or” statement in programming. It was: io_value == “0”||io_value == “-0.” I’ve never used pipes for anything and now I get to use the “double pipe.” More fun operators here. My favorite part about this is the symmetry of that equation. I’ve forgotten the elegance of mathematics. This time was hooking up the number pad and the tricky plus or minus button. Next session will be quite tricky, actual functions.
I recently went to New York and I had a great time there. It was a time of thinking. The end of summer approaching. My first summer as a certified graphic designer (I just graduated in June) and I felt a little bit like I was going to a Mecca of design. I walked a lot and I wanted to capture this time in my life. How I feel like my horizon is stretched out in front of me. I thought about how I wanted to save this experience in a website. How it acts like a bubble to keep my memories fresh.
As part of this year’s Seattle Design Festival: Design in Health, I attended a “design-thinking” workshop. The design leaders at Substantial executed a hands-on workshop that illuminated the first step of problem-solving within the context of creating a minimum viable product (MVP) in an agile environment.
Ryan Harasyn and Steve Shapero first talked about how an agile environment means having a shared vision with both the developers and designers at the table for the initial stages of the project. The three steps in creating great solutions, they said, are: Discovery, defining the problem; Stabilization, where you consolidate resources and data and start defining your solution; and Repeatability. During the discovery phase, you’ll wittle down your hypotheses after foreseeing problems, considering assumptions, and doing a fair amount of research into a minimum viable strategy. After validating this strategy –with more research!– then and only then should you start to develop the minimum viable product based on that strategy.
three steps in creating solutions
In this particular workshop, we split into groups of five and were then given a prompt.
Each group was to discuss the problems and assumptions of the scenario and begin to form hypotheses. Members of the presentation went around the room to individually assist each team how to deal with the vagueness of the prompt. In my group we talked about the definitions of “chronic illness” and “engage.” We also discussed how targeting a particular segment of the patient population would make it easier to identify specific foreseeable problems and areas of research or clarification. We wanted to know what are role was in this. Were we part of a team of medical experts or are we hired by them? One of the Substantial team members said ti was important to identify the players and some of their needs. The players include stakeholders, investors and the users. They called this part, the mapping of your understanding. Having both developers and designers at this stage was vital to creating a shared vision, better cooperation and a better end product.
A map of my understanding
After about twenty minutes of this, the presenting team instructed us to find a partner from a different group for an Interview. It was interesting because they didn’t tell us what to ask. Forming an interview from no time to prepare was a little nerve wracking. I focused on one part of my hypothesis to help steer the conversation. Through the understanding process, I was convinced that a solution for chronic illness was something that needed to be a routine. I was interested in how my interviewee developed habits. I asked “How do you begin to engage with something often?” He said discipline building, immediate results, a profess bar of some kind and positive reinforcement were factors that would affect his ability to form a routine. I asked him about a specific activity that he regularly engages in and he said jogging. I asked why he did it regularly and he said “I like it. It’s good for me and I feel immediate benefits.” He also said it was encouraging to read up articles written by fellow joggers that recommended amounts of jogging per week, ex. three times a week.
I was his interviewee as well and he asked me about insurance companies and if they issued a program for preventative care, would I follow it and other things related to that scenario.
This is a truncated process, very quick and insufficient for a real MVS, but it was amazing to see what we could get done in less than an hour!
So, we regrouped in our original groups of five and discussed our findings and invent a way to validate our MVS. Most of us had some nuggets of wisdom from personal testimonials but our answers were only as good as our questions. One person had an interviewee with chronic lower back pain and was able to pin point a clear MVS to bring back to the group. She said the MVS should be “We believe that walking daily and socializing will help alleviate chronic lower back pain.” I thought this was too specific and didn’t really speak to the how of the solution. I wanted to include something like building discipline over time creates a capable patient or something to that effect. But, a Substantial team member came by and said that this woman’s MVS is great, very concrete and actionable. Having a strategy that you can go back to is important when coming up with solutions, the strategy must be addressed, otherwise you’re not solving the problem you stated you’d solve.
The Presenters talked about how validating a strategy is important and doing experiments on a small test group can help you get data to support your strategy.
Summary of Discovery Process
Build trust between you (the organization) and the client.
Ask yourself, does the client need to be trained on something to be “business-ready?”
Tackle a broad problem.
Map your understanding. What is the client looking for?
Get to a place where you can start to look for validation.
Conduct research. Interview people. Aim for both positive and negative feedback. Aim for data-driven feedback.
Regroup and take a stab at a Minimum Viable Strategy (you have to start somewhere) Use the phrase “we believe that…”
After some discussion with your client about your strategy and the go-ahead to explore that line of inquiry, start on defining some key user experiences. Prioritize these and work on the ones with high impact. Break the project into smaller chunks to learn more quickly about the nature of your solution. Get more data to validate your direction.
I loved this workshop. This was my first user experience workshop and I feel a lot more confident in my ability to make apps that actually solve problems with an elegant and experimental process. The lessons learned here can definitely apply outside of the healthcare industry, though I am really excited about putting more power into patient’s hands regarding their health.
Kismet Arts Tangent 