In this Codecast, Jane gifts her expertise, strategic insight and tons of resources regarding key aspects to define when creating a product. She also discusses the importance of resolving user pain-points first, before creating a "flashy" design and offers a great reminder that the often edgy rub felt between developers and designers is useless and meant to be to a mutually beneficial collaboration!
Key Theme » Simple Solutions
To be successful the product doesn’t need to be "creative", it doesn’t have to be "innovative" or whatever the terms people apply to designed products. They don’t have to be like that. They just have to conservatively solve a painful problem for the user. That’s it, and it can be done through a very, very simple UI. – Jane Portman
"If the product solves a big enough pain, such flows in the UX are not critical anyways, because users will fight their way through to solving their problem. So really, the biggest important thing that founders need to nail is the product/market fit which is matching the audience with the problem they are experiencing, and the tasks. Everything else is just visual polish."
"The recipe for success in larger companies is to build a small success story which would allow for a success narrative to appear...Also, across a team of designers or across people from multiple divisions, you can get them all together and try doing basic UX exercises. Like putting together user stories, building user profiles, something like that. Working with cards on white paper so that everyone gets relaxed and focused on that and also invested a little bit. In this way you can slowly instill UX appreciation into the most hardcore traditional UX agnostic structure..."
Full Episode » Transcribed
Hello! Welcome to the Viking Codecast, back from hiatus. My name is Erik Trautman, I’m founder of Viking Code School and we are a fully online, immersive and now part-time web development school where we teach the fundamentals of software engineering and prepare people for a career in software.
The Codecast is a weekly series where we bring in experienced developers to give all sorts of interesting, eclectic knowledge from the other side of the line – life behind the curtain and the perspective of all sorts of interesting stuff and occasionally some really useful tidbits on everything from careers to technical topics. Every now and then we are lucky to be graced with someone who has a little bit of experience in the design side of the world and the product side of the world, as we do today.
So our guest today is Jane Portman, who’s definitely probably more tired than she looks, (laughs) who is out in Russia right now.
She runs the UI Breakfast and is going to talk to us all about different things along the product spectrum, which again is something that we don’t always get to hear about and it’s definitely something that’s really, really important for developers to understand and for engineers to understand working as part of a team.
I am really excited to hear from you Jane, and welcome aboard to the Viking Codecast.
Thank you for the nice intro Erik, I’m thrilled to be onboard. Can everybody hear me well?
Sure can. I guess as always, kind of the first question I’d love to pose to you is: just how did you get to where you are right now and what exactly are you working on these days?
Alright! I’m a UI/UX (User Interface/User Experience) Consultant helping SaaS founders build nice, simple, focused and profitable products. That is, I’ve been a designer all my life. (Laughs) Over the course of eight years up to four years ago. I spent eight years in an agency growing up from a junior UI designer towards a Creative Director.
Then I had my first son and I realized that I didn’t want to do agency work anymore, I just want to do my best stuff and I made a big goal of conquering a line of clients in the US market. I started out doing all kinds of work, spent a year on oDesk - that forbidden word. I quickly realized there is very, very low ceiling there, and started building my authority.
I started out with a book called Mastering App Presentation, which made me zero money but was a perfect way to get good clients way better than oDesk, and started going to conferences, blogging and podcasting.
Got on the ground with product (inaudible), as well. So these days I consider myself a pretty well established consultant and just launched my new book called The UI Audit, which is not even a lead magnet for my consulting work. It’s a self-sufficient product helping founders solve their design problems.
I love helping people about design, and my angle is functionality, product strategy, and all kinds of things that make products not just pretty but really functional and easy to use.
Cool. So, there’s a wealth of things that engineers could learn that are obviously important to their careers, coming from the product side.
Typically, the reason you’re building something is because there’s a product and I think that’s under-appreciated a lot of times. All you really want to do is work on a challenging problem and get paid for it, somehow. It’s very easy to forget that oops, there’s a product leading the way.
But on the other side I know a lot of our audience is really curious about designing their own products, about starting businesses, about joining small startups or starting small startups.
Phase I – Blending Design & Strategy.
So, the first thing I’m interested in is given the work that you’ve done so far, working with lots of different companies: where do we start about thinking about the meaning of product to someone who is technically oriented?
Alright. First I’d love to give a compliment to all technical founders and developers who are doing any kind of UI/UX design themselves, many hacking products together.
You actually make really good UX design most times, not fantastic but very, very sensible. Because you have that logic how everything works and you also have a ton of experience working with other software, and you have that library of patterns in your mind which you don’t even realize most times. Which allows you to be more successful than non-technical founders.
Sometimes you can just see whether it was a non-technical founder or developer building the UI. So, kudos on that! (Laughs)
And really it’s not that hard to build a UI. It’s all about a few very simple things like: if you object-list simple navigation, etc.
The hard thing usually is to make sure that this is exactly what the user needs. That’s where product strategy comes in place. One of the big topics for today was "Product Strategy", shall I dive into that?
Yeah, you mean we can’t just build it and they’ll come?
Kind of, yeah - there are so many apps out there still waiting for the audience and that’s not the place to be really.
4 aspects of product strategy.
So, my method of defining product strategy consists of four parts. (Audience. Goals. Tasks. Objects.)
It is audience – the number of people you’re building it for.
There are big goals that they are striving to accomplish with your app.
Daily tasks they do when they log into your app every day
and, objects that they manage within them.
The combination of these objects – it’s pretty simple, but when you write down you instantly realize who you’re going to be targeting, and what exactly you need to facilitate most.
Sometimes it needs just a few guiding principles to rule your decisions. Such strategy should definitely be like hanging on top of your hat above your desk somewhere so that whenever you’re trying to optimize a screen, to decide whether to use a feature or not, just look at the strategy and see whether it aligns with it or not.
So if I’m running a code school, online, how do I begin to think about approaching these four principles, like where do I start?
1: Define your audience.
Of course you start with an audience, right? (Laughs) It should be a group of people who you’re building it for and actually it’s quite scary to niche down, but it’s rather necessary.
You need to make sure that you know these people well, you know what they need. You know that they have a problem that you’ll be solving, and you also need to be sure that they can pay you afterwards. There are some kinds of audiences that are specifically not used to paying, especially consumer apps people who do the entertainment part of the life, it's very hard to make them pay.
So you want to make sure they can pay you, you want to make sure you like them, you know them, and that’s rather important because that’s going to define the next three items.
Okay, and then where do I go next?
I understand my audience.
2: What's their goal as a user?
You need to figure out what is the big goal that they are working towards. So for the code school, that would definitely be building your own business as a developer or getting a superior job or whatever it is for the majority of the students.
3: What daily tasks do users need to complete?
Let’s look at the daily tasks. People want to consume lessons, they want to browse your agenda - what else do they do? (Laughs)
Anyone here who uses our site - what do you guys do daily on the site? Any volunteers, for a little bit of user research?
I guess, readings and, not code challenges, but code assignments – and guidelines for those.
Okay, so you’re consuming a lot of information, definitely.
4: What objects are they interacting with?
Alright – so the first step would be figuring out what objects we are managing here, and usually there’s going to be a list of (nouns), and you could just browse through the previous list of tasks, you’re going to see what (nouns) you’re using there and very, very likely these are going to be exactly the objects you are managing in the app.
Can you talk a little bit more about what you mean by an "object?"
Object – let’s say it’s a project management app.
So the objects here would be: projects, clients, files, notes, messages stuff like that. It really depends on the scope. It helps to define the whole structure of the app both development-wise and UI-wise.
That’s interesting because it sort of comes in line with the ERM approach, the Entity Relational Modeling stuff.
When you design a database from the very, very bottom, the guts of the app you need to make the same considerations, right? As when you’re designing the front end UI.
So a lot of what we teach is about the back end. It’s about identifying - sort of starting from what we’ve been given by the UI, so a lot of times we’re given a mockup. The mockup has a whole bunch of stuff in it and we have to sort of dissect it and say: "okay, hold on, what does it mean to have a blog post and a bunch of comments and a bunch of users and tags," and things like that. Then sort of pulling that out and then turning that into some sort of database object.
So you’re talking about it from the other end, which is sort of from the perspective of someone who might actually be creating that mockup. So it’s really an interesting shift in perspective.
Can you dive a little bit more maybe into how you break down these user needs, and then turn that into an actual interface and how you think about that user interface, that UI?
Phase II – Managing Objects.
Alright. So once we write down these things we need to figure out what exactly our app is going to contain.
The essence of any web app is managing those objects that were listed. Usually these come into the shape of some kind of data tables or lists or something like that and the tasks that are going to be run down are going to take place in the context of this list.
So, my primary strategy for building simple apps is a rule of thought - one data table per page so that everything is super simple and obvious – not like piled up like we often see.
So it’s one table of objects per page or one object per page, and the other thing about navigation it also should be build around objects, not tasks. The most common mistake is people trying to pile up action verbs in their navigation and that’s a really, really big mistake because the number of objects we’re managing, it’s large but it’s quite manageable. But the number of actions we can do around them is literally infinite, like we can add, edit, delete, create, whatsoever and a ton of other complex tasks.
So while you’re building your app you need to just train the user where these things go, where they lead, and then just make sure that all their remaining tasks are obvious from there.
It’s a combination of actions you want to promote, tasks, and objects that we are going to be displaying within our UI. I hope that’s clear.
I was actually just going to say: do you have any examples where that might be the case?
Something concrete that we could sort of think around exactly what it means to differentiate in your nav between the objects and the verbs that you can do around those objects? Maybe from one of your prior projects.
Right, let’s take that imaginary app, project management app - so the items in the navigation should be as simple as projects, contacts, maybe files, something like that.
Each item should contain a very simple list and all the actions around them should be accessible from that very least. What we can do with them is really a huge number of options. A big mistake is starting to add verbs there. For example “add new” is a very popular thing that ends up in the navigation and it is not a very good pattern, because once something is added the user kind of doesn’t know where it went and where it leads.
You need to train them to go to those primary locations, and big mistakes that I see also quite often, is trying to replace navigation with the dashboard itself.
People rely on dashboard a ton, but while the user drills in just for the first level of work, the dashboard disappears. Nobody sees that tiny little strip on top, so they should really be well trained for the common place for things to lead, and know exactly where everything is, and they can come back any time and do their editing or whatever they need.
Do you have any links, anything that you might be able to show maybe on your website. I’d be happy to navigate to it just to give people a visual that maybe they could see?
Alright, would you wait a second? I just published a blog post on navigation, let me see.
Also, there is a series on my site called UI Practicum where I dissect separate UI problems, and I can also point you towards that.
I am now sharing your post. What can we take a look at?
We can scroll down definitely, this thing that we’re viewing here is that explanation why exactly it’s good to build your navigation around objects, and not tasks.
Why is that? Can you kind of explain what’s going on?
So the important message that this image conveys is that it’s complex! (Laughs)
There are only three types of apps, and now I just added all the actions we can do with them and we see the overwhelming number of actions possible. If you try to add those rectangle items in the dropdown menu or something like that, you’re going to end up with a real big mess. So what you want to do instead is just very simple navigation, which looks like the (circular-shaped) items labeled: project, content and files.
Aha. So in the prior work that you’ve done - what have you found to be the biggest mistakes that clients will typically make when they call you in to help them either develop a new UI, or improve the one they have?
Common UI mistakes.
Yes, so navigation mistakes are definitely number one, probably. Number two are very common mistakes about data tables.
Data tables are essentially the core of the app most times, and the controls that people pile over all of these tables – the controls are really a big mess, while things definitely should have common places. Let me show you the link. Just a second.
Okay here is a blog post on my site, there are some illustrations there.
Okay, where do you want me?
This picture is great.
So everything should really be very simple. There is a data table there. So filters are- list text here controlling what we’re going to see should go top left, and small settings, fine tuning of the way things are displayed should go on the right. The "WHAT" block, if you can see that – is on the left and the "HOW" block is on the right.
So everything related to "search" or "dropdown" filters should go there. Here is an image illustrating common problems with tabs.
You can see that people have a ton of problems using tabs because they don’t realize that everything below the tab line should relate to the tab header only, and everything above the line is common for all tab areas.
This is rather simple but you see a ton of mistakes around that. Also people like to mess up with common controls.
Here is an arrow that points to the right, the tab to the right of the tab's placement - this is a very favorite place for people to put stuff into and definitely nothing should go there because it’s not obvious what exactly this relates to. Whether it relates to all tabs, to stuff below the tab, or whatever. It’s just not a good practice.
If you’re working on a team that’s working with engineers, are there any issues that engineers often have that you run into as someone who’s coming in?
I don’t know if you’ve come under projects that never had a designer or product person on them where it was just engineers. Are there any pitfalls that you typically see that engineers get into?
I don’t know, I think what we just described is exactly what engineers do. (Laughs)
My favorite kind of project is something that has been hacked together with a theme, has been live for like a year, has a stable flow of revenue already and generally is validated. Meaning, it’s already an accomplished project it just really lacks the polish when it comes to UX. So these are my favorite kind of clients and I see these kind of mistakes very often.
If the product solves a big enough pain, such flows in the UX are not critical anyways, because users will fight their way through to solving their problem. So really, the biggest important thing that founders need to nail is the product/market fit which is matching the audience with the problem they are experiencing, and the tasks. Everything else is just visual polish.
As founders say, it was probably Ankur Nagpal of Teachable who said that: "the product goes through several stages, from being not ugly to actually being beautiful." The first, not being ugly, is totally enough for the product to exist and to be successful. For that I usually recommend using themes – a ton. That’s hours and hours and hours of design work, condensed into a single piece which you can never hack together, just being a developer.
Can you kind of explain what the idea of a theme is and where to find them and how to use them?
Bootstrap themes, stuff like that, admin themes? I’m sure you’re pretty familiar with the frameworks and how they work.
So it’s a quick way to hack together any kind of UI. Of course there are some problems with the themes because they are usually loaded with stuff. When you apply it to simple projects, you ask: "where are all the bells and whistles, where’s the fancy dashboard? How do I get like 20 perimeters in the map over there if I don’t need it? Like, what should go on the dashboard?"
That’s something very common – but other than that, simple table styling, all stuff like will get you to your MVP end pretty well.
Do you have a favorite theme or a favorite framework to use?
No, not really. In my book I send people to a couple sites, I don’t quite remember which of those. I did some research and as my friend said, "no themes are created equal." If you don’t like the framework itself you could still pull HTML, CSS, just the design and apply it to your own scheme of things, as well, if you don’t like the whole thing. It still works, because a designer made those.
Appreciating a design and being able to recreate, say typography from scratch, these are two different skills. Probably most people can appreciate stuff, but probably cannot create it from scratch. (Laughs)
I think something that we run into quite a bit with new engineers, and I’m sure there are those that are here right now and then there are those who are in the audience who can probably relate to this.
Which is the engineering instinct is to always create everything, because the creation is great! (Laughs) But engineers are almost, especially engineers who are very logically oriented for back end focused, and kind of dive into the nitty-gritty of code, there tends to be a bit of an inverse correlation between that and design ability and front end coding ability.
It’s always, we teach some front end CSS frameworks as well, like Bootstrap as part of the curriculum. Then the goal of that is definitely to say "don’t worry about it. It’s been solved, as long as you don’t fight with Bootstrap you can do just fine." I’m glad to hear you're backing us up on that.
Great UI design first solves a problem.
Absolutely. One more thing I want to just make sure everyone understands, to be successful the product doesn’t need to be "creative", it doesn’t have to be "innovative" or whatever the terms people apply to designed products. They don’t have to be like that.
They just have to conservatively solve a painful problem for the user. That’s it, and it can be done through very, very simple UI. Your goal is not to develop bells and whistles around it, or whatever.
So before we go any further, I want to open things up for questions.
I see, let’s populate it with some questions.
John, were you ...?
Yeah, I have a question and I hope Jane can handle however she’s fit, but it kind of goes a little bit towards motivation. In particular, are you familiar with Ryanair and some of the things people have talked about in terms of their UX and what they do and so on so forth?
I don’t think I’m familiar with that, sorry.
It’s this cheap airline based out of the UK I believe, and I don’t know all the details. But my understanding of it is, they have this notoriously bad UX wherein, if you don’t find the little tiny print and check some box correctly, then your credit card gets charged for like, 40-pounds of travel insurance that nobody wants.
For people who teach UX it’s always like: "this is really bad and don’t do this." I guess in terms of motivation I always thought, "it’s not that they did that by accident, right?" They did that on purpose because at least at some level, it worked. When I look at the internet nowadays, I just see so much bad UX of that same type.
Do you run into that very much I guess in your own clients? That’s something I just see that people are - there’s kind of this war between the users and the content providers and I think the UX people kind of get caught in the middle.
Is that something that you ever have encountered or have any thoughts on?
The business challenges within user experience enhancement.
I think, yeah, it’s a very wide question and wide problem and it’s not really a war.
Business owners have so many things on their plate that some mere UX is not usually on their top list of priorities. So whatever ends up on these pages, especially corporate pages, and especially things like airlines or whatsoever, there’s tons of bad UX there and that’s alright. You have to live in this world.
In the unsolicited redesigns, they are also quite unsubjective because you never know what kind of committee was there to take all those design decisions that we see on that page.
You never know what requirements were made, you never know what technical limitations were there – technical limitations are probably off topic. But it’s huge, design-by-committee thing – distilled five times after it’s been originally designed by some poor soul.
Really, it’s a big battle between corporate management and designers because corporate management tries to instill their timing of design and whatever ends up is just a result of that. It’s definitely not a war between designers and users, definitely not a war between businesses and their clients. It’s all done with good intentions, it just ends up as a monster sometimes.
There’s a saying that "a camel is a horse designed by committee" or something like that.
(Laughs) I like that one.
There might be, let’s say they invite you for a redesign. I've not been in this position because I usually work with businesses who are kind of UX aware and if they pay a lot of money to me that means they are already doing something in design, and are ready to undertake changes. But maybe, there was such a political challenge doing something that the UX just came flying by and never got approached well. Then also in such big environments, the gap between the designer and the final user is so huge that you can really, really hardly task-iterate and do whatever best practices are in UX right now.
A few months ago, I just had a chat with someone from a huge corporate environment printing credit cards and stuff. The gap between feature implementation, like the way the UX concept is brought in – and the way it’s implemented, it’s like a few months. If you try to iterate it’s going to take you a few years to nail this one feature, and there’s a ton of features to work on. It’s a tough thing and it’s not a war. It’s just a process that’s just not very efficient. I hope that answers your question, to some extent?
Alright. So with that in mind, actually with the idea of iteration in mind. Are there ways that if you’re working to design an interface and maybe you don’t really know a lot about your product, it’s definitely in the barely beyond ugly phase, is there a way that you can do that so you leave room for future iterations? So you don’t lock yourself completely into one design, set of design decisions or navigation options, things like that?
Design for continuous improvement.
There is definitely - there’s always room for improvement. The design that you ship it never really ships - it’s never really coded up the same exact way and just by the time the feature is delivered it usually looks a little bit different already. There is always space for improvement, and for some tweaks and for changes in strategy. It just depends on the strategy. I should say, it more depends on the business owner rather than the designer, because we’re merely brought in and really cannot control the time when they are going to address us back and come for feedback on something that they do.
I used to have a product called Correlation in which I was a monthly Creative Director for SaaS companies. That’s where we work together with a business on an ongoing basis and we got together every month and reviewed what they did. Even then we had so many things to work on that really didn’t iterate on something too much. We just addressed different problems in their business. It was still better than a regular, come-and-go design gig.
So, I do have more questions for sure but does anyone here have anything that you guys want some clarity on?
I have a question on clarity. I’m curious, I have peers and friends in the UX design industry and I have worked with a few of them and sometimes, at least in the United States, I’m not sure how it is in Europe or in Russia, but there’s a curious little dynamic around being very specific between what UI is versus UX.
Sure, that’s what everybody asks. I even get like booed by my audience saying, "you’re saying it wrong, it should be UI/UX it should be UX/UI." (Laughs) I’m like whatever you say.
These are just wide concepts and last year I wrote a book called Fundamental UI Design, so I spent like a week defining these two to make sure I am politically correct because that was the first time in my life I had to sit down and define these.
The UX sphere is much wider than UI itself because it involves, whatever we see on the screen, whatever goes in our minds, the whole process and flow and also ton of other subjective factors. Like support service, is also part of UX because that’s what the user interacts with.
Do you mind actually defining what those acronyms are just for the sake of our audience?
Defining the distinctions between UX and UI.
User Experience is UX and User Interface is UI.
So User Experience (UX) is everything that the person goes through and the ultimate goal of user experience is making the user successful and making them feel good. While the User Interface (UI) is probably more a visual term. Its origin goes back to Human Computer Interaction (HCI), when it just started out (more than) a couple of decades ago. It’s about things that people see on the screen and visual components.
Sometimes UI refers to the functional side of things, so it’s wireframes. Sometimes it means visual design which is high fidelity layouts and styling. Sometimes it means coding up stuff, so it can mean a whole range of things when it comes to actual craft. People working the field also have a whole range of craft and skills. I have never met two designers with a similar skill set because everybody has different kinds of things going on. Someone is doing wireframes, sometimes it’s mockup and sketch, someone doing that directly in code. Myself I can’t code, even though I have an education for that, I really regret it. If I could make my designs, bring them life I would probably be one of those people who are considered dangerous (laughs) when you can do the full cycle from starting from the concept to implementation. But unfortunately I have to rely on my developer friends.
Answering that question, UI is probably more the visual part of things, what exactly goes onto the screen, and UX is a wider range of concepts. I really, really think that people just spend too much time speculating what exactly this things means instead of just building good stuff. For any articles that makes the difference between UI/UX, if they just focus on something more practical that would definitely be more beneficial. That’s my standpoint. Less speculating more work. Just build something instead.
Definitely, I think I have one quick follow up question - in terms of the UX portion of it, how critical do you feel it’s important for teams to engage in user experience research?
Good question. I think that UX is not only about research. UX is generally about how things work and I do think it really consists of - let’s say 70% is best practices, how things are classically done, established patterns, etc, etc, and the remaining 30% is testing that, doing research and validation, etc, etc.
I think it’s incredibly important in terms of validating the product, making sure that the user do experience the pain that we are going to solve, but I think the importance of research is a little bit overrated these days. I have seen teams who are very good at research methods, they can do all kinds of exercises but the actual design they are iterating upon just lacks quality, initially. It’s not a good thing to iterate upon something that is not good initially, really, because you should just go and improve it first based on regular common sense. I think it definitely important but you shouldn’t rely on this, solely. You should build something good first and then iterate on that using research methods.
That’s my very, very painful problem. That’s why I’m so wordy about it.
How do you mean exactly?
Because smaller businesses and I come from the "bootstrap" system rather than funded startups, with smaller businesses they usually don’t have that much funds for research, like at all. They don’t have time, resource and money for that and you have deal with whatever is onboard. When you go read articles, it seems like everyone is living in that pink ideal world with unicorns, where everybody's testing out of the blue! (Laughs) That’s really disappointing sometimes.
There is a big extreme that people run into with testing everything. Sometimes it’s just good to trust someone’s advice and just do it instead of testing all the little things. Testing really, really depends on the amount of data that you get and for smaller businesses it’s not statistically significant to count on these results, most times.
Thanks. Did anyone else have questions here before I launch into mine?
So one thing you mentioned was that if you could code you would design, you would take your designs from zero to implementation which in our book makes you a unicorn. (Laughs) But given that you can’t, you were talking about working with your developer friends.
One thing I’m kind of interested in is what is like, from your perspective working with developers, how does that work flow look? What is almost a typical day in your life on a project where you’re collaborating directly with developers?
I’m actually not collaborating with developers, per se, as if I would manage them from my own project. Like my own five year plan is to become a SaaS founder myself, that’s exactly where I would work with developers in that sense, that I would have to really manage their work. Now it’s more like a side by side friendly collaboration. So I mostly direct with the founder, and they give away instructions to developers in a waterfall manner, sort of thing.
One of the things I do, like one of the most painful steps is going back to the life product and pointing out a little inconsistency in design implementation like spacing here, font size there, like that color is not exactly the same, the margins need to be different, stuff like that. These little details they make sense usually to designers only when they’re all together they kind of are responsible for the whole visual polish of the thing. It’s really, really worth the time and money to go back and polish this stuff if you’re aiming for high quality design.
It’s always very painful because it’s tough – it’s a very painstaking process. There is a very nice guide by a company called ustwo called Pixel Perfect Precision, something like that and it’s a really, really nice document aimed to bring developers onboard with design fundamentals so they can more precisely and correctly bring up designs.
Let me see if I can drop a link for you - it’s pretty old, they are updating it from time to time. Here you go.
It’s ustwo.com/ppp, just for everyone who’s watching and listening, or reading the transcript.
One thing I wanted to ask, when you’re interacting with developers, you were talking about that phase where they’ve implemented something and then you’re kind of coming in to do some quality assurance and make sure that it actually looks the way that it’s supposed to look.
Does it ever work the other way around? Like are there times when a developer or an engineer is going to pushback to you and say, "well that looks really pretty but we can’t really do that with our constraints," or there’s some reason why it’s not really possible. Are there occasions where that happens where that’s a good thing?
Usually not in my practice because my favorite part of the job is making things easier, so I usually rely on common practices, coming to see a mess of things and controls and I try to do the same exact thing with the same exact controls just in a way more transparent manner. It’s not like they would object to simplifying things. (Laughs)
I also am not a big fan of "rocket science", tech–intense components which would require weeks of coding. I’m more up for traditional patterns that have usually very obvious implementation.
Sometimes it’s alright if not all the bells and whistles are implemented, not all fancy interactions are in place for the version one, but that’s fine. I've really matured to be kind of agnostic to these things, not take it personal. Whatever happens is fine, as long as users like it.
Cool. Other questions from the audience – any UI’s you guys want critiqued?
I actually have a question, I came late, sorry I may have missed this part. But do you consider metrics in terms of UX/UI like load times and like responsiveness, does it work on a smaller form factor, like a phone screen? I imagine that comes up in the engineering / testing part of the UX. Do you use those metrics in a way to iterate on future designs or does that come up in something that would be categorized under user research?
I personally don’t go that far into technical implementation of UX. I’m more in the top level of these things, like product strategy and best practices, rather than those metrics that you describe. There are definitely specialists out there who do this kind of research so I cannot really give a qualified answer to that. But it definitely takes place.
The design process is messy, apply simple remedies.
I want to highlight that in real life products and problems, it’s never that precise and it’s never that perfect and it’s never that “play by the book” when it comes to the building process. It’s usually like very haphazard and things are built in such a messy manner that any kind of UX improvement is already a dramatic implement even if it’s not powered by dramatic research.
Cool, thank you. I guess I had another question.
In a larger company where many UX and UI people, how do they - I know there’s probably a diverse way of doing things, but from your experience what seems to be like a good way of coming up with a nice UX – as in what’s a good workflow? Do people come up with a consensus in terms of what things should look like, or is it just generally accepted best practices, "oh we should just do that", and everyone just agrees to that?
You’re exactly right, it definitely varies from team to team dramatically. I have a podcast and we just talked about UX leadership and the way you approach UX in large companies.
Because in large environments - when it's not like some creative agencies when everyone is so onboard with a great design – but when it’s a big, big enterprise structure, how do you make sure that a single UX person or design department makes an influence? The answer here and I think it should be valid for any company – is getting everyone involved into UX research practices, so that when people are involved in something and they commit their own time and energy. they become invested. Therefore always more considerate and always advocating for it, as opposed to against it. The recipe for success in larger companies is to build a small success story which would allow for a success narrative to appear, and then go to your next boss with that so they can do something else, and then they go to their boss with the same successful narrative so that they can promote that in terms of funding, etc.
Also, across a team of designers or across people from multiple divisions, you can get them all together and try doing basic UX exercises. Like putting together user stories, building user profiles, something like that. Working with cards on white paper so that everyone gets relaxed and focused on that and also invested a little bit. In this way you can slowly instill UX appreciation into the most hardcore traditional UX agnostic structure, let’s say.
Let me drop you the link to that podcast, too. Just a second, it’s a really, really good episode I recommend it to anyone. I hear it all the time what kind of problems people have and the number one problem that all designers have within big structures is actually making people appreciate design.
He’s very friendly! (Laughs)
He’s a Lead UX Designer at The Economist in New York, and he’s been leading mobile app creation from scratch. The Economist is a very, very rigid large company without any design practices. So we talked about that.
I’d be really interested to hear what is a project like for you? If you come in and you work with a client who’s asking for your services and asking for some help with their user interface or experience, or product strategy.
Do you have an example of exactly like what one of those engagements looks like for you, maybe one of the past ones you’ve gone through. Sort of, how does it start, how do you - what is the problem that you’re really trying to solve, how do you solve that problem and then how do you interact with existing teams?
Maybe not like "a day in the life of you" but maybe like a "month in the life of" you?
Jane's workflow process as a UI/UX Consultant.
I’ll try. I have done my best to standardize the beginning of engagement because I am really, really focused on UI audits. I have a book called UI Audit and I have a consulting offering called The UI Audit – let me drop a link so that we can kind of explore it, if you're curious.
That book is the consulting thing that I’m doing. It’s a report that I put together, takes like a few days to do (inaudible), so I put together a strategy report and I also tiered key screens in the app and defined what are the biggest problems that we should be addressing here. I don’t do any kind of hands on design work here, I’m just applying my best knowledge to see what the problems can be. Then the next stage would probably be wireframing, because after that people are often terribly curious. So what would be the right way of doing that, that’s the wrong one. I did try my best to release all the quick ones in the audit report, but still sometimes it requires hardcore wireframing work.
So the next stage would be wireframing, when we take the key features in the app and do wireframes. I use Balsamiq for it, which is a very nice tool. The founder is also very awesome. So we do wireframes and then I also like to include plenty of explanations there. Here are some of my wireframes in the article and the ones that clients get are even more complicated, but also very nice.
And after, that there is a way of quickly styling an app which is putting together a style guide. Which is essentially library of visual elements that you can use to shape the whole app without drawing up like 50 screens. Just because you have the set of necessary elements, the tables and menus and forms are styled. Then you can just assemble everything together. That’s a quick way of styling or I can do better and do high fidelity mockups for you, but it’s been a while since I did that because I really, really shifted my focus towards the strategic part, so it’s like a graph would be like that.
The majority of the clients like that, they would get the audit and some of them would get wireframes and some of them would like visual design. I do love doing visual design a ton and I used to be creative director and I love it, but I see that it’s not the primary value. The primary value is really making the product function right, so it’s more about the strategy these days.
It’s not exactly one client’s story, because they do range a ton. (Laughs) But I do hope that answers your question.
Yeah, yeah, thank you. I just wanted to get a little bit of what it’s like to work with someone like you, maybe so the perspective when it’s inverted they’ll have an idea of who is this person who’s coming in to work with our team and help us make this thing not look awful.
I’m a big fan of productized consulting which is selling your services with a long form sales page, describing everything, the value of the process and everything to the client so they don’t have the questions that you just answered. Getting into a relationship with a designer is a very, very risky thing and I know, I understand why people think so. They want to make sure I know what I’m doing!
They don’t know what the scope is, they don’t know what they need, they don’t know how we can even tackle that, not to mention the price and whatever else. Putting price tag on things is a really good way of doing consulting and I really recommend that approach to anyone who is doing consulting work in the future for you guys, it’s really good. Even if it’s in an expensive price label, it’s still better than losing clients because they are scared.
Would you accept more links from me?
Just a second. I have a very, very nice webinar on productized consulting because I think that productized consulting is a very important real life skill. So this webinar, it’s called Productized Consulting for Designers, but it’s definitely applicable to developers as well because we are going for how to put together an offering, and stuff like that.
Alright, does anyone else have anything? Any parting notes, parting words?
I do have a few words, though. I’d love you to take my free course if you’re up for it, it’s called One Hour UI Audit. It actually recaps on everything that we discussed today, it walks you through the process and if you ever decide to buy my book which is called The UI Audit I prepared a special discount for you which is 30% off by using code Viking30.
There you go.
Thank you. Alright, well thank you so much for chatting with us. I hope everyone here, you found it valuable, everyone who is listening at home, who has gotten this far, I guess you must have. Thanks for joining us for the first Codecast back from our intermission. Jane especially thank you for being with us at this ridiculous hour right now.
Designers and developers make love not war, seriously! (Laughs) It is a great match of skills.
Alright, well thank you so much. Thank you everyone for joining us, come on back next week and we’ll see you guys around. Thank you.
Contacting Jane + Resource Links
The UI Audit Book, with 30% discount use discount code viking30