Building Systems One Lego At A Time

How planning, component-driven design and iteration lead to better design and less thinking.

Transcript

1. Building systems one Lego at a time How planning, components and iteration lead to better design and less thinking.
2. We’re Made By Munsters. OH. HI THERE! Well technically we are one-half of the Made By Munsters’ team. But you get the picture. JOEY KIRK Founder + Designer KURT CUNNINGHAM Co-Founder + Designer
3. UX what is this term? who is this person? The short answer: It’s everyone. The longer answer: It is an individual who is generally curious about how things work. A person who plays 20 questions just because. Your co-worker who tweaks a design, document or presentation until it solves some problem that was bothering them. How do we implement good user experience practices? What do we have to do to build successful products?
4. How do we solve for x? 1. Gather all the facts before production. 2. Don’t solve problems that don’t exist. 3. Make an educated guess for the MVP*. 4. Create re-usable building blocks. 5. Iterate. Deployment doesn’t mean done. *Minimum viable product
5. Host an inception workshop. 01. GATHER ALL THE FACTS A planning session amongst all stakeholders to create and develop a working concept. User Personas User Stories + Flows Wireframe Sketches Who are building the application for? We need to define our user types, what they do on a day-to-day basis, how and when they will interact with the app. What’s their pain points? Why would they need this technology? What’s their level of tech use? What features do we need to build based on the users we think are going to use the application? What special considerations do we need to make in order to deem the users experience is a success? Then map those stories out. Did we miss anything? It’s time to lift the pencil, pen or dry erase marker. Wireframes allow us to quickly sketch out ideas and propose solutions to problems we are trying to solve. At this point no idea is a bad idea. We want to make sure we design views based off of our user stories.
6. What is a user persona? 01. GATHER ALL THE FACTS Each user persona is made up of a few key features: Age, education, work position and tech use. We establish their daily routine and determine what their needs and issues are in regards to the application. We then provide possible solutions. These individuals can be real or fake. As long as they are an accurate representation of real- world users. Otherwise, they do us no good.
7. Creating user stories. 01. GATHER ALL THE FACTS User stories are actionable items that solve parts of a larger problem. They should be small and to the point. Note, if you think the story is too complexed for a days worth of work, cut it down to multiple stories. Just like Lego instructions, user stories are building blocks. They are parts of a greater whole. • As a user I need the ability to login to the application • As a user I need the ability to assign a review to an employee •As a user I need the ability to remove a user from an assigned review •As a user I need the ability to mark a review as complete •As a user I need the ability to view other users who are my employees •As a user I need the ability to merge many reviews into one review •As a user I need the ability to see how employees stack up •As a user I need the ability to complete a peer-360 review
8. Creating wireframes. 01. GATHER ALL THE FACTS Wireframes add structure and context to the discussion the team has during the inception workshop. It is a quick stress test for user stories and work flows. Keep in mind, wireframes are a designers best friend. Nothing is set in stone. They can be destroyed or iterated on until the problem is solved. Additional note: We are not crafting UI at this point. We are not using our Lego pieces to construct build-able designs.
9. Workshop’s end result. 1. We align all parties on a unified thesis. 2. We capture data to influence our designs. 3. We develop clear benchmarks and goals. 4. We leave as one team working toward a common goal of solving a single problem. 5. We define a Day 1 release.
10. Craft a working thesis. 02. SOLVE ONE PROBLEM What is the problem you are solving? Write it down. Sleep with it. No really, do it. What’s wrong with all of the software 
 Red Ventures tried out during the years? The applications were bloated. Too many features. Didn’t focus on the thing we needed the most, conducting reviews. They were not flexible enough to meet our review structure needs. Users had to click more than two times to achieve a simple task. Users were just confused. Users dread using the applications. Reviews seemed like a chore and not a natural work task.
11. Our thesis statement. Red Ventures seeks a simple, intuitive and clean web application that will allow their users to conduct employee reviews in a time efficient manner.
12. Design a starting point. 03. EDUCATED GUESS Web application design is a process. Designs should evolve and change as users’ needs grow. Design for day 1 Don’t get hooked Test early and often Focus on what is needed for the first release. Don’t spend time designing features that are non-essential to the initial roll-out. Clogging up designs with future feature designs makes iteration harder. Just because it went live doesn’t mean it is set in stone. Designs need to change when issues arise and users provide feedback that raise questions. Listen to your users and adapt your designs to their needs. Use tools such as InVision or Marvel to test your wireframes. Seek feedback early and often. Ask pointed questions and have users complete basic flows. Find where your designs fail to solve a problem.
13. Red Reviews focus. 1. Focus on review task management. 2. Move users from one step to the next. 3. Reinforce positive actions 4. Remove clutter, bring focus on active task 5. Make reviews fun again. don’t build this for day 1
14. Think in components, not views. 04. BUILDING BLOCKS Designing components over views helps to iterate and adapt to users’ needs quickly. Components Structures Built Views What are components? They are singular design elements that can be use and re-used. Alone they don’t mean much, but when attached to other components, a designer can build structures to produce working views. Made of many components, structures shape the way a view is laid out. It’s important to note that each structure should live independently. If you remove one, the entire view should not come crumbling down. Views should be built with many individual components. This allows us as designers to create playgrounds, create rapid iterations and multiple pages that can be tested / vetted until the right combination of components are found.
15. Building Red Reviews. 04. BUILDING BLOCKS Red Reviews was built from various low-level Lego blocks. On the surface they don’t do much but when a grouped together were able to build views that were re-usable or quickly amended based on user feedback. OUR LEGOS BLOCKS • Boxes • Sidebar • Buttons • Links • Lists
16. Deployment is step 1. 05. RELEASE. ITERATE Great you released your product. Now what? Iterate. Iterate. Test. Iterate, again. Having built a design system, you have the Legos needed to build new structures and tweak views that are preforming poorly.
17. Questions? @madebymunsters • hello@madebymunsters.com @kurtcunningham • kurt.cunningham@madebymunsters.com @joeykirk • joey.kirk@madebymuntsers.com
18. Thank you!