Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How do you write concepts? (Structure / Tools / Howto)
63 points by ladino on Apr 29, 2016 | hide | past | web | favorite | 21 comments
You have an idea and would love to get a designer + developer to get that on track! :)

How do you scribble your mockup? Do you have a structure or question-list to make a detailed concept (in my case for a web project) What are your experiences? What are your tools? Could you recommend books or experiences from big companies? How to start?

* Design Mockup Tools

In the past I used Keynote for its simplicity, now I prefer Sketch. It's nice to be able to preview your designs on your mobile devices. These apps are for Mac only though.

* Books

One book I would recommend on design is "The Design of Everyday Things". You'll learn a few useful things about design in general.

Another book I'm reading right now is "The Process of Creating Life". I cannot recommend it yet as I haven't finished it, so I'm just mentioning it. This book might seem like an odd choice at first since it's from the architecture shelf, but it has some interesting ideas nonetheless.

One thing to mention is that the topic for both of these books is not digital design, yet I would argue that the knowledge learned from them is transferable to the digital realm.

About "The Design of Everyday Things", there is also a course on Udacity based on the book: https://www.udacity.com/course/intro-to-the-design-of-everyd...

I sometimes work with remote designers, so I needed something that is flexible and fast to create.

Rather than trying to spend hours using Gimp or Photoshop ( I have been down that road), this is what I do as its much faster to translate whats in my mind to something a designer can use.

Get a sketch pad ( blank pages no lines ), I bought mine at a local pharmacy.

Get a good mechanical pencil, they sell good ones for drafting, also get a good erasure that is different from the pencil.

Get yourself a good ruler, it you want to draw to scale get an architectural ruler not an engineering ruler ( scale is for land etc so its too big ) if you do not need to draw to scale, get a metal ruler with the cork underside to prevent slipping on the paper.

Get yourself a plastic stencil of different shapes. Many of these are used for flow charts or electric circuits, but find one that has the shapes you want.

Draw out your proof of concepts on paper using your rulers and stencils.

Label your drawing.

Finally just take a picture with your phone and send it to the designer.

It you have to make a change, its super simple to erase something and make an adjustment.

Take a look at the recent book Sprint: http://www.goodreads.com/book/show/25814544-sprint?from_sear...

It details a creative process for developing concepts and testing them. Given that the book outlines a 5-day process that is tailored for product development teams, you might get a lot out of it for personal projects.

I'll say pen and paper for sketching too, for it is the fastest tool to use, no need to chase the object you'll draw, or search for where to modify the font. You think and you draw, the quickest possible. But then I'd move it to a digital platform because there it's easier to manipulate a schema that you already have. Though up until this day I haven't done that. However for emacs users there is the builtin artist mode and for others who don't want to use emacs there's a program that is capable of sketches and flow charts via a script input, but I don't recall the name, sorry.

In general I usually jot down whatever comes to my mind and try to structure it all later, or on the way witg intervals. It's hard to think in a schematic way. So I'll have my notebook and pen, and write whatever comes to my mind asynchronously, that is I won't wait for the next thought. If I'll present my idea to someone else, I ll try to have at hand a schema and some notes both as brief and as clear as possible and I'll skip details for not making premature commitments.

For UI/UX draw it on paper. Then get inspiration from an expert's work who's design is similar to your drawing on a sites like behance, dribbble, etc.

I use my blog post for my go-to list for prototyping.


[Look at design resources section](https://medium.com/free-stuff/500-free-things-on-the-interne...)

For data structures, database schema, software dev; MOOCs are your best friend. (MIT,Coursera, etc.)

I've found more formal database schemas are often lost on people that don't work with relational data. Any ideas on how to avoid that?

I typically don't go past the point of jotting down the structs. If we're just talking about getting ideas out, it only needs to include what's necessary for selling the idea.

Edit: by which I mean a fairly simplified bullet-point list of, say, ThingFoo with attrs fizz, buzz, bar, and baz.

This is a great point. I forgot about this. People who have no background in programming can find it easier to follow along if you just tell them you're gonna have this multiple different black boxes that does a specific thing (different function/methods/classes)

I'm using draw.io to draw mockups, it's incredibly useful, it helps me to figure out how the interface looks like.

Also I use emacs org-mode to write down my notes. Usually it's just some thoughts on the project and list of features that I want.

Then I start putting it together in browser, usually almost immediately, without much preparation. I just create a django project, add a test view, and start writing some html/css. It really helps me to think, as I do that I get all sorts of ideas about the design, features that I want, and how the whole project will be structured.

Meanwhile, on my notes, I have a list of "big", "medium", and "small" features, ranked by importance(or in order I want to build them in). Also bugs, questions, and whatever other ideas I have.

But all that is just for personal projects, I haven't yet worked in teams on anything big.

http://creately.com/plans only costs $50 for a year for an individual

It allows you to create use cases. I wouldn't get too much into the details. It's a designer and developers job to design and develop. If they are good they will have plenty of insights on "how" to do stuff. If you give them too much detail they will just use your design. Let them use the other tools to create the design and flow for you. And let them justify why they made those decisions.

I would design the initial on boarding flow first and test if you can get users for it. don't spend a bunch of money on a project that can't get bunch of users.

I've had a lot of luck throwing something together in Bootstrap or similar, and then when a designer gets involved with the project, they approach it as more of a redesign: they can get familiar with the app, understand what it's trying to do, and then go from there. Paper, in my experience, doesn't adequately communicate some things (for instance, more complicated UI interactions are somewhat hard to model in a reasonable way on paper).

Personally, for code stuff I've always found that boxes with arrows between them are really good at relaying information (pen and paper / whiteboard).

In my experience, it's not the final result that matters though, it's the process. As you add each bit to the puzzle and scribble paths on that helps build the understanding. The end result usually looks like a big mess, but the process of getting there is what matters.

That works for most decision tree models. Venn diagrams are better for explaining anything having to do with set models. Cartesian graphs are good at explaining time/space complexity.

Whiteboard + draw.io for component, flow and class diagrams (if it comes to that level). Whiteboard for UI. If I have a dedicated UI dev, they can take a pic of my whiteboard sketch and build a static prototype faster than me attempting to draw it in some legit fashion :)

Quick static/stubbed out prototype app in some cases with whatever tech is appropriate (for mobile been digging ionic quite a bit lately for prototyping).

I'm a customer & fan of balsamiq.com for sketching user interfaces - it does the job really well.

webpagestickynotes.com has a diagram menu powered by js-sequence-diagrams, mermaid.js, flowchart.js & d3.js that allows frictionless text-to-SVG diagram rendering paired with a quick snapshot capability.

Additionally, draw.io can produce SVGs with embedded serialized draw.io state. Those SVGs can be added in a document or a sticky note and re-imported back to draw.io for later editing.

If I make a concept or design and in the process of thinking, I only use pencil and paper, lots of paper.

Everything else is just too distracting. The available software tools just don't cut it for me as a software developer. They are bound to a device and have complicated user interfaces, they are distracting or at least run on a device that has potential to distract me. Even if they are the perfect software, the fact that they run on a PC/Laptop/tablet/Phone is just enough to distract me. Except maybe a whiteboard, but these are quite expensive compared to pencil and paper and a maintenance nightmare. Their use case is justified if this is an interactive Meeting.

And the best thing about pencil and paper: It works offline, will not install updates and display no ads.

If I am done thinking/tinkering/planning/designing/modeling whatevering, I either redraw it cleanly and scan it or use one of the tools, others will mention in their comments to be able to archive it digitally and share it with others.

Some notes:

No, the time you will need to redraw it when changing your concept it not wasted time. No, the fact, that there is limited space and resolution when working with pencil and paper is a feature, not a bug.

Now for the process:

use cases DO NOT SKIP THIS, never ever. Some may call them user stories but hey, that's just marketing. use cases can be put in diagrams and they even have a standard: UML They are the highest level abstraction of what you want to build and the help you and others to keep on track. Maybe read about them here: https://en.wikipedia.org/wiki/Use_case TL;DR The important part is to know, who will do what with the system you want to build, to achieve what? When creating diagrams, create them in a way, so that they fit on maximum half a page each. Everything else can't be grasped reasonably and is "just to smartâ„¢". Divide and conquer if necessary. As a result, it should be clear on a high level abstraction what the purpose of that thing you want to build is. A tip: You may sit for an hour on a diagram that has four bubbles and a stick man, that may feel awkward but is just the right thing!

If you have use cases, you can go on with how you imagine to fulfill these. That's usually the exciting part and the part people jump to forst, not realizing that they don't even know what they want to do because they skipped creating usecases... Depending on the project use anything that seems appropriate: mockups, architecture diagrams or some kind of sitemap in case of a web site.

If you think you have a rough draft you can explain, talk to your developer/designer, the rest will come naturally if they are professional. If they are professional, the should be able to offer you good communication as part of their job.

Hey there, I've enjoyed your comment. I think we're kindred spirits when it comes to using paper for putting thoughts down without distractions.

Mind if I ask you two questions?

I've been struggling with finding a way to reconcile using paper and the digital realm.

On the one hand, I find sketching out ideas and writing out thoughts a lot more enjoyable on paper. I also seem to distill what I am trying to communicate a lot better too! And like you've mentioned, there are a lot of negatives to using software to achieve the same end.

- Complexity of interface

- The software runs on a machine that is capable of distracting me way too easy

- Notifications

But how do you deal with having a lot of paper floating around, filled with ideas and sketches of stuff? I guess, how do you organize them all in a way that isn't just organized clutter?

I've been digitizing all my work with a Document Feeder Scanner, which works alright in the sense that it gets my work onto the machine, but I feel like I'm philosophically missing the point.

Can you comment with some thoughts perhaps? Thank you.

Actually there are two points here:

1. The creative process 2. Archiving/documenting

The amount of paper used in 1. can be very high, but essentially the key point is to let go of all your sketches when you are done distilling them. They are material for the trashbin. This may sound hard but it makes sense when you have a separate step for archiving, which means step 2.

Step 2. means, I distill all the lump of paper into what is required for the project at hand or worth keeping. This depends on the circumstances. Sometimes it means just putting a sheet of paper next to the other bureaucratic stuff, most of the time it means writing a project documentation or "specification" document, sometimes writing an outline for a paper or an abstract. This may be grunt work and the tools may suck, but that's OK since it is separated from the creative process and for the purpose of documentation, not creation.

If you have multiple projects at the same time and find yourself switching around often, make some organized space. There are these stackable plastic things where you can put stacks of paper in, not sure how they are called in english but I do use them to have 3 or 4 separated stacks that I can just pull out or put away when needed.

Maybe the key point is to be able and let go of old stuff. Taking half a hour once a week and browsing through the notes, evaluating and rejecting old/obsolete stuff helps too. Also, the "archiving step" acts as a filter. If you find yourself not having time/incentive to archive a certain idea or sketch, it is probably not worth it and can go to the trash.

Keep in mind, that Ideas (when they are just Ideas) are worthless. They need to be realized and one can only realize so much in a finite amount of time.

I sincerely appreciate your response and the points you've pointed out.

The process you talk about makes a lot of sense. The creative process separated from archiving/documentation is a good distinction, thinking about it. I can see how it moves from paper to digital better now.

I'm reflecting on the key point, of being able to let go of old stuff. That, combined with a limited time in the day (not to mention motivation / discipline / incentive) makes your point a very hard one to swallow.

I think that rationally, it makes sense. Limited time means we can only do so much in a day. Emotionally, it feels like I should be able to digitize all the ideas and do them "later".

I'm not sure where I'm getting at with this, but I wanted to say thank you for giving me some good advice on how to approach paper and digital for projects.

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact