11

What's Your Web Design Approach?

3 years ago from , Visual Designer/Developer

I want to change my web-design process of wire-framing, design, and code. It is out dated and slow. I am curious to see how others more experienced than me handle web-projects from start to finish.

21 comments

  • Andu PotoracAndu Potorac, 3 years ago (edited 3 years ago )

    It's a bit of trial and error depending on the project. Sometimes I skip some steps for obvious reasons. I'll share them here hoping this process will improve / be adapted by others.

    1. I always try to answer this question: my site/app needs to ___. And I always keep in mind the concept of Maja - depth, utility, beauty.
    2. Sometimes this helps to create a brief - http://www.black.design/
    3. Design focus research (usability testing, ethnographic studies).
    4. Brainstorm - What is the problem we want to solve? What is the solution? (find the right solution and features)
    5. Prioritise ideas (MVP), focus on only one feature and 2 sub features max, that are necessary to make your core product work.
    6. I create Personas, proto-personas, scenarios storyboards - interview potential users, surveys, talk with potential users. (who they are and how the product will fit in their live) - goals answers the WHY question, and not the WHAT question.
    7. Then I create user stories using the person at #6. I don't go too much into detail, something along the lines of: As a [… user persona ...] I want to [… accomplish something …] so that [… some benefit happens …]. Example: As a parent, I want to sign in so that I can access my child’s grades and related info.
    8. Create User Flow Chart / App Flow Diagram / Sitemap (this looks messy :P ).
    9. Content (interpret and communicate the content - the design must reflect the spirit of the content) - unfortunately many times is auto-filled in Sketch and not many customers understand the need to provide it. So basically I am left with using good defaults and hoping for the best. :)
    10. Define grid (if used) - fixed / responsive grid, columns and gutters
    11. Define what the viewport is for specific screen sizes, so that you can create a composition taking that into consideration. (for websites it's different breakpoints, for example see this http://dev.vuzum.com/breakpoints/) For apps it's the 1x, 2x, 3x mantra. I'll write a good post about it sometimes soon. The idea is to start at 375x667 as your 1x.
    12. Mockups (drawn).
    13. Wireframes (using sketch real quick, or balsamiq) - Will this compliment and reinforce my site's purpose? Is this really needed or am I just filling space? Will this be distracting from my site's purpose?) - filter, filter, filter - until there’s nothing that can be removed (get out of the user’s way, users come to the site for the content.
    14. Create Color Palettes (ideas: using photos/paintings of specific context - like space for science book, check contrast between colors with different tools afterwards)
    15. Create Style Guide (a reference sketch file with multiple instances of typography and UI elements used on the website/app)
    16. If needed, I sometimes split the Style Guide from the elements and create a separate UI Kit.
    17. Create Pages (usually for each screen category, or page in a website)
    18. Create Artboards per pages (basically, each page or screen has more states, these are done as Artboards).
    19. Set proper grid and layouts per Artboard.
    20. Create Symbols and shared styles for layers. I'm using Sketch and you should too.
    21. Design interface (magic)
    22. Organise layers. MANDATORY! :)
    23. Responsiveness if web, otherwise simply export in 1x, 2x, 3x and take care of the fine details.
    24. Sometimes I create a prototype in Invision or Marvel if I work on a project for a client. Otherwise I have my user flow chart that is enough for the dev team.
    25. Interactions mostly to get approval from client before we code without a direction and to explain the developer how it must FEEL (Origami, FramerJS only if Origami cannot do it)
    26. Presentation Layout - basically the design goes in a mobile or a chrome frame for presentation to the client.
    27. Perform usability tests. Go back to point 1 if needed depending on the results.
    28. Export Assets. This is important. Your developers should not open Photoshop or Sketch. And they should not experiment with values in CSS. You must be able to give them the assets correctly exported, including preferably a zip exported with https://github.com/tudou527/marketch, and the measurements on an alternate screen using https://github.com/utom/sketch-measure for distances and sizes. And a folder with the assets exported properly so they can simply place them in, and when needed CSS styles copy / pasted in a separate document for gradients and stuff like this. There's also Inspect by Invision and Zeplin, but these are not free. Don't be an asshole, do this right. :-)
    29. Be available during development to answer questions, alter assets as needed.
    30. Be there to QA the deliverables (not just UI but also UX).

    Next time a client tells you design is easy, send them a link here. If you can remove any of these steps and not affect the quality of the product, you tell me which step you would remove and I'll tell you what will change.

    12 points
    • Mason LawlorMason Lawlor, 3 years ago (edited 3 years ago )

      I really like this answer, but I feel it's most appropriate for projects you get an ideal budget on. I have a low cost lifestyle, and I think it'd probably cost $5-10k for me to justify going through all these steps.

      I seem to get a lot of clients that I "want" to work with that don't have that kind of budget starting out, so I think it's nice to have a discount process as well (given that you're willing to sacrifice ideal budget for a more interesting project).

      So it depends on the project for me. Sometimes I skip hand-sketching. Sometimes I even skip the mockup process and go straight to development. Usually a combination, where we establish the design is headed in the right direction and start developing it knowing there will be some minor changes.

      One important thing to always keep the client aware of is in the video production world, what we call picture lock. Once the storyboard has been approved, and especially is production has commenced, they will be severely penalized if they want to re-work some original ideas that were approved. Idk the correct term for this in web design/dev world, but I'm sure it exists.

      A couple other tips:

      • If you use Photoshop, "Generate Assets" is a great feature that will export any layers/group names ending in .png or .jpg (I suggest only doing .svg in illustrator).

      • If you're using SVG's in Illustrator, you can edit/save in Illustrator with live updates to your site.

      And if you're writing code, especially if using a css pre-processor, grunt, gulp, or webpack (my new fave compiler) help immensely. Especially if used with Browsersync.

      If you find yourself redesigning similar websites over and over again, consider building internally used templates/boilerplates. Nothing will do more for refining your work-flow than actually documenting your process in detail, then constantly improve upon it.

      Good luck mate!

      2 points
      • Charles Jones, 3 years ago

        I really liked what you said about refining and using templates/boilerplates for improvement. I definitely agree.

        0 points
    • Charles Jones, 3 years ago

      Well done. I definitely need to re-examine these points, but I really like how you laid how things here.

      1 point
  • Ken Em, 3 years ago

    I'm old, so I sketch out ideas on paper sometimes. If it's a project for myself, I'll just jump into a text editor and start coding. No frameworks or any fancy stuff, just text on a page. If it's for someone else, the process usually starts with a few mockups in Photoshop before any coding is started.

    8 points
    • Charles Jones, 3 years ago

      I think sketching on paper is still an amazing way to start out! Thanks for your insight.

      0 points
  • Jon MyersJon Myers, 3 years ago (edited 3 years ago )

    My design approach begins first by burning sage and walking with the smoldering fire stick to every corner of the room with my head solemnly bowed down.

    Once the room begins to fill with smoke and people begin to choke, everyone is asked to stand as the leader of the organization proceeds to bang a gong to commence the design process.

    We then simulate a thunder and lightening storm with sound samples. The lights are flickered on and off, and everyone is given a kite on a stick with a keychain attached to the bottom and splashed with buckets of water.

    Our participants then experience a mild shock that emits from the kite stick to simulate what it feels like to innovate.

    Feel the innovation... Praise it!

    A foosball rod is spun, the leader of the session snaps a bumper pool cue over his knee, and that gets things going.

    Everyone is then seated in bean bag chairs, Rubic’s cubes, nerf guns and other objects of creative irony are placed in front of the subjects. The hands to the side, palms to the sky and ceremonial goat bones are passed to awaken the third eye chakra.

    A basket is then passed and all participants are asked to place their wallets in the basket and they’re reminded that the entire place is under surveillance and the session is being recorded.

    The subjects are then asked to put on blind folds...

    --

    Ok, for real.

    There is some really good stuff here others have mentioned in terms of tactics and organization.

    In terms of technical execution, the design part, I run similar to how others here have outlined in areas such as document organization, style organization and so on.

    These days, it’s basically - full on Atomic Method with some of my own twists.

    My own high-level framework I adapt and keep to myself in terms of product creation.

    Empathy, utility and value.

    I’ll let you read the tea leaves on that - as you will.

    Seriously though, if you want to get REALLY good, have more impact and thus, charge more, you need to get involved in the business case of what you are designing, who it serves and why that product should exist in the first place.

    You want to be hand in hand with the stakeholders.

    Thus, it depends on the project.

    -

    Go to the scene of the crime

    While surveying customers can be useful, and we do, I don’t like solely hiding behind a crapy online form and calling it a day. Everyone is doing that shit and people have form fatigue.

    I go in the field and get my hands dirty.

    I prefer to go to the scene of the crime. The emergency room, the call center, the office, the factory where they make the sausage, the showroom, so I can see the faces of customers in action. Customers in pain, customers being entertained, customers who peace TFO and could give dos cacas about the company. All this, so I can see how the business operates, so I can ask questions and see WTF is going on and hypothesize as to why.

    The design approach for me always starts there, getting as close to the problem as possible.

    I then dig deep into how the company, its products and services and its site seek to serve those humans and the problem space their offerings exist in.

    I get deep into how it works, how does it create value for customers and the business, and ding ding, what economic yield on what I am creating for them do they desire.

    That desired economic yield on my efforts dictates if it makes sense for them to even work with me or if so, how do I calibrate my pricing in relationship to the effort, intellectual property and the yield they desire from my contribution.

    So funny enough, I rarely talk about “design” with customers, making the logo bigger, my son loves red, so make this red. Design is the baseline. That’s the running water, the toilets, the internet, the electricity and lights on. We do talk design systems, and mostly, my days are spent toiling over how it works, and by nature of how it works, how do our assumptions of how it works serve the user.

    In short, the Cliff Notes:

    1. Get close to the problem
    2. Get close to the user
    3. Document and understand business fundamentals
    4. Have one single source of truth documenting these understandings.
    5. Maintain a constant quest for clarity based on the understandings of the user and business fundamentals.

    Good luck.

    -j

    3 points
    • Charles Jones, 3 years ago (edited 3 years ago )

      Thank you for this. This is super insightful. I think the power of understanding and a clarity in objectives is really important. I think what potentially slows the process down is when these things are not perceived well.

      0 points
  • Robin RaszkaRobin Raszka, 3 years ago

    Dropbox Paper > Sketch > Atom

    2 points
    • Charles Jones, 3 years ago

      I used Dropbox Paper for a logo project, and really enjoyed it! Good to see it works for you.

      0 points
  • Connor NorvellConnor Norvell, 3 years ago

    I generally switch between sketch, and coding. I'll start the design in sketch, but a lot of times I change the design after testing it out with some code, so ill make a few 'test' folders and fine tune the design before fully coding it.

    Thats about it!

    2 points
    • Charles Jones, 3 years ago

      So when you change the design you change the static design file rather than changing the code?

      0 points
      • Connor NorvellConnor Norvell, 3 years ago (edited 3 years ago )

        Depending on the client yes. For most projects no, but it depends. I use sketch as a way to mind map mostly. So I might make a new art board and experiment with different variations on the design I made, and I will update the design based on the code I wrote if I need to pitch it to a client.

        My system isn't super efficient either. But as long as I avoid sloppy coding it works pretty well.

        Its important to note that this is very literally my 'design' workflow and not the whole process, others have more in depth answers like planning before you ever open sketch, I do those things as well, but as far as design goes... thats my system

        1 point
        • Charles Jones, 3 years ago

          That makes sense, and is interesting; it seems like its good to keep things hand in hand if you're working with both code and design.

          1 point
  • Bentley Wong , 3 years ago

    https://www.quora.com/What-does-the-future-of-PSD-to-HTML-technology-look-like/answer/Dipesh-Batheja?srid=D11Y

    Just read this article it was pretty insightful in terms of how the design to development workflow is evolving. I think you might find it helpful for web design approach.

    1 point
    • Charles Jones, 3 years ago

      Definitely just read this as well. I liked the progress of the article. I still feel like I am asking the same question though of “so what's working best for people?”

      0 points
  • Jesse Korzan, 3 years ago

    Charles, good question. When you say you are slow, is it you're missing deadlines or you feel you could be more profitable with your time?

    0 points
    • Charles Jones, 3 years ago

      Could be more profitable with my time. My process doesn't seem fluid enough. I see the steps are important from wireframes to design to code. I don't believe I should jump into code right after wireframing, but I also believe that it is easy to spend an unnecessary amount of time within the design.

      I don't want this to be a "use prototypes" conversation. I just think there has to be a better way to handle these elements of the web-design process.

      1 point
      • Jesse Korzan, 3 years ago

        Some folks, like myself, have a variable process. Certain projects, maybe I do jump from quick paper sketches to HTML wireframes, other projects require more work; photoshop time for element collages, complex wireframes to spec out requirements, different stages of fidelity for prototypes, user testing, etc.

        Paper sketches are often good enough for wireframes, so maybe skip the Omnigraffle. A competitors website can be a fine prototype (using Chrome dev tools, change a logo, change a couple colours and bam! you've got a good reference for early discussions with stakeholders).

        Personally, as I got (get) more experience, I am better equipped to gauge when I've defined a problem well enough to start solving it. And what tools/steps I am best with to deliver an appropriate solution. The problem (and constraints) dictates the tools, not the other way around, I guess.

        1 point
        • Charles Jones, 3 years ago

          Thanks for your insight. It's great learning how your take on projects of this nature. One thing I am noting is that maybe the process doesn't have to be linear; it can be dynamic depending on the project goals.

          1 point