Lately I've been loaned out to another group at my company, but not just to another group. I'm having to work with a third-party consultancy helping with a consumer facing application. They had already been working on the project for over a year when I came on board. Because the consultancy's design group was lead by visual designers and they didn't ask our EUX group about our process and tools, I've been forced into using Sketch and all of its accouterments.
Sketch is THE most miserable software I have ever used for enterprise UI design, followed by Abstract the version control I was forced into. I happen to be heavy-fingered on the mouse. Because of it, layers unknowingly move around on me constantly. Even when I'm aware, it can happen and I'm trying hard not let it happen. I screwed things up in a master library file royally. But I wasn't alone. 3 of the other 4 designers have done the same.
Sketch is probably quite fine for small consumer products such as mobile apps. But the moment you try to design a kitchen-sink, data-heavy enterprise application, it becomes untenable almost immediately. At one point, I had so many art boards in my section of the website application, that my Mac slowed because Sketch was using too much memory. Sure it can be fixed (which I did), but why?
Besides the misery of using Sketch there are some definite drawbacks using it:
No one expects a designer to be a developer. In other words, you don't have to be an expert. But learning HTML, CSS and possibly jQuery to design in, gives you an immediate ability to communicate with developers in their own language. This is the far most important benefit to designing with code.
Other benefits include:
Sketch is THE most miserable software I have ever used for enterprise UI design, followed by Abstract the version control I was forced into. I happen to be heavy-fingered on the mouse. Because of it, layers unknowingly move around on me constantly. Even when I'm aware, it can happen and I'm trying hard not let it happen. I screwed things up in a master library file royally. But I wasn't alone. 3 of the other 4 designers have done the same.
Sketch is probably quite fine for small consumer products such as mobile apps. But the moment you try to design a kitchen-sink, data-heavy enterprise application, it becomes untenable almost immediately. At one point, I had so many art boards in my section of the website application, that my Mac slowed because Sketch was using too much memory. Sure it can be fixed (which I did), but why?
THE PROBLEMS WITH SKETCH
Besides the misery of using Sketch there are some definite drawbacks using it:
- Communicating interaction design via Sketch is difficult at its best.
- You have to create many art boards attempting to show each step of an interaction.
That can still be and will be misinterpreted by development and product owners, who may be using your designs to write the acceptance criteria for development stories. - Additional documentation has to be written to describe interactions.
When that isn't understood or used, you have to have a lot of unnecessary conversations with developers, who may still not understand what you are trying to have happen in your design. - As a designer you lose control of the interaction design.
It's up to someone else's interpretation of how a design should work.They don't have anything that shows them how your design is supposed to work. Developers want to understand the step by step interaction. They have to interpret those steps into events to program against. If you're not giving them that, they're going to make up to what they think works best for programming. - It's just plain too slow to create design in.What takes me 4 hours to design in Sketch, takes me 40 minutes in HTML. I'd go back to my own office at lunch and redo my morning work in an HTML mock-up. Yes, there are some ways to enhance your speed through the use of "symbols". But, I've found even when I create some base page elements/symbols, I have to spend so much time manipulating them to show a slightly different form of them that it's just not worth it. Add on top of this having to duplicate art boards to show either interactions or modes of the page, a single change can take an hour or more, depending on how complicated the design is, to propagate to all the art boards.
- It encourages designers to forget interaction design.
Some designers just don't think about or think through the interactions if they're not forced into seeing and/or creating them. In Sketch, you spend too much time worrying about pixels and not how the user will use your app. And you should never lose the user from your work. - It's too easy to mess up your own design files.
The way Sketch's layering system works, it's too easy to move things around without realizing it. Photoshop's layering system is far better. And, when you use undo, it doesn't show you what's being undone which might not be so bad except that it doesn't have a redo feature. - It's too easy to mess up shared design files, meaning you mess up another person's design work.
I've been amazed at how easy it is to mess up someone else's designs by changing a master library file. Sure, you might think you're fixing a problem with a button or a label, but what fixes your problem suddenly breaks someone else's designs because they've had to work around the "broken" issue. I can't tell you how many times the required asterisks at the end of labels or button label wrapping break in my design after someone updates the master library file. - Sharing design takes yet another software, InVision, and that comes with its own sets of problems.
- Interaction design is still hindered.
We publish art boards to InVision where you can create click and navigate interactions.You can create more ornate interactions, but that takes even more time. Why would you do that when most of those interactions come natively in HTML? - Usability studies are problematic.
I've seen several user walkthroughs using InVision and I'm not impressed. Our discipline's motto is "Watch what people do, not what they say." Yet we are left having to listen to what someone says versus what they do because they can't interact with the design. - Developers really don't like the inspect tool.
InVision simply doesn't speak their language. While designers use geometrical shapes to design, developers use HTML. They want to know which HTML component, which angular component, which CSS class. While the CSS can be of some help, once CSS classes are established, little of the CSS is helpful and developers can't tell when something is an exception to an established class.
What I do like about Sketch is dealing with paths. It's far easier to design an icon in Sketch than any other software I've used. Followed by that is the ability to copy out the SVG information on those icons. Although, I still have to run it through an SVG compressor to get rid of all the unnecessary information and white space. But honestly, there are too many good icon libraries out there to pay for a Mac and Sketch to make my own.
THE BENEFITS OF DESIGNING IN HTML, CSS & JQUERY
No one expects a designer to be a developer. In other words, you don't have to be an expert. But learning HTML, CSS and possibly jQuery to design in, gives you an immediate ability to communicate with developers in their own language. This is the far most important benefit to designing with code.
Other benefits include:
- You understand what the limits or boundaries in which you're designing.
You are less likely to create pie-in-the-sky design where developers have to jump over major hurdles to create it. At the same time, if you can do it, it's hard to have a developer say no to what you want in your design. The better you get at HTML, the more able you are to help them create your design. - You will be forced into thinking what the interaction on a page should be.
What happens when there's an error? What about how different permissions affect the design/interactions? Should a button be disabled until the user fills in a text field? - You are able to show expected interactions for users.
Not only does this make you think more completely about the interactions, but you've then done all the upfront thinking for the developers. They just have to code to your blueprints, not think about the interaction for you. No need for documentation or tens of art boards for a single interaction. If you get a little more in deep with JQuery, you can start manipulating the UI for deeper interactions and use pre-created libraries for specific functionality. Developers will love you and so will QA. - You still have the ability to have shared resources between designers.
Standard style sheets and easy-to-use components can be developed and shared between designers, just like in Sketch. By being include files in HTML, you don't have a chance to mess them up unless you specifically go into the file to make changes. Most of the time in addition to a master style sheet you use a style sheet for your own application where you overwrite the master styles for your own needs. No accidents or messing up someone else's work. - You have the ability to use development shared resources.
At my company, designers create the base CSS files for a brand new app which are then handed off developers. At that point, developers become their curators. Since we use the same files as the developers, we share one language as far as style classes go. Then it becomes easy for a developer to tell where we have exceptions to the standard style sheets. - You don't have to have expensive software to write HTML, CSS & JQuery and you don't have to use developer-centric software-on-steroids. I personally use Notepad++, a freeware, but there are other freewares that might be more intuitive for you to use. You can use GIT as a repository and version control just like developers. You can put a web server on your own machine or you can have a shared server. At my company we have both.
- You have an immediate experience for business/product owners to try out.
Will they be as perfect as development's? No. But having something that works helps to drive out more requirements and more discussion around how something should work and what the experience should be. - You have a working mock-up that business/product owners can show to customers and upper management to drive buy-in at other levels. Believe me. They really like this.
- You have a more dynamic and real-to-the-end-product mock-up you can use in user testing. Users can do more than just navigate from place to place. And if you learn how to use JSON to store data like a database, you will be able to use data from your actual customers for testing.
One of the continual counterarguments I get about creating HTML mock-ups from this third-party's employees is "But what if the developers use this?" This argument comes amazingly from architects and developers themselves.
Here's the thing. Yes, developers are going to use your code and the more they use your code, the closer you get to what you want. But, good developers will be able to look at your code and know what of it is production-usable and what code is not. It should act as a scaffolding for them. If you have developers who are wholesale using your work without doing that review, then they are poor or inexperience developers. Don't ever let a developer blame you for them doing the wrong thing, not keeping you from creating HTML mock-ups.
Finally, there are far too many benefits to creating design in an HTML mock-up. Don't limit yourself and your role by using tools that limit you and your ability to create the best design for your user. As UX designers, we create the entire experience. Not just the visual design.
Here's the thing. Yes, developers are going to use your code and the more they use your code, the closer you get to what you want. But, good developers will be able to look at your code and know what of it is production-usable and what code is not. It should act as a scaffolding for them. If you have developers who are wholesale using your work without doing that review, then they are poor or inexperience developers. Don't ever let a developer blame you for them doing the wrong thing, not keeping you from creating HTML mock-ups.
Finally, there are far too many benefits to creating design in an HTML mock-up. Don't limit yourself and your role by using tools that limit you and your ability to create the best design for your user. As UX designers, we create the entire experience. Not just the visual design.
Comments
Post a Comment