Creating a Balanced UX Workflow
•
6 likes•1,600 views
The document discusses creating a balanced UX workflow. It provides examples of workflows for personal projects, freelance projects, agency projects, and application development. It also shows Mailchimp's UX workflow involving design, support, development, compliance, and mobile teams. The document emphasizes that user experience is everyone's responsibility and that Mailchimp's goal is to create an intuitive, easy to use app that empowers and surprises users. It concludes with discussing lessons learned about user desires, expectations, and fears.
![Creating a Balanced UX Workflow ,[object Object]](https://image.slidesharecdn.com/jason-ux-workflow-110928114847-phpapp01/85/creating-a-balanced-ux-workflow-1-320.jpg)
![I’m just a web designer. ,[object Object]](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)
Recommended
Recommended
More Related Content
What's hot
What's hot (19)
Viewers also liked
Viewers also liked (20)
Similar to Creating a Balanced UX Workflow
Similar to Creating a Balanced UX Workflow (20)
More from Jason Beaird
Recently uploaded
Recently uploaded (20)
Creating a Balanced UX Workflow
- 10. Workflow: Personal Projects DESIGNER/DEV
- 11. Workflow: Personal Projects DESIGNER/DEV WIFE/USER
- 12. Workflow: Freelance Projects DESIGNER/DEV CLIENT USERS
- 13. Workflow: Agency Projects CLIENT PROJECT MGR INFORMATION ARCHITECT DEVELOPER DESIGNER
- 14. Workflow: Application Dev INFORMATION ARCHITECT DEVELOPER DESIGNER
- 17. “User Experience is everyone’s responsibility” - Jennifer Downs
- 18. Workflow: @MailChimp DESIGN LAB SUPPORT UX TEAM DEVELOPMENT COMPLIANCE MOBILE LAB
- 19. Workflow: @MailChimp Make the app as intuitive & easy to use as possible. Create fun things to surprise, delight & amaze users. Add features that empower our users to do more. DESIGN LAB SUPPORT UX TEAM DEVELOPMENT COMPLIANCE MOBILE LAB Answer questions, listen to & inform our users. Provide the same user experience to our mobile users. Encourage good email marketing & enforce rules to protect users.
- 35. Lessons Learned
- 43. Take it Home!
- 48. Questions?
Editor's Notes
- So why am I here talking about UX today? I’m more of a designer/front-end dev than a UX pro. I wrote a book called TPOBWD about basic design principles Visual design is a big part of UX so I recommend it to anyone who doesn’t already have a design background. Audience Participation: Share your job title. So…Maybe you don’t have a job title that contains “IA, UX, Interaction” but that doesn’t mean you can’t have a profound affect on on how users perceive/learn/use the things you are creating. Just look around you...
- There are examples everywhere why more people need to be thinking about UX. “ grill” style bike racks that aren’t used as intended
- informative signs that do not inform – what does this sign even mean Entire field of design called Wayfinding All the signage that helps you get around an airport and hospital complex Good signs: Efficient, cohesive & recognizable
- Logical stove burner-to-control mapping is a classic example. How many times have you turned on the wrong burner? Donald Norman’s “Design of Everyday Things”
- non-intuitive, non-user focused interfaces The point is that I’m not just a web designer. I’m also a problem solver. I can have an affect on how the things I design are perceived, learned & used.
- The same things goes for websites… While I was doing web design at agencies, I’ve worked on some big projects like BCBS SC that didn’t have a UX person at all. Just designers and developers…but we were in charge of the IA and figuring out how to
- ...and Moore school of business. No matter how big or small the project, the process and workflow was similar. Client Meetings, Design, Approval, Front End Dev, Launch
- then I started working at MailChimp and my view of web design and project workflows was turned upside down. got me thinking about all the ways I’d worked in the past.
- The first way that I worked (and that a lot of designers work at first) is on personal projects… Shortly after college I rolled my own CMS for my blog. Learning experiment...I was the only intended user, so it was rudimentary
- figured it worked for my personal blog, so I duplicated the database and made a blog for my wife and I it wasn’t long before I switched to a real CMS
- I’ve also worked as a freelancer (both design and front-end dev) on a few projects. This is one step beyond personal projects. If the client and contractor are focused on the users, this is fine...but sometimes...this happens
- Then there’s agencies... Maybe there’s a dedicated IA/UX person, maybe not… but the process is usually driven by the client. Any thought about the users is done upfront and isn’t revisited once the design/build starts.
- I’ve seen a lot of friends that work on small application development projects… Application developers on the other hand scurry to rush features, drop them on users and iterate out the bugs. On difference from typical agency projects…no “external” client to impose rules…
- With all of these workflows (personal projects, freelance, agency, app dev), as far as UX goes, there’s a single point of failure... If you have one person, or one tiny department responsible for UX, you have an Achilles' heel.
- Even good design can be foiled by bad implementation.
- At ReMIX conference here in Atlanta in August… I don’t think we’re unique from this standpoint, but Thinking about all the way’s I’ve worked before, That’s where MailChimp has been different.
- We have right around 100 people at MailChimp and so obviously there are a lot of different teams. These are just some of them. The cool thing about this is that we all communicate.
- Not only do we communicate, but we’re all focused on improving the user experience in one way or another. So with all these teams, what does a typical workflow look like?
- There are 6 of us on the UX Team and we handle anything IA, Design and Front-End code related in the app, so sometimes the workflow stays entirely in our group. The updating of the embed code interface is a good example. Aarron did the wireframing...
- And I built it out... Pretty true to the original design and I didn’t have to bug the developers. Things like this happen sometimes within a department. It’s kinda like the personal project workflow I showed you before.
- Another example of this is the MailChimp coloring book. 100% design lab project. Does it have anything to do with UX, you betcha.
- Back to UX...There are only 3 of us that really edit the application code though, so sometimes project workflows start with the developers. Setting up domain verification was one of those things.
- That’s part of why we set up the pattern library... An archive of the reusable interface elements we have in the app. Grid units (nicole sullivan’s OOCSS) Button Styles Navigation styles.
- In my keynote presentation this slid down…couldn’t get powerpoint to do the same, so 1 slide became 5… Tabs, data/stat blocks, icons
- Template galleries, alert/success/warning/error messages, table styles
- Form styles, …and finally…
- Microcopy examples…here we have some examples of existing alert/success/status/error messages used in the app so we can match the voice I said before that visual design is a big part of UX… another big part is emotion – “voice” of our copy is a big part of what makes MailChimp MailChimp “ Designing for Emotion” – Aarron Walter (comes out Oct 18 th – a book apart)
- So…back to the domain verifcation feature… When a new feature gets added by the devs, it usually doesn’t need much work from us... in this case, the form was a little confusing. This is what it looked like just a few days before the next release was supposed to occur.
- so instead of going through the whole interface design process we were able to check in a few tweaks and the feature rolled out Clarified copy (email address containing yourdomain.com), Consolidated fields, maked “enter verifcation code” lower priority
- ...and sometimes there’s bigger projects, like revamping the “Chimp-Chatter” feed on the dashboard, that require a lot of back and forth. In this case, we did the IA/Wireframing, passed back to devs to get the data pulled in, ran it by support to get their feedback, it came back to us to implement the front end and back to devs again, etc...
- But when all the teams involved are focused on improving the user experience, the feature is usually pretty well polished by the time it launches...
- But even if we think everything is working well, and we don’t get any support requests saying something is broken or confusing, Jenn will often test our changes with real users
- And occasionally, we all get together to watch them...over a pizza lunch. This particular lunch, we were watching some remote tests of user signup. These *never* go how you expect them. ...this is where we learn how we fail. Then we go back to the drawing board, or omnigraffle, or a notebook…
- A few things we’ve learned to think about and pay attention to
- Desire paths... There’s a flickr group with almost 500 examples like this… Sometimes, despite your best laid plans, users don’t do things the way you expect them to. If they hit a barrier, or they get impatient, they’ll abandon your intended solution and do things their own way...
- A lot of the tests that Jenn has done have been of new users… So this is especially true while they’re learning. That’s why we constantly update our knowledge base articles...but more importantly, try to teach people the ropes in the application.
- Another thing we’ve learned to pay attention to is User Expectations they’re subtle but strong... being raised in the south (well, FL isn’t the south, but anyway) I love me some sweet tea. I expect that all sweet tea is freshly brewed.
- The other day, I saw this at a restaurant in town. It looks a lot like a regular tea dispenser, but it uses bags of tea concentrate that get mixed with water like the soda fountain next to it. I honestly don’t care but I thought it was funny that they tried to trick me.
- sometimes we have to do similar trickery in the app. so many things autosave now... Campaign content, template design, embed form settings… But we always make sure there’s a save button… We removed it once from the campaign content editor and users went a little nuts.
- I mentioned that emotions were important… It’s also important to think about how people FEEL when using your app or browsing your website. There are some tasks that anger, frighten, or excite users… We’ve learned that the single most frightening thing for our users was hitting the send button…
- we made some changes to sending/scheduling with the last release so Aarron added this little sentence… a teeny little thing, but people noticed!
- don’t just think about UX at work... Amy and I just bought a house here… a house the needs a lot of work. A built in bed frame and headboard? But we have a king size bed. This frame isn’t even centered on the window. What a waste of space... So I get all Mike Holmes - “MAKE IT RIGHT!”
- So I started tearing stuff out. Ahh, that’s why that’s there...and the headboard?
- Ah, of course. Typical example of poor design covering up poor planning. Notice that the drywall doesn’t even extend to the floor on the left there. that brown stuff...yea, that’s roach poop...lovely
- Why not just run this to the wall?
- ..and sealed it up. That drywall has all been sanded and painted. Carpet will go down soon. What’s the point of all this? UX need to be thought of at all stages of the project workflow. Ignoring UX at the beginning of a project or at the end will result in a lot more work in the end.