UXpin's Blog, page 112

UXPin Changelog September 2017 #8

UXPin changelog is our weekly series on all changes, improvements, and fixes we released the past week. If you’re interested in what we launched in August, check  Changelog #6 and Changelog #7.

Design Systems

Adding multiple elements to the Design System Library automatically creates a symbol out of them
Ability to add the same text style to the Design System Library multiple times 
Improved scrolling performance in the Design System Library (left – after, right – before)
[Fixed] Spec Mode not showing proper size of the symbol

 

Join the world's best designers who use UXPin.Sign up for a free trial.Your e-mailTry it for free!

The post UXPin Changelog September 2017 #8 appeared first on Studio by UXPin.

How to Simplify UX Design Documentation with UXPin

Design documentation can be a total time suck.

That’s why we’ve done our best to make it as simple, automated, and collaborative as possible.

Here’s how UXPin lightens the burden of documentation so you can spend more time designing.

For designers and clients

Guiding folks through a prototype, explaining certain design choices, and showing them the value can be a challenging task. It’s crucial to get the right message across and that’s precisely what you can use Free Flow Documentation for.

First, you can create your prototype in UXPin or use our integration with Sketch and Photoshop to import your work quickly. Now you are only few clicks away from an interactive prototype – just add some interactions to the design. You can also create some depth with multistates by adding more states to the elements, e.g. by making two instances of one input field – active and inactive.

The final step is to provide some context that explains particular particular interactions and the multistate behaviour using our Documentation mode. You can also use this feature to ask your client for their opinion on particular parts of the design.

In order to have a clear and effective communication, all information should be stored in one place, so nothing is lost on the way. That’s where our Preview plays a crucial role.

When the client opens the Preview, they get access to different modes:

They can easily switch to the Documentation section and get familiar with use cases or context for each part of the mockup.

They can test the prototype out in the Simulate mode to see the entire design in action.

They can provide feedback in the Comment mode, click on particular parts, and type in the remarks.

2. For designers and developers

Spec Mode, and Free Flow Documentation helps teams to better automate their specs and documentation.

Automatic redlining + synched metadata

Take a look at the below example to see the fields you can add.

If you use elements from your design system, these fields will automatically populate since your projects and design system are synced.

Spec Mode can also generate CSS code for elements and style guides for projects.

To add more information for developers, just change the mode to Documentation and type in the remarks and suggestions.

Quick access to documentation

Once the designer is done with their magic, the developer can open the Preview and switch between Specification and Documentation modes. This allows them to place the design in context, familiarize themselves with use cases, inspect the elements, check formatting details, and even download all assets with one click.

3. For product managers and stakeholders

Free Flow Documentation can also improve comprehension between product managers and stakeholders. You’ll be able to present different business solutions and ask for their validation without ever leaving UXPin.

Making the right call is often based on the data provided by A/B testing your ideas with the users. This is why in most cases you need to have two variants of a Hi-Fi mockup to present them to your Stakeholders. Product managers can use the Documentation mode in the editor to explain additional business data and analytics.

Once all the necessary information is provided, use our Approval process to deliver the design and gather feedback from your Stakeholders. Here’s how:

Once you send the request, your Stakeholders will be notified via e-mail that the project requires their attention.

After opening the Preview, the Stakeholder will be able to browse through the data you’ve provided in Documentation mode and review the design.

With the final approval of the Stakeholder, the PM has the green light to proceed to the next stage of the project.

With these use cases you can see how UXPin improves workflow across the entire product and design organization.

Ready to try it in UXPin? You can play around with all these features in our free trial.

Join the world's best designers who use UXPin.Sign up for a free trial.Your e-mailTry it for free!

The post How to Simplify UX Design Documentation with UXPin appeared first on Studio by UXPin.

Creating a Design System in UXPin: The 5-Minute Guide

There’s never a better time to work in software.

Developers and designers are among the most desired people on the market. Companies all over the world seem to have a never-ending thirst for software experts. In 2003 the U.S. Bureau of Labor Statistics estimated the number of software engineers working in the US to be 677,900 people. In 2016, this number increased over 5× to 3,870,000.

At the same time, design teams grew faster than software development. In the last 5 years, the design-developer ratio increased by an average of 2.5×. These changes put enormous pressure on designers and developers to take on more projects while delivering higher quality faster. But the challenge is that software development doesn’t scale easily.

Scaling through hiring, without first putting standards in place, doesn’t usually end well. With every new hire, the technical and design debt increases. New ideas for color palettes, typography, patterns, code standards or even frameworks appear in the product, increasing the inconsistency and maintenance cost.

Creating a design systems process is one of the best ways to prevent this problem.

The Era of Systems

For faster and more consistent product development, companies all over the world, including such giants as Salesforce, IBM, Airbnb or Microsoft, started to invest in Design Systems.

Unlike past approaches to setting up standards in software development (pattern libraries, style guides…), design systems are not a static deliverable created from months of work. In fact, design systems are not a deliverable at all – they’re a new process of building software.

For faster and more consistent product development, companies all over the world, including such giants as Salesforce, IBM, Airbnb or Microsoft, started to invest in Design Systems.

Unlike  past approaches to setting up standards in software development (pattern libraries, style guides…), design systems are not a static deliverable created from months of work. In fact, design systems are not a deliverable at all – they’re a  new process of building software.

What Is a Design System?

A design system reflects the truth about the standard experience in a given organization. It’s both trustworthy documentation and a modular toolkit for designers and developers.

Design systems adapt naturally to changes in the product, and sync design and code for an easier way to create consistent experiences.

The Toolset for the new Era

Over a year ago, the team at UXPin started our user research. After 40+ interviews with design and engineering leaders and a survey of 3,100+ designers and developers, we’ve concluded traditional design tools aren’t good enough to serve this new reality.

They’re too fragmented, disconnected, and unfocused. Design system tools must be a complete hub for design and development.

We’ve summed up the research with simple rules for our first release of UXPin Systems:

Dynamic environment,  not  static documentation
Actionable system, not a reference document
Connection between design and development, not just a library of design patterns

With these principles in mind, we released the first design system platform on June 13th 2017.

Step by Step in UXPin: Creating a Design System Process

Using our internal design system as an example, let’s explore how to create the foundation for your design system:

Color Palette and Text Styles
Assets (logos, icons)
Design Patterns
Development Documentation

Important disclaimer: All the following examples were created within UXPin only, but the UXPin Design Systems solution also supports  Sketch.

1. Create an Actionable Library of Styles

Start with the most prevalent pieces of any design – text styles and color palette.

In UXPin, both color palette and text styles can be pulled directly from design projects and saved in a shared Design Systems library (an actionable toolkit that’s always synced with design system).  Your entire team will always have access to approved  styling, minimizing the temptation of introducing yet another typeface or shade of gray.

To add every color or text style, simply select layers in Sketch or UXPin and UXPin willpull the right styling and add it to the system.

All these styles always stay in sync with the library in UXPin or Sketch, which makes for a living system (not just static documentation).

2. Create an Actionable Library of Assets

Just like colors and text styles, you can save all your graphic design assets in UXPin Systems.

Think logos, approved stock photos, or icon libraries. You can save all these in the Design Systems Library, which stays in sync with the Design System and your entire team. One library, directly in your tools and always in sync.

3. Create an Actionable Library of Patterns

You can also save your design patterns in UXPin. All your symbols from UXPin and Sketch can be saved in a Design Systems Library. UXPin symbols can be interactive and animated, so you don’t have to recreate interactions every single time.

Symbols in both UXPin and Sketch have overriding abilities, so you don’t have to worry about your patterns being used in multiple places with different copy. UXPin allows you to adjust the copy however you want and sync everything with the library whenever you’re ready.

It’s a powerful tool to manage all your shared design patterns.

4. Generate a System and Keep it in Sync

Having a library of shared assets is great, but it’s definitely not enough to solve the problem of scaling software development.

Most solutions stop here and don’t move towards development. We’ve decided to go all the way.

In UXPin Systems, all the colors, text styles, assets and patterns become a living system with one click. Just go into the Design Systems tab in UXPin Dashboard, select your library, and it comes to life.

A new documentation page is automatically created and always stays in sync with your library. If you add a new pattern or a color, it automatically appears in your design system.

5. Add Documentation for Developers

Once you’ve generated your system, you can add documentation, including code snippets to any element.  The documentation editor makes it very straightforward to document your system.

Again, the documentation is immediately available to your team.

6. Make Documentation Actionable

Design system documentation shouldn’t just be a reference document. It needs to be where the action is – in the design projects themselves.

With UXPin, documentation from the design system follows the elements in any project.

If you’re working on yet another sign-up form, once you drop in the symbols from the library, UXPin automatically generates full documentation for developers – including all the information coming from the design system (full markup, information about imports, and names of javascript components, etc).

The First Complete Solution

Needless to say, I’m extremely proud of our focus on design systems as the heart of a better software development process. Of course,  this is just a beginning.

If you’d like to try out UXPin for yourself, you can go ahead and start a free trial.

Join the world's best designers who use UXPin.Sign up for a free trial.Your e-mailTry it for free!

The post Creating a Design System in UXPin: The 5-Minute Guide appeared first on Studio by UXPin.

Building UX Teams at Scale: Inside Atlassian’s Bespoke Hiring Process

When you hear the word “Atlas,” you might think of the ancient Greek giant holding the world on his shoulders.

The software company Atlassian certainly lives up to its namesake as an enterprise with 12 products, 2,200 employees, and 90,000 customers.

Atlassian San Francisco office.

Creating a design team to support that scale is no easy feat. Add to that the complexities a B2B company faces, and you begin to truly appreciate the full scope of the challenge.

Atlassian, however, is breaking the mold of the engineering-driven B2B company. To explore how they’ve built a thriving design culture and practice, we spoke to three members of their design organization:

Karen Cross, Head of Design – Go-to-Market & Ecosystem
Amanda Sampson, Senior Recruiter, Design
Liam Greig, Design Manager – Confluence  

Karen Cross,  Amanda Sampson, Liam Greig. 

They revealed the secrets of their success in finding, hiring, and nurturing the right designers from all around the world.

The Right Team Size and Structure

Back in 2012, the design practice at Atlassian was just a handful of folks. Design coherence was lacking – for example, there were 48 different kinds of dropdown menus alone. Recognizing the competitive advantage of well-designed business products, Atlassian started building its design practice.

Liam Greig (center) during a design feedback session. 

First among those hires was Jürgen Spangl, the current Head of Design. His emphasis on a coherent user experience paid off, and in the years since, their firm grew in both the number of personnel and the maturity of their process. Now, with almost 200 people in the design organization and a powerful design system, Atlassian Design is on track to grow by another 20-30 hires through 2018.

Whiteboarding session in Atlassian Sydney’s design space.

“We’re not just trying to grow a design team arbitrarily,” says Liam. “We’re growing our design team so that it complements product management and engineering.”

The design organization at Atlassian currently spans five disciplines:

Information experience – Crafting the product content, interface copy, technical documentation  
User research – Researching and validating user needs
Product design – Product improvements and new product development
Creative team – Creating interactive marketing projects
Design operations – Putting in place the right tools, processes, and vision to make design teams successful

And when it comes to maintaining harmony in the product triad, Atlassian uses this ratio as a guideline:

1 designer : 1 product manager : 10 developers

Of course, the ratio isn’t written in stone – it flexes based on the project and skills of team members.

Generalists vs. Specialists: Enter the Design Skills Matrix

Instead of chasing unicorns, Atlassian hires T-shaped individuals to fulfill their five disciplines. Team members specialize in one area of design (the vertical line of the T), but can still fill in other areas (the horizontal T line).

Hiring T-shaped designers is ideal for balanced design teams with cross-functionality. The structure fits perfectly with the career development process: usually new hires work on one product for at least a year to hone their skills. From there, designers can transfer between different products.  

So how do they build the profile for their T-shaped hires? Karen Cross (Head of Design for Go-to-Market and Ecosystem) has created a design skills matrix now used globally across all hiring and career development efforts:

But what about coding? Where does Atlassian weigh in on the debate? Well, it all depends.

“Coding certainly doesn’t hurt, but it’s not a must-have,” says Liam Greig, Design Team Lead on Bitbucket. “Again, back to the T-shaped designer — it depends on what we’re looking for in the T-shape. More importantly, can you understand people who code?”

Amanda Sampson (Sr. Design Recruiter) agrees that different design roles require different levels of technical skill. “If we’re hiring a prototyper or growth designer, then they should be able to code. That way they can quickly design, code, and ship an experience,” says Amanda. “For most designers, we care more about how they work with developers and function within technical constraints.”

The Carefully Crafted Hiring Process

To find the right T-shaped designers, Atlassian follows a hiring process that’s anything but cookie-cutter. Instead of using the same process as engineering and product teams, the design organization created a tailored four-step process.

1. Initial evaluation

The process starts with reviewing a candidate’s resume and portfolio. According to Amanda — who’s taken classes at General Assembly to immerse herself as a recruiter in the designer mindset — a formal design education isn’t as important as how they think.

She’s particularly interested in how they solve business problems. How do they present their work? How did they understand the problem and the user group? Do they know what worked and what didn’t in their design? These talents can’t always be taught.

2. First phone conversation

Closer to a traditional screening interview, one of Atlassian’s two design recruiters spend about 20-30 minutes with a candidate. The recruiter explains the background of the role, the  locations, and the expectations of the role. The candidate will also summarize their experience and expectations.

3. Virtual portfolio and experience review

At this stage, the hiring process starts diving deep.

The hiring manager (someone like Karen or Liam) and candidate speak for about 45 minutes to an hour through a video interview to explore the decisions and process behind a few projects in a candidate’s portfolio.  

“Don’t just walk through features,” Liam explains. “Why did you make those decisions? Why is it a carousel? Can you link research insights to a design decision?” It’s not enough to design the right way; candidates have to understand and explain why it’s the right way.

4. Onsite interview

Candidates who pass the virtual portfolio review then get invited for a half day onsite at one of Atlassian’s global offices.

Atlassian’s Sydney office.

After a series of 1:1 conversations with other team members, the interactive design exercise begins. Lasting between 1½ to 2 hours, these fictitious exercises span two sessions that mirror the divergence and convergence of the design process:

First session –  2-3 Atlassian employees role-play with the candidate to gauge collaboration skills (confidence, delegation, leadership style) and idea generation abilities.
Second session –  Candidates are given time alone to create a cohesive concept. The final deliverable may range from a wireframe to hi-fi mockup. When ready, the candidate will present their work to the same group from the first session.

Thanks to the alone time in the second session, the process evaluates soft and hard skills without making more introverted candidates uncomfortable. The format reflects Atlassian’s emphasis on balanced designers over unicorns.

“We’ve left the room feeling ho-hum after seeing a candidate not shine in the collaborative session, only to come back and be totally blown away by their work in the solo session” says Liam. “The format really shows all the skills of the designer and prevents us from pigeonholing people”.

Following the interactive exercise, candidates are then invited to a values interview with several employees. The goal is to assess culture fit according to Atlassian’s company values. “Culture fit isn’t about being like the Borg and trying to assimilate everyone into our way of being,” says Liam. “It’s more about sharing the same values and letting culture be fluid as a team grows.”

Questions like “What don’t you like about your current environment?” and its follow-up, “What action have you taken to change that?” shed light into who’s likely to jump ship at the first sign of danger (not team-players), versus those committed to finding solutions first.  

“Culture in tech has almost become a buzzword,” says Amanda. “We demystify ‘culture fit ’by defining our core Atlassian values and interviewing accordingly. We dig into someone’s experience, philosophy, and attitude to see how it resonates with our values.”

The values interview concludes the hiring process, although some additional interviews may be needed to iron out logistics or involve remote team members who couldn’t be onsite.

Designing the Onboarding Experience

The onboarding experience is just as carefully crafted as the hiring process.

Atlassian divides their onboarding into three parts:

Before the first day. A welcome package arrives at their home around the same time they receive an offer. The package includes cultural artifacts like a passport holder to represent the company’s global workforce. Design hires also receive an extra gift: Designing at Atlassian, a physical anthology of the design team’s Medium articles.
First week. Atlassian uses a mentor or “buddy” system to onboard new employees and guide them through onboarding activities. The mentor is usually outside of their core team, again encouraging new hires to broaden their expertise.

Regular check-ins for 90 days. Managers meet regularly with new hires to discuss the company’s mission, products, values, customers, and workflows. Check-ins let managers assess new hire progress, and gives new hires a platform for discussing goals and expectations.

Long-term Career Development: The Dual-Track Model

Over the course of their career, designers can choose from either specializing in design craft or design leadership. By offering equal compensation and stature in the company, the dual-track model allows designers to pursue careers out of genuine interest and skill. Designers are also free to move between the tracks.

Career development paths at Atlassian Design.



To promote a sense of community and improve knowledge sharing, Atlassian also gathers together their design organization every year for Design Week. During the internal conference, teams share best practices from case studies and participate in fun activities together.

Atlassian Design Week 2017

Conclusion

Well-crafted products require good designers. To attract good designers, you need a well-designed hiring process.

Design transformation isn’t as simple as hiring hundreds of designers and calling it a day. Careful processes are required to hire and develop the right design talent without disrupting the balance of other teams.

It’s no different than designing a product: consider the end-user experience, think through the consequences of each decision, and be prepared to evolve and iterate over time.

Interested in being a designer at Atlassian? To see available positions, check out Atlassian Design Careers.

The post Building UX Teams at Scale: Inside Atlassian’s Bespoke Hiring Process appeared first on Studio by UXPin.

UXPin Changelog August 2017 #7

UXPin changelog is our weekly series on all changes, improvements, and fixes we released the past week. If you’re interested in what we launched in August, check  Changelog #6 and Changelog #5.

Design Systems

Ability to change Design System name while creating it from scratch.
Adding custom pages to Design System documentation.
Top bar and left menu redesign.


Editing text styles and symbols – delete items and change names from Design Systems documentation.
Ability to get autogenerated specs for every UI pattern in Design System.



Ability to sort, rename and delete text styles and UI patterns.
[Performence] Extensive Design Systems (such as this one) loading time improvement.

Symbols

[Fixed] Copy/paste groups with symbols between prototypes.
Deleting documentation when the symbol is removed from DS documentation.

Sketch (Plugin 4.5)

Important: Plugin update mechanism will now be handled by Sketch.

[Fixed] Issue with grouped symbols not being added to Design System Library.
[Fixed] Applying gradients to elements from Design System Library.
[Fixed] Adding radial and angular gradients to Design System Library.
[Fixed] Issue where elements with fractional dimensions were not rounded properly when exported to UXPin.

Join the world's best designers who use UXPin.Sign up for a free trial.Your e-mailTry it for free!

The post UXPin Changelog August 2017 #7 appeared first on Studio by UXPin.

Smashing Conference (Oct. 2017): Get $100 Off

As guest authors for Smashing Magazine, we’re pretty excited to share some cool news about their upcoming conference in Barcelona.

Smashing Conference is an in-person extension of the practical content we read on their site. Based on their speaker lineup and topics, the multidisciplinary conference explores UX and front-end development case studies:

Design and development collaboration
Best practices for front-end development
Mobile design and development
Evangelizing UX design

An image from SmashingConf in Barcelona 2016. Image Credit: Alessio Carone

What’s it about?

A big proponent of collaboration and networking, Smashing Conference aims for an intimate and comfortable experience. No fancy suits, impersonal halls, just useful content with like-minded designers and developers.

Smashing Conference 2016.

They’re bringing together experienced folks to share front-end and UX techniques and the pitfalls they ran into, lessons learned, and efficient workflows.

This year’s topics in Barcelona include:

How to improve the perceived performance
Where and how to use SVGs
Accessibility For Everyone
Responsive Design
Emoji integration
Design systems

When is it?

October 17-18, 2017.

Who’s speaking?

This year’s 15 speakers include:

 

Brad Frost – Author of the book Atomic Design, co-host of the Style Guides Podcast, he has also helped create several tools and resources for web designers, including Pattern Lab, Styleguides.io, Style Guide Guide, and WTF Mobile Web.




Stephanie Walter – A Web Designer, Pixel & CSS lover, she focuses on designing for user experience on mobile and web applications and Responsive Webdesign. She also teaches courses on Mobile design and optimization and HTML & CSS for beginners at the University of Strasbourg.

 

Sarah Drasner – A web developer and designer, with a history in as a Scientific Illustrator and an Undergraduate Professor. She’s an award-winning Manager of UX Design & Engineering at Trulia and staff writer at CSS-Tricks.

Monica Dincluescu – An emojineer at Google, she works on Chrome, web components, and Polymer.
Anton and Irene – Creators of interactive experiences for many large scale clients and projects, under which the redesign of USAToday.com, Metmuseum.org, Zumtobel.us, Balenciaga.com, Wacom.com and SportsIllustrated.com. They’re also the creators smaller projects, apps and experiments for clients like Shantell Martin, Karim Rashid, Google, Nickelodeon, Porsche and Red Bull.

Marcy Sutton – A Web Platform Award winner for her work in accessibility, she works on web accessibility tools at Deque Systems, a company focused on digital equality.

Paul Boag – User experience strategist who helps companies make use of digital to better serve connected consumers. He hosts the award-winning user experience podcast at boagworld.com and is the author of four books including Digital Adaptation and User Experience Revolution.

Where is it?

In Barcelona at the Palau de la Música Catalana, one of Barcelona’s most magnificent buildings, built from 1905 to 1908.

Palau de la Música Catalana

Get your discounted ticket

The folks at Smashing Conf were kind enough to offer us (and our followers) a discounted rate.

Get $100 off with the coupon code “uxpinrocks”.

Get discounted ticket

The post Smashing Conference (Oct. 2017): Get $100 Off appeared first on Studio by UXPin.

Closing the Gaps Between UX and Agile: Advice from Adrian Howard

Adrian Howard is passionate about creating great teams and great products.

With over 15 years experience working with startups, established businesses, and agencies, Adrian is an active member of the Agile and Lean UX communities. He cofounded his agency Quietstars to specifically help companies integrate business processes with design and Agile methodologies.

We recently spoke with Adrian to explore how to avoid the common pitfalls of integrating UX and Agile. Here’s what he had to say.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile. 

Have you seen any gaps between Agile processes and user-centered design?

I don’t think Agile and UCD are misaligned in intent. We only create gaps through malpractice and misunderstanding.

People often say Agile is a very developer-focused set of practices. That’s not entirely true.

While Agile definitely originated from the developer world, the focus was very much on, “Let’s stop building crap products. Let’s start making our customer happier. Let’s start listening to our customer. Let’s have much tighter feedback loops. Let’s deliver actual value.” All those principles completely align with UX goals.



You’ll find a lot of stuff out there that’s Agile in name only. It’s the same as passing off rubbish design in Photoshop as UX work. There’s a lot of, “We’re going to jump on the latest buzzword because we hear it’s good.”

But the company does’nt understand the underlying strategy behind Agile. So you get a lot of Cargo Cult Scrum, especially in larger organizations where people run the sausage machine at the development team as fast as possible, pushing functionally sound features out all the time without enough user validation.

As far as I’m concerned, that’s not Agile at all. That’s just a superficial interpretation.

What is one of the top mistakes you’ve seen companies repeat as they practice UX in an Agile environment?

Because a consistent stream of feedback usually pours in during Agile product development, some companies might assume usability testing and user research skills aren’t required. The product team is already pushing incremental features live and hearing from customers quickly, so what more do they need?  

The fallacy is that unless your team has at least basic skills in user research or usability testing, you might hear about the problems from users, but you won’t know how to steer the product out of those problems.

So how can Agile teams build up more UX competency to better act on user feedback?

Increase the whole product team’s user exposure hours. Don’t just rely on passive user feedback coming through customer support, or usability reports delivered by a researcher or designer.

In fact, if you look at the origins of Extreme Programming, the creator Kent Beck actually embedded a user into the product development for Chrysler’s Compensation System (the test bed for his XP methdology).  

Of course, that kind of Stockholm Syndrome-esque approach does come with potential bias since the customer becomes part of the development team. But still, even at that level, the whole team at least was in regular contact with the end-user.

Usability reports are easily ignored by development teams. However, if a developer attends even just 1 hour of usability testing a week, the feedback hits home immediately. People will instantly believe and understand a designer’s recommendations because they’ve experienced the visceral power of seeing a poor old end-user having a horrible time with the product. You don’t need as much documentation to convey your point.

Try an incremental process of drip-feeding your exposure hours. Every other week spend a few hours with developers interviewing users and moderating usability testing. Incremental research provides more value because people apply insights by the next sprint.

Spreading out your user research is an easier sell to organizations than trying to convince them to spend $60-70,000 on a month’s worth of user interviews all at once. You spend less upfront, show results quicker, which earns more support for thorough research.

You spend much less on user research upfront, and you gain buy-in more quickly since you can show the problems you fixed. Plus, you’re constantly steering the product in the right direction as you uncover new customer needs since the time you started the project.

I have a cliche slogan which is: “Do less more often together to do more”.

Do you think component-based design helps with UX in Agile processes?

It certainly relieves many pain points.

For example, I run this workshop exercise where I show wireframes of popular sites to developers, and designers. I give everyone a few minutes to write down their observations. Developers will say “These are the elements of the application, this is the form X1 for next the page, this is the edge case, etc”. Designers will talk about vertical rhythm, typography, and overall interaction flow.

Everyone sees a different part of the elephant. Component-based design helps you reduce that misinterpretation and resulting approval bottlenecks.

When you have a shared design language that breaks down into universal UI patterns and elements, designers no longer need to create everything for signoff. The whole team now has a toolbox for exploring new ideas or refactoring the existing UI.

As a result, the product team’s conversations are much more strategic.

Instead of developers wading through minutiae when asking a designer to recreate a whole page, everyone knows how the pieces fit together. We know the forms we should use and the interactions we should support. Your sprint release quality improves since developers with little design background can implement mockups and prototypes with less risk of inconsistency.

By democratizing the design implementation, the designers are then freed up to focus on the more difficult business problems. You get to “done” faster and better.

Does the fast pace of Agile UX increase risk of experience debt?

Only if you focus purely on speed of release.

Agile is not just about delivering faster. In fact, the more crap you release, the more crap you need to wade through, and the slower you’ll become anyways.

The issue of UX debt in an Agile process all depends on your organizational values. Does the company care more about keeping the development team at 100% capacity, throwing out tons of features, or about delivering value?

Because if it’s the former, then nobody is really incentivized to dedicate time to “payback sprints” to clean up as they go.

You need to develop against a hypothesis (like Lean UX advocates) and prioritize your work according to the Kano model, otherwise you will inevitably create unmanageable UX debt.

Going back to my earlier point, you need collaborative incremental user research to keep your Agile sprints in check. When the product manager and developer sees five people in a usability testing all fail miserably to register for an account, the designer doesn’t need to fight as hard to justify an iteration sprint versus being forced to dive into the next feature.

When an experimental strategy drives the Agile UX process, you can better remove the danger of people sticking to their plans for fear of losing face.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile. 

The post Closing the Gaps Between UX and Agile: Advice from Adrian Howard appeared first on Studio by UXPin.

Solving Agile UX: Advice from Laura Klein

Author of Lean UX for Startups and Build Better Products, Laura Klein is a product management and UX expert with over 20 years experience in tech.

She started her career when the waterfall process dominated product development. In the years since, she’s practiced multiple forms of Agile.

We sat down with Laura to explore the best practices she’s learned along the way.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile. 

How do you see Agile and UX working together?

Agile was created for engineers, so it originally didn’t address UX – and honestly, that’s kind of fine. We’ve learned to adapt.



The saying is that “Lean helps you build the right thing. Agile helps you build the thing right.”

Lean Startup is about constantly making sure that you’re working on things that customers will use. Agile is about delivering those things to them quickly and efficiently. They’re both about helping you learn quickly and adapt.

I would argue that any kind of user-centered design contributes to all of that, especially the learning. If you use all three of them together it’s easier to build the right thing, and it’s easier to build it the right way, and that is helpful.

But I’m not religious about it, the only thing I don’t love is building things without talking to users.

Could you help walk us through how you’ve seen that Lean/Agile/UCD hybrid process play out successfully in projects?

The Lean Startup process is very much about understanding what you want to build by testing your assumptions with customers. You’ll see that overlaps with UCD methodologies, since customer development is a form of user research. We’ve been observing users in the UX community for many years already, so the two work very nicely together.



On the other hand, Agile is  a way of organizing your engineering team to release features faster and deliver customer value more quickly.

I’m a big fan, not just of the Lean and Agile philosophy, but also the related discipline of Extreme Programming which includes things like test-driven development, pair programming, and continuous deployment.

Continuous deployment helps deliver the hybrid process – Lean Startup, Agile, and User Centered Design -because we can be talking to users, observing them, studying their problems, coming up with solutions for them quickly and getting them out in front of users and then measuring the results within a very short period of time

This can be a very Lean Startup, hypothesis-driven process: “If we make this change, we  predict it will have this effect. Now let’s test to see if we were right or wrong.” A great advantage, of course, is that we can complete the whole process from hypothesis to validated solution in a matter of hours or days rather than weeks or months.



The key is to always drive your process based on a clear hypothesis. You want to design a small complete thing (not an under-designed thing) as a quick experiment. You can then use Agile processes to break down that complete thing into bite-sized tasks for engineers.

If you involve engineers in the user research, you also gain a greater shared understanding of the problem, which always helps with efficiency. So we come up with our experiment, build it,  ship it,  measure it, and all of a sudden we’ve gathered meaningful results in a very short period of time. That’s a great cycle to follow, and how I’d combine the different processes.

Now you’ll notice that I didn’t say things like, “Well you always need two-week sprints, and you need a planning meeting, etc”. Daily standups and Scrum are not the point. Those are tactics. They’re not bad! In many cases, they’re incredibly helpful tactics. But they don’t define the process.

The strategy behind Agile is being able to focus on small chunks of work that you can quickly get in front of people to learn if you need to change direction. Continuous integration and continuous deployment help you figure out very quickly if things are broken. You don’t find out 6 months later and then cycle back into the process again.

Agile is not specific tactics. Just like Lean Startup isn’t only A/B testing or customer development and user centered design isn’t just writing things on post it notes or making wireframes. Those are just tools. Occasionally using a hammer doesn’t make you a carpenter.



Know the strategies behind your process and adapt the tactics and tools to your team.

How do you fit user research into an Agile process?

Companies newest to Agile struggle most with fitting user research into the process.

They worry about design teams working ahead of engineering, which is really tough at the very beginning of the Agile transition, because it means that engineers are sitting around waiting for people to finish designing the stuff that they’re supposed to start building.  So, people try to dramatically shorten the design process.

You end up with a collection of tiny waterfalls.

Of course, you can’t avoid that altogether. I don’t believe teams need to do everything together. Not everyone needs to do user research together or sit around and create wireframes together. Designers will need to do some work ahead of engineering  so that engineers have something to work on. But they don’t need to design everything ahead of time.

Also, don’t think of user research as something that only happens at the beginning of a project. Certain types of user research does tend to happen early – the generative stuff where you’re learning a lot about your prospective customers and their needs often gets frontloaded – but we need to stay in constant contact with users throughout the project and involve everybody on the team in some of the regular research activities.

Grab design ebooks created by best designers

All for free

Download Download Download DownloadDo you want to know more about UI Design?

Download 'Enterprise UX Industry Report 2017-2018' FOR FREE!

Download e-book for freeClose
In your almost 20+ years in tech as a designer and developer, what are some of the most dangerous UX mistakes you see Agile companies make?

Setting the designer up as the user champion. We should all be user champions.

The other problem I see is creating this series of mini-waterfalls where engineers are just handed very specific things to build with no input into the design or research process, so they don’t have the context to make good decisions.

We need to work together on many product decisions. You can’t just say “I did all the work upfront, now it’s your turn”.



The situation is even worse honestly when you’re dealing with a design agency where the conversation is very much “Here are some comps, implement this,” and then all of a sudden the engineers are left with so many questions that they just answer in the simplest way possible.  

It also absolutely drives me nuts when it’s set up as designers versus engineers, and every decision is, “Oh, is this going to be good for the user or good for the engineering team?” We should have a process that’s good for everybody, and that comes from collaborative teams where everybody has an understanding of the user and the ability to contribute to important decisions.

How do you run retros so that people actually “fail better”? instead of just “fail faster”?

In terms of time length, the retros usually run 15-30 minutes. Any longer and it costs a lot – not just in terms of salaries, but also morale. Designers and developers hate disrupting their flow with meetings.



To focus the discussion, I start every retro with the “Start-Stop-Keep” format. Based on our progress in the past sprint:

What should we start doing that we haven’t already?
What did we try that we should stop doing?
What worked so well that we should keep doing it?

We also review metrics of any recent features that shipped. One thing I don’t like about Agile is the misleading feeling of “Done”.

We even have a column on the Kanban board that’s called ‘Done’, right? So, “Oh, I moved it to Done, that task is done.”

That task is not done. It’s just in users’ hands. It’s not done until it’s changed the user behavior in a way that meets the business goal we set. Until then, all you’ve created is an output without an outcome. 

You might ask some other variations of the questions in your retro, but you must change the conversation from “What did we accomplish in terms of getting working features out the door?” to “What did we accomplish in terms of impacting the business and changing user behavior?” 

In an Agile UX process, what else can we do to redefine the meaning of “Done”?

Understand that the job of anyone on a product team is not to ship a feature. Your job is not to write code, your job is to increase a business metric. We need to show that number on a big information dashboard so that everyone can see it.

If we’re telling engineers, “Hey, your job is to knock off 6 tasks a day and hit this particular velocity and close this many issues,” that’s all you will get.

We need to tell the whole team “Hey, your job is to increase this number. Nothing is done until that number’s where it needs to be (and these other numbers haven’t suffered).”

For example, “Increase user activation from 15% to 20% without decreasing retention”.

When you focus on a common goal like that, it also creates a stronger sense of “the product team” versus “the development team” and “the UX team”. Companies need to reward their teams fairly based on those business goals, which is admittedly really hard to do.

For more advice and case studies from 10 UX practitioners, download the Definitive Guide to Integrating UX and Agile. 

The post Solving Agile UX: Advice from Laura Klein appeared first on Studio by UXPin.

Agile UX for the Enterprise: Advice from a Sumo Logic Design Director

Based in the Bay Area with 250+ employees and $161 million in venture capital funding, Sumo Logic serves some of the top enterprises in the world.

The company’s analytics platform visualizes more than 100 petabytes of data per day, helping businesses harness the power of machine data to streamline operations.

In 2015, Sumo Logic hired their first UX team comprised of design leaders, interaction designers, visual designers, and UX architects. One of those designers was Daniel Castro – a 20-year design and engineering veteran in the enterprise space. 

Sumo Logic’s UX readiness model. 

Now a Design Director, Daniel spoke with us about the tactics and processes required for Agile UX to succeed in the enterprise.

 

What common mistakes have you seen companies make as they fit user-centered design into Agile?

The first time I heard of Agile was when I was designing at Verizon. One of the Agile evangelizers who developed the manifesto presented a really detailed deck to the company.

I remember the response from the whole design team was  “This whole process is never going to work.” At that time, the concept of a UX “Sprint 0” just didn’t exist. We were just expected to start designing and developing immediately.

So, as with a lot of processes, you need to pick out what applies and what doesn’t. Since the early 2000s, we’ve seen so many different flavors of Agile that sometimes it almost feels like we’ve just created micro-waterfall.

In fact, a developer here at Sumo Logic actually has a sign in his cube that said “Drink coffee, do stupid things faster and with more energy!”.  Agile is the coffee for your design process – it is a fantastic tool for efficiency, but it doesn’t deter you from doing dumb things.

The biggest mistake is thinking that Agile will help you move in the right direction. You need to build in a series of checks and balances to ensure you’re building the right thing.

How do you strike that balance between user-centered design and Agile processes?

You take advantage of Agile’s collaborative nature to expose everyone to the value of user-centered design.

User-centered design is naturally iterative, but in reality you only have a few shots at revisions before you frustrate engineers. They’ll get cranky because the requirements keep changing.

To make the most of the iteration sprints you can realistically run, one of our most successful tactics is ensuring everyone understands that each design change is supported by usability research and testing.  

In our design process, the first step is to validate whatever problem a product manager presents with customer interviews. Once we’ve spent time digesting the feedback in the form of customer journey maps, our design team clears out their calendar for ~2 days. We email the whole company and advise certain stakeholders to be on-call for feedback.

For those two days, we’ll hold a highly focused “Swarm” session in which we dive deep into divergent and convergent design around the problem. The Swarm also helps us align to the product vision for the ensuing sprints and the business goals. We might also create additional generative research questions with developers and PMs, which then breaks down to a series of tasks you test with users with alternating sprints of testing and design.

That list of tasks is the contract binding developers and designers together for each sprint. You reach a solid middle ground where developers aren’t pushing back on every change, and designers aren’t lost in blue-sky thinking.



You get more buy-in for unexpected iterations because the context changes completely. Designers aren’t forcing the developer’s hand – the customer is guiding everybody along.

Sumo Logic’s Agile UX process. 

How do you approach documentation in the Agile UX process?

You can’t completely throw out your documentation just because you’re Agile. You need to create smarter documentation.

Documentation doesn’t need to live in a document. You can be nimbler, like Slacking your team a screenshot of your whiteboard session. Don’t obsess over the form or format – the singular goal of documentation is to ensure that everyone agrees to the success criteria.

For example, if I need to convey more detail after a whiteboard sketching session, I’ll create a quick UXPin prototype and share with the team instead of marking up a huge product specs document.

Sumo Logic prototype created during a discovery phase for their Unified Logs Metrics product. 

In the platform, I can literally just drag and drop objects from the dozens of libraries to convey the concept that our team discussed. Add some notes to the prototype and share with the team, and now everyone has naturally created documentation together that actually helps us make better decisions down the line.

Understand the collaborative spirit of documentation, not the tactics.

Does this natural form of documentation help you mold your product strategy?

Absolutely.

For Sumo Logic, the UXPin platform really shines at helping us create collaborative visualizations to help PMs and developers better understand both the horizontal requirements (overall feature set) and vertical requirements (depth of each feature).

Even if the PMs and developers aren’t physically present, we can can send them a project link for their comments. They suddenly have clear visibility into how the scenarios play out for each persona, and how it all comes together to form the overall customer experience.

Collaborative prototyping helps the team understand the end-to-end solution and how it breaks down into chunks of work for sprint planning. Very early on, the team can start to understand what Release 1, 2, and 3 looks like and how they all map back to the core vision. Everyone gets a better sense of what they should and shouldn’t build.

The prototype naturally joins the product strategy and design tactics together. Even though your final product might not look anything like the prototype, you’ve created a living representation of the core success criteria. You can’t really see that with paper documentation.

How has prototyping helped you define success criteria in Agile UX?

So, after we’ve held the “Swarm” sessions and conducted user research, we’ll sketch through all the feedback. Once the sketches start to convey flow, we’ll dive into a lo-fi prototype.

The prototype flows are the heart of the design. They inform all the tasks, which of course define success for the product.

With a prototype, you can tell confidently tell a developer “Hey, we tested this design and it’s ready for you”. After the first formal build, you can compare the coded design back to the prototype and list of usability tasks.

Design swarm at Sumo Logic. 

For each sprint, how do you build the components without losing sight of the overall strategy?

You need to set success criteria in each sprint on two levels.

Let’s return to the bicycle analogy.

First, you need the horizontal success criteria: the person needs to sit down, hold down the handlebars, pedal, and move from A to B.

Secondly, you need vertical success criteria: the frame design will be aluminum, the pedals are a certain size, etc.

Not only does the team need to understand both levels of success criteria, but you also need to ensure you’re testing at both levels.

You can’t test features in isolation. You need to test the entire end-to-end solution as early as possible. Otherwise, you get lost in vertical paths. You build the most amazing tires but Billy can’t ride the bike because the tires don’t fit on the frame.

Of course, prototyping helps us get that perspective at each step in the process. It’s a living contract for both sets of features. Anyone can have high-level conversations about strategy, or dive deep into individual components.

What Agile principles have you found useful to user-centered design?

Agile gives you a concrete structure for planning ahead. It brings designers back to earth and prevents them from wanting to design forever.

Agile has also democratized the design process so that even sales and customer success can contribute to the product.

We’re able to break up work, encourage open contribution, and move away from the “lone designer” mentality.

On the other side of the spectrum, how do you prevent too much design collaboration (e.g. design by committee)?

That’s always a tough issue.



It starts with the designer’s attitude towards collaboration.

First, they need to see themselves as a facilitator for gathering, shaping, and testing input.

Secondly, consider holding 1:1 sessions with vocal stakeholders. During design reviews, let them air their thoughts, but if they dive too deep into prescriptive advice, tell them you care so much about their ideas that you want to dedicate focused time to discuss.

Sometimes, you’ll find that stakeholders might even reconsider since they realize they need to separate personal opinions from facts. It seems like a paradox, but sometimes being overly open actually helps people better accept dissenting opinions.

For example, we were working with a product manager who wasn’t exposed much to the design team. We had trouble communicating our approach, and he was adamant about a certain feature. We simply responded with “We don’t think it will work, but let’s test it and see”.

Coming out of that usability test, the original idea was invalidated, but we found pieces of it that could work in a different context. So even if the testing validates the designer’s idea, you can’t tell others “I told you so”. You need to convey a spirit of “We’re willing to work with you”.

Finally, designers can try reframing the conversation by saying “Look, we’re trying to make you look amazing. We want to release a product that will make people want to write about your features.” versus “Look, my idea is right because…”

All of a sudden, something clicks and the other stakeholder realizes that the designers are on their side – and sometimes that means saving them from themselves.

Do you follow a component-based design system (e.g. Lego-block approach to design)?

We’re currently in the middle of a reboot project that will help us work even closer along those lines.

Luckily, we’ve been blessed with UI developers who sit inside the UX team. As such, designers and developers can define the major components of a pattern library together.

Once you have that common design language that breaks down to patterns and elements, everyone does less redundant work. Designers can focus on solving the large business problems, and developers feel empowered to use vetted components instead of asking designers to verify everything.

We aren’t 100% there yet. But after this reboot project, we’ll be much closer. You can imagine how exciting it will be to just go into a shared environment and grab the exact component to match your context of use.

How would you improve the Agile UX process?

I’m all about expectations, whether they’re big or small.

The best process starts with collaboratively defining the requirements for success. From there, you can chunk out all the pieces into your sprints.

Within each sprint, you also set expectations for each chunk of work. What are the goals? What are the discovery questions? What are the tasks? How will we know customers love this?

You repeat the process, ensuring that everyone on the product team always knows the answers to the four questions above.

Download the 99-page Definitive Guide to Integrating UX and Agile. 

The post Agile UX for the Enterprise: Advice from a Sumo Logic Design Director appeared first on Studio by UXPin.

Integrating UX and Agile: Advice from Jeff Veen

With a career spanning 25+ years, Jeff Veen’s experience has spanned design, business, and venture capital.

He’s lead design teams at WIRED, Lycos, Google, and Adobe. He’s co-founded three successful companies: Measure Map (acquired by Google), Typekit (acquired by Adobe), and Adaptive Path (acquired by Capital One). Now, he’s advising startups (like us) on design and product strategy as a Design Partner at True Ventures.

We figured he knows a thing or two (or many, many more) about how to practice design successfully in an Agile process. So we sat down with him for an hour to learn from his experience.

From hybrid processes to conducting user research and running retros at scale, here’s his most useful advice.

Want more practical advice on Agile UX? Download the new Definitive Guide to Integrating UX and Agile.

You founded Typekit, lead teams at Google and Adobe, and now work in venture capital. How do you balance UX with Agile?



I’ve seen a lot of different methodologies come and go, or come and merge.



We adapted practices from Extreme Programming, Agile, and Lean Startup (which I think is an evolution of both of those ideas). We didn’t follow “agile with a capital A”, but just treated it as another inspiration for our hybrid process.



The most steadfast “rule” was that every single person on the team is doing UX, whether they’re a back-end developer, front-end developer, or designer. A Database Engineer is just as important to delivering the end-user experience as a Visual Designer.

To make that hybrid process work, we found it helpful to merge the UX and development team. I just made one team and said, “You all have different roles towards making the best possible product, now let’s follow a design process that works for all of us.”

For example, our daily standups weren’t by the book at all. If you read the books about Agile, you’ll find lots of discussion about tacking index cards up on the wall and moving things around. I don’t really do a lot of stuff, but I love the spirit behind checking in every morning to gauge progress and morale.

Once our teams grew, we scaled the format to accommodate size (sometimes 40+ people). You don’t have ask every single person, “What did you get done yesterday, what do you want to do today, and what’s blocking you?” Instead, you can appoint key people who have emerged as leaders in the organization to report out on these answers so the format is more “Here’s what’s happening in our company and team”.

Then, as a leader, you’re better able to see if there’s energy here or if you need to dig deeper into problems.



Was it hard getting buy-in for that more hybrid design process?



It was definitely more challenging for companies that were still following a waterfall process.

For example, you go to a place like Adobe, which is really entrenched in an org chart with separate disciplines and everybody is centralized around their discipline, and engineers with years of experience will say, “Would you just please give me a mockup, so I can go build it?”



That can be really challenging. To get buy-in for a more hybrid process, I would always try to show progress by tackling smaller projects for quick wins. That way, others could immediately experience the improved process versus what happens when a design team is battling priorities from a department that has nothing to do with the current product.

What do you like most about those different methodologies that inspired your design process?



Shifting the thinking so that every technical project must be rooted in an identifiable user need.

The other part I liked is that Lean, Agile, and Extreme Programming are all structured around momentum. And that means going fast, doing small amounts of work, and launching as quickly as possible so you learn from the real world.

That turns a design process into a much tighter prioritized set of goals. Instead of designing a complete architecture and launching all 150 features at once after 6 months, we launch two things next week and learn how to immediately improve.

Once you’ve shifted that mindset, it’s so much easier to follow a flexible process based on the project needs. Everyone ends up feeling good about their work, they’re getting constant feedback, and they’re shipping quickly as opposed to these death marches towards giant releases.

Grab design ebooks created by best designers

All for free

Download Download Download DownloadDo you want to know more about UI Design?

Download 'The Agile UX Best Practices Bundle' FOR FREE!

Download e-book for freeClose

What pain points did you face in your hybrid design process?



Flexible methodologies are always difficult to introduce to talented people who are already well established in their career.

When I describe this hybrid collaborative process, a lot of people can believe that it sounds like a waste of time and we should spend that time coding. You need to build trust in the team to say, “Look, we’re not typing at our computers for the next week, we’re doing work that helps us understand the problems we need to solve”.

On the other side of the coin, going fast all the time with sprints can be frankly exhausting. It’s like you’re sprinting through a marathon. Leadership needs to regularly gauge the overall sense of fatigue in a team.



Sometimes we needed to go a little slower and we planned a few sprints to pay back the technical debt we accumulated from moving so fast. You need those “payback” sprints because you want the team to feel satisfied with work that reflects their reputation.

For this hybrid design process you tried at Typekit and Adobe, how did you decide who was the product owner?

We always designated one person as the product owner, but that person wasn’t a pure product manager.

I tend to look for product management skills in developers and designers or even user researchers. For the product management and product owner role, I find people are more successful if they first have a strong background in a design or technical role and they’re shifting to this role for more influence over the product.

At Adobe, a lot of the product management were MBA types. It’s not a bad thing at all, but their method of working was around developing models, spreadsheets, and Powerpoint decks. Very little user research involved. They would examine problems like “What’s the total addressable market, and how do we achieve that?” Those questions are totally important, but your method of achievement must be based in user-centered design.

Therefore, in order to capture that market share, you need clearly designated product managers and product owners with a solid grasp of UX.

Jeff Veen at Adobe in 2013.



How can enterprise designers better sell the value of user research in an Agile process?



You can use some sleight of hand in the beginning of a project, and say “We need to work on all these big things. We need to develop some kind of overall architecture. We need to choose a technology platform. Oh, and we need to do a bunch of customer research to make sure none of that goes sideways.” You place user research in the same category of upfront work as technical scoping.

You also frame the research in a way that generates revenue.



When working at Google on their analytics and Adwords platform, I said “Look, we have to talk to people paying for AdWords and find out their reporting needs so that we can help them spend more money.”

As a result, we spent our first few sprints (a couple months) diving deep into understanding ad spending, online marketing, and publishing efficacy of customers.



We met with hundreds of potential customers in the agency world and in-house teams at large companies. When you listen to even 20 people with the same job talk about their role, and you visit their office and you see the sticky notes on their monitor and all the other workarounds, you see a ton of trends emerge. You analyze the transcripts of all of these interviews and say, “This is a task, and this is a task they do, and this is a task.” Group the tasks together and you’ve built a solid mental model and product architecture.

All without coding anything or designing any screens.



On the other end of that spectrum, how did you fit user research into the the process you practiced at Typekit?

Same approach. We did two large research sprints upfront to learn about web designers and people who design and sell type for a living, then continued to follow up throughout the process.

In the beginning, my cofounders and I would spend 30 minutes at a time interviewing a total of 40 users (Skype, coffee, etc.).

From those interviews, we learned about critical issues and had plenty of source material to adapt the rest of our design sprints.

At Google and Typekit, I didn’t write up a research brief with a protocol and a structured plan.  I just told everyone  “No, I should go talk to as many people as I can to figure out if I’m going crazy or not.”



In this hybrid process, did you run post-mortems and retros on a regular basis? If so, what format did you find successful?

We ran post mortems and retros all the time.

That’s incredibly important for freeing everyone up to be creative. You don’t look for blame or credit, but simply “What did we learn from what we just did”.

For each post mortem or retro, someone on the team was tasked with investigating the situation and returning with insights. They’d share them with the rest of the team for alignment, and then we’d dive right in after the morning standup.

The “investigator” would share the vetted results with the team, then we’d start an open discussion based on the 5 Why’s of Lean Startup to dive into issues discussed. We kept the post mortems and retros short and focused to prevent them from becoming a complaint session.

And of course, during post mortems for projects that failed, leadership needs to identify the circumstances, not the attributes, of the people involved.



What would your ideal design process look like?



I’m not quite sure I have a perfect process because there’s no perfect team.



The most important thing to remember is that a team is just a collection of humans. Humans have some combination of rational thoughts and emotional responses to everything. And every process must account for that particular blend of rationality and emotions.

Here’s the three key elements crucial to any design process:

A deep understanding of the people on your team.
From that comes culture, a clear mechanism for communication that everybody buys into.  
That culture encourages a sense of momentum in which everybody feels like progress is happening and they’re thrilled everyday to see the product get better and better.

The best process is a flexible process. Steal the best techniques from multiple methods, then adapt them to the context of your product and team.

That approach always scales over time.

What collaborative tools do you think help facilitate Agile UX?

I’m a huge proponent of any tool that facilitates collaboration and communication across teams. I’ve seen the power of this when working in highly productive teams who embrace tools like Slack or Trello or Asana.

But what I’ve been most interested in lately are processes and tools that encourage collaboration around design artifacts – the files that designers use to communicate their interface solutions or interaction flows.

As an investor, that’s where I think UXPin really shines: it allows not just teams, but whole organizations to seamlessly work on designs without emailing around images and haphazardly collect feedback. It’s super efficient and organized, and I think more and more Agile companies will be embracing this type of design-centered collaboration in the future.

Want more advice and case studies on Agile UX?

Download the 99-page Definitive Guide to Integrating UX and Agile. 

The post Integrating UX and Agile: Advice from Jeff Veen appeared first on Studio by UXPin.